端口已开放，服务还是不通？分层定位连接故障
先确定“开放”是哪一种证据
控制台里存在允许规则、扫描工具显示开放、应用返回了HTTP响应，是三个不同层次。第一种只能证明配置意图；第二种通常说明某次传输层探测得到响应；第三种才表示请求已经到达某个HTTP处理者，而且这个处理者未必是预期站点。
排障前把原始现象写完整：目标域名、协议、端口、时间、客户端网络，以及实际错误。连接被拒绝、连接超时、证书失败和页面返回错误码，应分别记录。不要把它们统称为“服务器不通”，否则更换DNS、重启应用和调整防火墙会同时发生，导致后续无法判断哪项真正有效。
从服务器本地确认业务是否成立
先检查程序是否运行、监听地址是否正确，再从服务器本地调用应用的健康接口或一个轻量页面。若本地也失败，优先处理应用配置、依赖和启动日志，不必先怀疑远端线路。
假设应用监听127.0.0.1:8080，由Nginx对外提供443入口。这可以是正常架构；不应为了让外部端口探测成功，直接把8080暴露给所有来源。应验证本地应用、Nginx到应用的代理连接、外部到Nginx三段路径，各段使用自己的预期地址和协议。
如果本地响应正常，外部连接仍失败，再比较云侧规则、系统规则、地址绑定和路由。如果存在容器或NAT，增加对映射层的检查。每次只修改已经有证据指向的一层，改动后复测相同请求。
保留域名语义测试指定入口
一个IP上可以承载多个站点。Nginx会结合监听地址、端口与请求主机名选择虚拟主机；直接访问IP可能进入默认站点，不能据此判断目标网站内容异常。Nginx请求处理文档
HTTPS还涉及证书对应的名称。排查某台源站时，可以使用curl的resolve功能指定目标地址，同时继续用正式域名进行请求和证书校验。以下使用文档示例地址，执行时应替换成自己管理的真实入口。curl官方手册
curl -v --connect-timeout 5 --max-time 15 --resolve www.example.com:443:192.0.2.10 https://www.example.com/
输出中应分别看连接建立、TLS校验、HTTP状态和响应体。不要把跳过证书校验设为长期修复；那样会掩盖域名不匹配、证书链缺失或信任配置问题。保存诊断信息前，也应移除认证头、Cookie等敏感字段。
用请求关联代理和应用日志
如果已经得到HTTP响应，检查响应来自哪里。CDN错误页、反向代理错误和应用自己的错误界面，可能使用相似的文字。记录请求标识、响应时间与状态码，然后在同一时间范围内查边缘、代理和应用日志。
假设代理返回502，而应用日志没有对应请求，排查重点可以放在代理到上游的连接与协议。若应用已经完成处理但代理最终超时，就要比较各层超时设置和处理耗时。提高超时可能缓解症状，但需要先确认长时间等待是否符合业务要求，不能让慢请求无限占用连接。
恢复后，用原先失败的操作复测，并增加一条能发现同类问题的探测。例如检查页面中的预期标识，而不是仅检查443能连接；对登录接口则使用受控的测试账号验证完整路径。验收记录应说明恢复了哪种业务、覆盖了哪些入口，以及仍未验证的访问场景。