VMISS迁移后Nginx仍报502？先核对域名刷新与后端身份

网站迁到新服务器，直接访问后端已经正常，经过Nginx却还报502，此时继续给VMISS候选实例加CPU，可能买不到任何改善。域名记录改了，不代表每一层代理已经把请求送到新地址；连上了新地址，也不代表HTTPS身份和应用站点选择正确。迁移验收应沿着一次失败请求寻找证据，先确认代理连接的实际目标，再决定是否需要调整解析方式、证书配置或者服务器资源。

一份502记录，需要同时留下地址与业务身份

设想一个场景：入口代理没有迁移，应用后端换了机器，运维者更新了后端域名的地址。浏览器直连新机能打开首页，入口仍偶发失败。这里是排查情景，不是VMISS发生过的事故，也没有对商家实例作实测。首先保留入口错误日志、同一请求的时间与路径，并记录实际上游地址、响应状态和耗时；如果条件允许，再用请求标识对上新旧应用日志。只保存浏览器上的502页面，很难分辨失败发生在连接、TLS还是应用返回阶段。

从代理所在环境检查解析结果，不能用管理员电脑的查询代替。代理可能使用独立DNS、容器内解析器或配置中的固定地址。还应检查实际加载的配置与二进制版本，确认请求落在哪个server和location，而不是只阅读部署目录里尚未生效的文件。DNS查询显示新地址，只能证明这次查询拿到了新答案，不能独立证明故障请求采用了它。要把答案与代理记录的实际目的地址对应起来。

这份记录也提供反证。如果失败请求已经稳定到达新后端，TLS和站点选择正确，应用日志却显示数据库等待或进程崩溃，就应转向应用与资源路径。不能因为迁移前后恰好改过DNS，就把所有502都归给解析；同样，重启一次恢复了，也不足以证明长期刷新机制已经正确。

“写域名”与“持续跟踪域名变化”是不同配置

NGINX上游模块文档将resolve定义为跟踪服务器域名对应的IP变化，并在无需重启的情况下修改上游配置。它同时要求服务器组位于共享内存中，并在http或对应upstream块指定resolver；在1.27.3之前，这一参数只属于商业订阅能力。[2] 因此采购交接不能只写“支持Nginx”，还要核对安装版本、构建来源和生效配置是否满足选用方式。发行版可能长期维护不同版本，不能直接拿最新文档中的示例覆盖现有环境。

配置里已有域名，并不充分证明启用了上述动态跟踪。应明确采用受支持的动态上游方式，还是由受控配置发布更新地址；后者需要把检测变更、验证配置和执行重载的责任写清。重载不是每个故障都应先执行的操作，尤其在尚未保存现场时。两种方案的取舍取决于地址变化频率、维护能力和故障预算，不是动态配置越多就越可靠。

对使用NGINX内置resolver的解析路径，文档说明默认按DNS响应的TTL缓存，valid参数能够覆盖这一有效期；resolver_timeout控制解析超时。[3] 缓存有效期与等待一次解析的超时时间，不能互相替代。降低缓存时间，不能修复一个不可达的解析器；缩短解析超时，也不意味着记录会更快更新。解析器应当从实际运行网络可达，并按官方建议部署在受保护、可信任的本地网络中。[3]

还有一种常见改法，是把proxy_pass改成包含变量的地址。代理模块文档说明，这时域名先在已定义的服务器组中查找，找不到时使用resolver解析；同时，变量与URI的组合会影响转发路径的替换规则。[1] 这不是只补一行DNS配置的无副作用修复。应把带查询参数、路径前缀和经过重写的请求一起回归，防止502消失以后，登录回调或文件下载路径悄悄变错。文章不提供可以不经修改直接投入生产的通用配置。

缩短TTL还会把更多正常请求的可用性依赖交给解析链路。解析器临时不可达、返回异常或者IPv6地址不可用，都需要在授权测试环境中分别验证。NGINX文档说明默认查询IPv4和IPv6，并提供按需关闭某个地址族查询的参数。[3] 不应为了让一次测试通过就永久关闭地址族；应先确认业务需要的路径与网络能力，保留故障证据，再选择相应策略。

连通以后，再验TLS名称与HTTP Host

后端使用HTTPS时，目的IP、TLS握手的服务名称与HTTP请求里的Host承担不同职责。NGINX文档明确写出，proxy_ssl_server_name默认关闭，用于控制是否向代理HTTPS服务器发送SNI；proxy_ssl_name用于指定证书校验和SNI使用的名称，默认来自proxy_pass的主机部分。[1] 因此，把后端改成固定IP虽然可能绕开地址选择问题，却可能同时改变名称语义，不能仅凭TCP端口可连接就宣布完成。

HTTP层还要另外核对。proxy_set_header用于重定义发往上游的请求头，默认Host使用$proxy_host；文档给出了按需求传递原始Host或$host的不同写法。[1] 新后端托管多个站点时，错误Host可能命中默认站点；客户端访问域名与源站证书域名不同时，也不能机械要求所有名称完全相同。交接记录应明确每一层预期名称，由后端实际配置验证对应关系。

证书校验也不能省略。文档标明proxy_ssl_verify默认关闭，并提供信任CA文件和校验深度等配置。[1] 面向需要验证源站身份的部署，应明确开启符合需求的校验、配置信任链并核对名称。关闭校验后能访问，只能帮助缩小某类问题范围，不能充当安全验收结果。若修复依赖忽略错误证书，应继续检查证书链、域名和信任配置，而不是用采购更贵机器掩盖问题。

VMISS订单应覆盖迁移窗口，而不是只填主机月费

本次渠道通记录确认了VMISS服务器推广入口，渠道商品列表中没有可用于核对具体套餐的产品记录。官网首页请求超时，商店返回403，未取得可用产品画面。因此这里不引用当前价格、库存、线路、资源独占比例或退款期限，也不把渠道介绍当成订单承诺。准备比较候选服务时，可通过VMISS服务器推广入口核对当前配置与服务条款查询。此链接具有推广关系，站点可能因成交获得佣金。

询价要带着现有服务的交付要求：系统镜像是否便于安装所需版本，解析器和源站访问是否可达，网络策略由谁维护，故障后是否有控制台恢复入口。还需取得首购与续费、流量计算、额外地址、取消与退款的书面条件。本篇没有进入客户账户核验这些项目，不能承诺某项套餐默认具备。若购买管理服务，应确认DNS刷新、TLS配置和迁移回归是否属于支持范围，避免把“提供服务器”误解成“负责应用迁移”。

总成本应加入旧机保留、新机试运行、配置发布、证书维护与回滚工时。假如只需修正地址刷新方式，升级CPU不会减少这项维护；若链路已经正确，而业务在同样请求和数据下持续出现资源饱和，再比较实例规格才有依据。保留双机的时间也不宜简单等于一个DNS TTL：客户端解析、代理自身地址选择、已有连接和应用数据写入各有边界，应按实际日志判断旧机何时可以退役。

验收最后做一次计划内地址更换，并保留回退。分别检查新建连接是否到达新后端、正确站点是否返回预期内容，以及解析异常时能否在业务允许时间内发现问题。涉及写入的操作还须核对数据归属，避免新旧节点同时接收不一致更新。只有这些结果都明确，才有依据停掉旧订单；若新机访问正常而代理仍使用旧目标，下一笔应投入的是解析与配置交接，而不是更多计算核心。

资料口径：技术依据为本次读取的NGINX官方模块文档，实际行为须对照部署版本和配置；商家事实限于渠道记录及上述访问状态。没有购买、性能测试或商家故障经历。正文配图均为生成示意，不作为产品功能或实测证据。

Sources:
[1] https://nginx.org/en/docs/http/ngx_http_proxy_module.html ， proxy
[2] https://nginx.org/en/docs/http/ngx_http_upstream_module.html ， upstream
[3] https://nginx.org/en/docs/http/ngx_http_core_module.html ， core