我目前正在设置 AWS ECS 上的官方 Docker 镜像。
在 EC2 上运行时，Docker 镜像工作得非常好。
但是，在 ECS 上使用相同的配置启动后，我最终遇到了损坏的头像图片。
相关错误：
在位于 url：//x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg 的存储中找不到文件
和
无法正确处理劫持的响应：FinalDestination::SSRFDetector::LookupFailedError：FinalDestination：查找失败
文件在存储桶中，并且访问权限与 EC2 实例相同。
有人能指出我可以深入挖掘并找到根本原因的地方吗？
谢谢。
您是否构建了一个包含启动器的镜像并将其推送到仓库？您是否使用与启动器相同的环境变量来启动它？
是的。我使用了 run-cmd 命令生成的环境变量。到目前为止，我没有发现任何错误。
不幸的是，我至今还没有找到 Discourse 的 ECS 示例。
你思路是对的，但是迁移展架和上传资源很棘手。我不确定问题可能出在哪里。
我找到了根本原因。由于我设置了 Discourse AI 插件，我将一个私有区域添加到了 VPC 中，以便在 VPC 内部提供各种服务。
当 Discourse 在 Docker 容器中的 EC2 实例上运行时，容器会获得一个像 12-34-56-78-app 这样的主机名。然而，当在 awsvpc 模式下作为 ECS 任务运行时，您无法设置主机名，也无法配置 DNS 搜索域。这导致 ECS 上的 DNS 解析不同，在我的例子中，添加了一个像 xxxx.internal 这样的搜索域。
在深入研究后，我使用 tcpdump 发现 Discourse 在 SSRF 检查中尝试解析自己的 FQDN。如果失败，检查就会失败。作为后续错误，对 S3 的调用会以上述错误的错误消息失败。
在我这里，修复方法是将我的 Cloudfront 分配的 FQDN 记录添加到我的私有 DNS 区域。
哇。这真是个不错的调试！这就是为什么这是一个不受支持的安装！其中很多都无法猜测！
最终还是老样子：如果它不起作用，那总是 DNS 
您好 @nodomain，
我遇到了和您在下面帖子中完全一样的错误。请求用户头像，例如 https://example.com/user_avatar/example.com/myself/96/215_2.png，响应为 500。在我的例子中，域名 example.com 没有在公共 DNS 中设置，在测试阶段，我在本地的 hosts 文件中伪造了 example.com。当域名 example.com 在公共 DNS 中设置好后，这个问题还会出现吗？
