采购承载 Nginx 反向代理业务的云服务器前，哪些带宽、IP与故障支持条款要核对？

先固定 502 的故障范围

多个变量同时变化时，很容易把 Nginx 的配置问题误判成带宽不足，也可能把上游应用异常归因于公网 IP。采购承载 Nginx 反向代理业务的云服务器前，应先要求供应商把带宽方向与计费口径、公网 IP 属性、线路测试条件、交付内容，以及网络与故障支持边界写入订单或合同。

实际排查时，先区分“请求是否到达 Nginx”和“ Nginx 是否能够正常连接上游”。只有在相同请求、相同测试节点和相同时间窗口下逐项改变一个变量，才有可能回答如何找出 Nginx 502 Bad Gateway 的根本原因。502 表示网关从上游获得了异常结果或无法完成正常转发，但它本身不能直接证明公网带宽、IP 或云服务器线路存在问题。

采购合同中必须写清的带宽、IP与支持条款

“独享带宽”“高速线路”“公网 IP”这类描述不能替代可验收的技术条款。比较不同方案时，至少要把以下项目统一到同一口径。

这里的“独享”或“固定”必须以供应商对资源属性的明确定义为准。不能因为某个 IP 当前只分配给一个实例，就推断它在迁移、重装或故障切换后仍然永久保留。若业务依赖源 IP 白名单，应同时确认 IP 变更通知、备用 IP 和切换流程，而不是只记录当前地址。

带宽还要结合业务方向理解。客户端访问 Nginx 时，请求流量从公网进入云服务器，响应流量通常从云服务器发出；Nginx 访问上游应用时，又会产生一条服务器到上游的连接。两段链路可能由不同的资源和故障边界负责。合同只写公网入口带宽，并不等于上游连接一定具备相同条件。

交付当天先建立可复现基线

采购验收不应一开始就压测或修改配置。先记录一组低风险、可重复的基线，后续每次只改变一个变量。基线至少包括：

• 测试节点所在网络、测试时间和时区；
• 使用的域名、解析到的 A 和 AAAA 记录、实际连接的公网 IP；
• 使用的协议和端口，例如 HTTP、HTTPS、80 或 443；
• 请求路径、请求方法、请求体大小和是否携带特定 Host；
• Nginx 返回的 HTTP 状态码、响应时间和响应头；
• 云平台看到的带宽、流量、连接数及异常告警；
• Nginx 访问日志、错误日志和上游状态；
• 测试次数、失败次数以及失败发生的具体时间。

如果没有业务健康检查接口，可以使用一个不会修改数据的静态路径或只读接口。不要用写入、删除或会触发业务副作用的请求作为验收样本。

从固定域名和指定公网 IP 发起 HTTPS 测试时，需要保留 Host 与 TLS SNI。下面的命令只用于读取结果，示例中的域名、IP 和路径应替换为实际值：

PUBLIC_IP="替换为待测公网IP"

curl -sS -o /dev/null \
  -w 'code=%{http_code} remote=%{remote_ip} connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n' \
  --connect-timeout 5 \
  --max-time 15 \
  --resolve example.com:443:"$PUBLIC_IP" \
  https://example.com/health

如果业务使用 HTTP，可将协议和端口改为实际配置。--resolve 只改变本次请求的域名解析，不改变服务器的 DNS 配置，适合验证某一个公网 IP。测试结果应与正常 DNS 访问结果分开记录。

在服务器上查看 Nginx 版本与当前生效配置，可先使用只读命令：

nginx -v
nginx -t
nginx -T 2>&1 | grep -E 'listen|server_name|proxy_pass|proxy_set_header'

nginx -T 的输出可能包含敏感配置，保存或发送给供应商前应先遮盖域名、内部地址、认证信息和密钥。nginx -t 只能说明配置语法和引用关系基本可解析，不代表上游应用一定可用。

按优先级逐项定位 502

第一步：确认请求是否真正到达 Nginx

先用固定测试节点访问域名，再用 --resolve 固定到待测公网 IP。两次请求保持路径、协议、请求头和时间窗口一致。

观察结果可以这样解释：

• 访问超时、连接被拒绝，且 Nginx 没有对应访问日志：优先检查 DNS 指向、A/AAAA 记录、云平台安全策略、监听端口、公网 IP 状态和入口线路。此时还不能把问题归因于上游应用。
• Nginx 有访问日志并返回 502：说明请求已经到达 Nginx，公网入口至少完成了连接建立，继续检查 Nginx 到上游的链路。
• 同一域名在不同地址上的结果不同：分别核对 IPv4、IPv6、DNS 缓存和各地址对应的实例，不要只根据域名整体结果判断。
• 固定公网 IP 正常，正常 DNS 访问异常：重点检查 DNS 记录、TTL、解析线路或是否存在未更新的旧地址。
• 固定公网 IP 也返回 502：公网入口通常不是第一嫌疑，应进入上游连接和配置验证。

如果 Nginx 没有访问日志，不能直接得出“线路不稳定”的结论。还需要确认日志路径、日志级别、请求是否经过其他入口，以及测试请求是否命中了正确的 server 配置。

第二步：检查公网 IP和端口交付条件

在供应商交付的 IP 上，至少验证实际监听端口、域名匹配和证书选择。HTTPS 场景下，直接访问 IP 可能因为 Host 和 SNI 不正确而出现证书或虚拟主机差异，因此应优先使用带 --resolve 的域名测试。

采购验收时应取得以下结果：

• 实际交付的公网 IP 与工单或订单记录一致；
• 域名的 A、AAAA 记录是否都指向预期地址；
• Nginx 的 listen 配置是否覆盖实际使用的 IPv4/IPv6 和端口；
• 云平台的端口策略是否允许业务所需流量；
• IP 是否属于固定分配、共享分配或可回收资源；
• 上游白名单需要放行哪个源 IP，以及该 IP 是否可能变化。

如果只关闭 IPv6 或只删除一条解析记录后问题消失，只能说明某个地址族或解析分支存在关联，仍需进一步检查该地址对应的监听、路由和上游访问能力。不要把“暂时删除 AAAA 记录”当作最终修复；如果业务需要双栈访问，应分别完成验收。

第三步：在同一时间窗口核对带宽和流量

带宽问题必须用云平台监控和业务请求结果同时判断。只看“带宽使用率没有达到标称值”并不足够，因为还可能存在连接数限制、单连接超时、上游响应异常或应用进程资源不足。

建议先在不改变配置的情况下记录：

• 入方向和出方向带宽；
• 总流量及计费流量；
• 活跃连接数和新建连接数；
• Nginx 进程的 CPU、内存和文件描述符情况；
• 502 的发生时间与带宽、连接指标是否重合；
• 失败请求的路径、响应体大小和上游地址。

如果平台提供分钟级或更细粒度数据，应确认统计时间与 Nginx 日志时间是否使用同一时区。不同统计周期不能直接对齐。

一次合格的性能判断应写明测试节点、时间、服务器配置、请求路径、协议、并发方式、请求和响应大小、样本数量及失败定义。例如：

在某测试节点于某日某时间段，通过 HTTPS 请求固定域名的只读接口，记录连续样本的状态码、连接时间、首字节时间和总响应时间，并同时读取云平台入出方向流量与 Nginx 上游耗时。

这是测试方法，不代表已经取得任何性能结论。没有真实样本时，不应声称某条线路、某个带宽规格或某个公网 IP 能承载多少请求。

结果解释应保持克制：

• 带宽接近合同定义的上限，同时响应变慢或连接失败增加：可能存在带宽或突发策略影响，应要求供应商提供同一时间段的端口、流量和限速记录。
• 带宽不高，但新建连接失败或 502 增加：优先检查连接数、文件描述符、上游端口、Nginx worker 和应用资源。
• 带宽指标稳定，只有某个接口返回 502：更像是接口对应的上游、请求头、协议或应用处理异常，不应直接采购更高带宽。
• 降低请求量后恢复，但上游日志同时出现进程退出或连接重置：带宽可能只是触发条件，根因仍需在应用或连接容量中确认。

任何带宽升级都应作为单独变量进行复测。升级前后保持测试节点、请求内容、并发方法、时间记录和监控口径一致，不能同时修改 Nginx 超时、DNS 和上游实例。

第四步：检查 Nginx到上游的连接状态

当请求已经到达 Nginx 后，应从 Nginx 所在服务器发起与 Nginx 配置相同的上游测试。不能只从个人电脑访问上游，因为两者的 DNS、路由、源 IP 和访问权限可能不同。

先确认配置中的上游地址、端口、协议和域名解析：

nginx -T 2>&1 | grep -E 'upstream|proxy_pass|proxy_ssl|proxy_set_header'
getent hosts upstream.example.com
ss -lnt

如果上游是 HTTPS，还要保持正确的域名和 SNI。可以使用实际解析出的地址进行定向测试，但不能为了测试而修改生产 DNS：

UPSTREAM_IP="替换为上游地址"

curl -sS -o /dev/null \
  -w 'code=%{http_code} remote=%{remote_ip} connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n' \
  --connect-timeout 5 \
  --max-time 15 \
  --resolve upstream.example.com:443:"$UPSTREAM_IP" \
  https://upstream.example.com/health

结果含义通常如下：

• 连接被拒绝：上游端口没有监听、端口配置错误，或访问控制拒绝连接。
• 连接超时：需要检查从 Nginx 到上游的路由、访问控制、地址解析和上游负载；这类情况不一定是公网入口带宽问题。
• 能够连接但返回异常协议或异常响应：检查上游是否确实提供 HTTP 服务、TLS 配置是否匹配、Host 是否正确，以及是否有中间设备修改响应。
• 本机请求上游正常，但经 Nginx 转发为 502：重点核对 proxy_pass 的 URI 拼接、请求头、协议版本、TLS SNI、连接复用以及 Nginx 所使用的解析结果。
• 本机请求上游也失败：优先处理上游服务、上游监听、访问控制或服务器到上游的网络问题。

不要仅通过提高 proxy_read_timeout 来处理所有 502。读取超时更常见地表现为 504，但上游提前关闭连接、返回无效响应或连接建立失败仍可能是 502。超时参数只有在日志明确显示等待时间不足，且应用确实允许更长处理时间时，才适合作为单独变量验证。

第五步：结合日志判断是连接、协议还是应用异常

为了把 502 与具体上游行为关联起来，建议在变更前备份配置，并在维护窗口内增加必要的上游耗时字段。下面是示例配置片段，字段应放在 Nginx 合法的配置上下文中，不能直接覆盖整个配置文件：

log_format upstream_timing
    '$remote_addr [$time_local] "$request" '
    'status=$status upstream_status=$upstream_status '
    'upstream_addr=$upstream_addr '
    'request_time=$request_time '
    'upstream_connect_time=$upstream_connect_time '
    'upstream_header_time=$upstream_header_time '
    'upstream_response_time=$upstream_response_time';

access_log /var/log/nginx/access.log upstream_timing;

修改前应保存原配置，确认磁盘空间和日志权限；配置变更会影响日志格式和排障方式，但不会自动修复上游故障。变更后先执行语法检查，再平滑加载：

nginx -t
systemctl reload nginx

以上命令适用于由 systemd 管理且服务名为 nginx 的系统。若服务管理方式或配置路径不同，应先核对实际环境，不要照搬服务名。若检查失败，不应执行加载；若加载后日志异常，应恢复备份配置，再执行 nginx -t，确认无误后重新加载。

Nginx 错误日志中常见信息与方向包括：

具体日志文本会随 Nginx 版本、操作系统和编译模块有所不同。应保存错误发生前后的完整时间段，而不是只截取一行。日志中的 upstream_status、upstream_addr 和耗时字段，能够帮助判断失败发生在哪个上游成员。

第六步：确认上游应用是否在相同条件下可用

如果 Nginx 到上游的连接已经建立，还要检查应用是否能返回符合预期的 HTTP 响应。重点包括：

• 上游服务是否正在监听配置中的地址和端口；
• 应用是否要求特定的 Host、认证头或请求协议；
• 应用是否能处理 Nginx 转发后的路径；
• 应用是否因连接数、线程、进程或资源限制主动关闭连接；
• 应用日志中的错误时间是否与 Nginx 502 时间一致；
• 是否只有大请求、长响应或特定接口失败。

这一阶段不要同时重启应用、修改 Nginx、切换公网 IP 和升级带宽。若必须重启或调整应用，应先确认影响范围、保存当前配置和日志，并安排回滚方式。生产业务不适合通过随意停止进程来“验证”故障。

修复后应至少进行两类验证：

1. 从 Nginx 主机直接访问上游，确认连接、协议和响应内容正常；
2. 从固定外部测试节点访问公网域名，确认 Nginx 状态码、上游状态码和响应耗时恢复。

只有两类验证都通过，才可以认为转发链路基本恢复。若仅本机访问上游正常，而外部请求仍为 502，应回到 Nginx 配置、虚拟主机匹配和请求头检查。

把故障支持条款变成可执行的工单边界

采购时不应只问“是否提供 7×24 小时支持”，还要要求对方说明什么事件可以受理、需要提交什么证据、何时升级以及何时算恢复。

建议在合同或服务附件中明确以下内容：

网络与IP故障

确认公网 IP 不可达、端口无法建立连接、异常丢包、IP 被错误回收或地址发生变化时，由哪一方负责初步定位。还应说明：

• 供应商能提供哪些时间段的端口、流量、连接和网络事件记录；
• 是否可以协助确认 A、AAAA 解析到的实际地址；
• IP 变更、迁移或替换是否提前通知；
• 业务依赖白名单时，供应商能否提供变更记录；
• 网络故障与客户自身安全策略、Nginx 配置之间如何划分责任。

“线路稳定”不是可验收条款。应改为具体的监控指标、统计窗口、测试方法和异常处理流程。

云服务器与Nginx故障

明确系统不可登录、实例异常、端口不可监听、Nginx 进程退出与客户自定义配置错误之间的责任边界。供应商可以负责实例和基础网络，但不应默认承诺能够修复业务应用返回的所有 502。

如果供应商提供 Nginx 配置协助，应确认协助范围是否包括：

• 检查配置语法和生效配置；
• 核对监听端口、上游地址和日志；
• 协助判断公网到 Nginx、Nginx 到上游的故障位置；
• 是否允许在生产环境执行 reload；
• 配置修改前是否需要客户确认和备份。

响应、升级与恢复

把“响应时间”和“恢复时间”分开。前者是工单被接收或开始处理的时间，后者是服务恢复或提供临时绕行方案的时间。两者的起算条件、暂停条件、维护窗口和客户配合要求都应写清。

同时确认：

• 是否有电话、工单或紧急升级通道；
• 需要提供哪些日志、请求时间和公网 IP 信息；
• 是否支持把网络、主机和应用相关人员加入同一故障单；
• 维护或迁移是否提前通知；
• 故障记录和监控数据保存多久；
• 服务等级未达标时，如何认定和处理。

这些条款的价值不在于保证业务永不返回 502，而在于发生问题时能快速判断是入口、线路、Nginx、上游连接还是应用本身。

采购前的最终核对顺序

在签约或确认订单前，可以按以下顺序留存书面结果：

1. 确认业务链路：记录客户端到公网 IP、Nginx 到上游的两段连接，以及实际使用的域名、端口和协议。
2. 确认带宽口径：分别问清入、出方向、保证值、上限、突发、限速、统计周期和费用计算方式。
3. 确认 IP 属性：记录 IPv4/IPv6、固定性、独享或共享属性、变更流程、白名单支持和异常处理方式。
4. 确认交付内容：验收公网 IP、DNS 配合、端口、监控、流量统计、日志权限和登录条件。
5. 建立低负载基线：在指定测试节点和时间窗口执行固定请求，保存状态码、耗时、解析结果和日志。
6. 验证上游路径：从 Nginx 主机访问上游，确认地址解析、端口、Host、TLS 和只读健康接口。
7. 确认故障支持：把网络、IP、实例、Nginx 和应用的责任边界，以及响应、升级、恢复和证据要求写入合同。
8. 再进行容量测试：只有基线稳定且条款明确后，才按业务模型测试并发、响应大小和持续时间；测试过程中一次只改变一个变量。

复测条件和结论边界

修复 502 后，不能只用一次浏览器刷新作为验收。应在与故障期间尽量一致的测试节点、协议、域名、解析方式、请求路径和上游条件下复测，并同时查看 Nginx 访问日志、错误日志、上游应用日志以及云平台带宽和连接指标。

如果改变公网 IP 后恢复，只能说明 IP 或其关联路径与故障有关；如果提高带宽后恢复，也还要排除连接数、突发策略和应用资源耗尽。只有在单变量复测、日志证据和多次相同条件验证能够相互印证时，才适合把某个因素认定为根本原因。

最终采购判断也应保留限制条件：测试结论只覆盖已声明的节点、时间、协议、请求类型和样本范围，不能自动延伸为所有时段、所有用户网络或所有业务接口的性能承诺。