在很多情况下，我们需要在 AWS beanstalk 环境中覆盖 nginx conf
。- 设置最大文件附件 数
- 强制 http 到 https
- 为不同的静态资源设置不同的缓存过期时间
- 设置 WebSocket
- gzip 文件类型
- 等等 等等
AWS Support 建议使用 nginx.conf，它是来自 beanstalk 应用程序的副本，方法是在实例中查看/etc/nginx/nginx.conf。这将用作基础，然后添加新的配置或块。 然后在项目中使用此内容使用 .ebextensions/nginx/nginx.conf。 但是，最大的问题是，如果AWS更改了基本nginx.conf，那么可能很难首先知道它何时更改，然后重复复制它然后添加覆盖的步骤。像这样的东西
大多数网络搜索提供的其他选项是在appdeploy或configdeploy中使用container_commands和创建文件 container_commands人们建议修改/tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf 像这样的东西
这种方法的问题在于，它仅在部署应用程序时才有效，而不是在任何 beanstalk 配置已更改时(例如更改 env var(。
我的问题是哪种是覆盖nginx配置的更好推荐方法。
为了帮助保持弹性 beanstalk 部署的可管理性，请记住以下几点：
首先：AWS 不会直接更改 Elastic Beanstalk 生产环境中的任何配置。 同样，您也不应直接在生产弹性 beanstalk 环境中进行任何更改。
AWS 建议您更改开发环境中的配置，并在要使更改生效时通过控制台或 Elastic Beanstalk 命令行界面 (CLI( 重新部署。 这与容器化与否，或负载平衡与否，弹性 beanstalk nginx 配置文件或覆盖选项无关。
第二：从您提供的第一个链接：您可以使用弹性 beanstalk 默认的 nginx 配置或.ebextensions 中的覆盖配置。 两者之间没有混合。 这应该有助于减少您的困惑。 在开发环境中对任一更改时，此更改意味着应用的新版本，您需要将其部署到生产环境才能生效。
第三：nginx可以充当源服务器的代理，源服务器可能会指示资产的缓存过期。 如果需要，有一些方法可以更改nginx配置上的配置以覆盖源设置。 来自 NGINX 缓存指南：
默认情况下，NGINX 遵循来自源的 Cache-Control 标头 服务器。它不会缓存缓存控制设置为 私有、无缓存或无存储或在响应中使用设置cookie 页眉。NGINX只缓存GET和HEAD客户端请求。
我希望这有助于澄清问题。 部署应用并牢记这些技术，继续部署。 如果错误，请将其删除，然后重试。
如果您遇到困难，请询问有关您的应用程序和特定配置的更具体的问题。 您为问题提供的详细信息越多，我们就越能为您提供帮助。