表现常为浏览器报错(ERR_CONNECTION_TIMED_OUT / ERR_SSL_PROTOCOL_ERROR)、curl 无响应或返回 4xx/5xx。作为 开发者视角,应先区分是网络连通、传输层还是 应用层故障排除 范畴。
优先用 curl -v、telnet 或 nc 测试目标端口连通性;若 TCP 三次握手成功但 HTTP 报错,表明问题在应用层或 TLS 层。
先做端口连通 → 再做 TLS/证书 → 检查 Host/虚拟主机 → 查看应用日志与访问控制。
若域名解析到错误 IP 或解析失败,会直接导致无法连接。用 dig/nslookup 查看 A/AAAA/CNAME 记录,并比较本地与公网解析差异。
检查 TTL、域名备案/注册状态、CDN 或负载均衡的回源配置,以及是否存在 DNS 污染或 ISP 劫持。
临时用 8.8.8.8 或 1.1.1.1 对比解析,修改 hosts 做本地绕过,确认解析恢复后再同步修复权威 DNS 配置。
出现证书错误、浏览器提示“证书域名不匹配”或连接被拒,可能是证书链、证书过期或 SNI 不匹配引起的。
使用 openssl s_client -connect host:443 -servername domain 检查服务器返回的证书与 SNI 关联是否正确,验证证书链与中间证书是否完整。
确保证书覆盖所有域名(包含 www 与裸域),并在负载均衡/反向代理上正确配置 SNI、证书路径与密钥权限。
若服务器基于 Host 头做虚拟主机路由,缺失或错误的 Host 会导致 404 或转到默认站点;反向代理转发规则不当也会导致路径错乱。
用 curl -H "Host: domain" 明确传递 Host 头测试后端响应,检查 Nginx/Apache/Traefik 的 server_name 或 vhost 配置,以及后端应用的域名绑定。
修正代理转发规则、确保 Host 头透传并在应用中对请求域名做容错处理,增加默认虚拟主机日志便于定位异常路由。
结合前端请求、负载均衡与后端应用日志链路,寻找时间戳、请求 ID、返回码和错误堆栈,定位应用处理失败的具体环节。
在服务器上用 tcpdump 或 Wireshark 抓取 443/80 流量,结合 tshark 分析三次握手与 TLS 协商;在应用层使用 curl/traceroute 与日志聚合(ELK、Grafana)做链路追踪。
启用请求链路 ID(例如 X-Request-ID),在各层记录并关联日志,复现请求并逐层查看请求头、后端调用与数据库响应,快速定位 应用层故障排除 的根因。