先把问题讲清楚：网络故障其实是什么样的“病”
把网络想成邮局系统：请求是信，服务器是收信人，路由器和中间设备是邮路。报错代码就像邮局返回的理由条——有的说“地址错了”（DNS或404），有的说“收信人没回应”（超时或连接被拒绝），有的说“信被篡改或不被信任”（TLS证书问题）。懂了这个比记代码更重要，接下来我们以类别讲解并给出可操作的检查与修复步骤。
如何阅读这份对照表（快速上手）
- 先看表现：页面空白、长时间转圈、直接报错、还是断连重连？
- 再看场景：是浏览器、App、还是服务器间调用？移动网络还是局域网？
- 最后看日志与抓包：HTTP响应、socket错误码、DNS返回、TLS握手日志、tcpdump 都重要。
- 小提示：先从客户端到服务器逐层排查（应用层→传输层→网络层→链路层）。
常见错误类别总览
- HTTP 状态码（1xx-5xx）
- DNS 错误（NXDOMAIN / SERVFAIL / TIMEOUT 等）
- Socket / TCP 错误（ECONNREFUSED、ETIMEDOUT、ECONNRESET 等）
- TLS/SSL 相关（证书验证失败、握手失败）
- WebSocket 关闭码（1000、1006 等）
- 移动网络与运营商相关错误（信号弱、切换导致断连）
- 路由器 / NAT / 防火墙 导致的端口或连通性问题
HTTP 状态码对照表（常见且实用）
| 代码 | 含义 | 典型成因 | 快速排查/修复 |
| 200 | 成功 | 正常响应 | 确认内容是否正确，检查缓存与CDN |
| 301 / 302 | 永久/临时重定向 | 服务器配置或路由规则 | 检查Location头，确认重定向循环或错误 |
| 400 | Bad Request | 请求格式不对、参数缺失 | 检查请求URL、Header、Body；对开发日志打点 |
| 401 | Unauthorized | 认证失败或Token过期 | 确认认证流程、刷新Token、检查时间同步 |
| 403 | Forbidden | 权限不足或防火墙拒绝 | 检查ACL、WAF 规则、CORS 配置 |
| 404 | Not Found | 资源不存在或路径错误 | 核对URL、路由规则、静态文件路径 |
| 408 | Request Timeout | 客户端或中间设备超时 | 优化网络、增大超时阈值、查看中间代理 |
| 429 | Too Many Requests | 限流或速率限制触发 | 查看限流策略、做退避重试 |
| 500 | Internal Server Error | 代码异常或资源耗尽 | 查看服务器日志、监控、回滚或修复bug |
| 502 | Bad Gateway | 上游服务不可用或负载均衡问题 | 检查上游服务健康、LB 配置与超时 |
| 503 | Service Unavailable | 服务临时不可用、维护或资源耗尽 | 查看实例健康、扩容、限流或熔断 |
| 504 | Gateway Timeout | 上游超时或链路延迟 | 调整超时、优化上游响应、网络探测 |
DNS 错误与对策
DNS 相当于地址本，解析失败就找不到“家”。
| 错误 | 含义 | 常见原因 | 排查/修复 |
| NXDOMAIN | 域名不存在 | 域名拼写、未注册或解析记录被删除 | nslookup/dig 检查，确认域名与解析A/AAAA记录 |
| SERVFAIL | 服务器返回失败 | 递归解析器问题、上游DNS故障或配置错误 | 换用可靠DNS（8.8.8.8 等），检查域名服务商 |
| REFUSED | 解析被拒绝 | DNS 服务限制或防火墙阻断 | 检查DNS服务器访问控制与防火墙 |
| TIMEOUT | 响应超时 | 网络丢包、DNS服务器不可达 | ping/trace到DNS服务器，确认网络连通 |
常见 Socket / TCP 错误（系统级）
这些通常是操作系统层面返回的错误码，能直接指示连接的问题类型。
| 错误码 | 含义 | 原因 | 处理要点 |
| ECONNREFUSED | 连接被拒绝 | 目标端口未监听、防火墙或服务未启动 | 确认服务监听端口、检查防火墙与安全组 |
| ETIMEDOUT / EHOSTUNREACH | 连接超时/主机不可达 | 网络中断、路由问题或服务器不可达 | traceroute、ping、查看路由表与链路 |
| ECONNRESET | 连接被对端重置 | 对端主动断开、协议不匹配或中间设备干预 | 检查服务器日志、协议与负载均衡器设置 |
| ENETUNREACH | 网络不可达 | 本地网络配置或上游链路问题 | 检查网关、路由与本地网络配置 |
| EADDRINUSE | 地址已被占用 | 端口冲突、进程未释放端口 | 关闭占用进程，或使用端口复用/随机端口 |
TLS / SSL 常见故障（安全层）
TLS 就像信封加密与签名，失败通常表示证书、信任链或协议不匹配。
- CERTIFICATE_VERIFY_FAILED：证书链不完整或不受信任。检查证书链 (leaf → intermediate → root)，确保根证书在信任库里，证书未过期。
- HOSTNAME MISMATCH：证书的主机名与访问域名不符。确保证书包含访问的域名（SAN 或 CN）。
- HANDSHAKE_FAILURE：协议或加密套件不支持。检查客户端/服务器支持的 TLS 版本与套件，关注 TLS1.0/1.1 的弃用。
- OCSP/CRL 失败：证书撤销检查失败或被阻断。确认 OCSP/CRL 可达或使用短期证书策略。
诊断工具：openssl s_client -connect host:443 -servername domain（查看握手信息、证书链与协商套件）。
WebSocket 常见关闭码
| 代码 | 含义 | 常见原因 |
| 1000 | 正常关闭 | 应用主动正常断开 |
| 1001 | 对端离开/断开 | 服务器重启、浏览器关闭、网络切换 |
| 1006 | 异常关闭（无法在应用层捕获） | 网络断连、代理或防火墙中断 |
| 1002 | 协议错误 | 帧格式错误或应用协议不匹配 |
| 1011 | 服务器内部错误 | 处理异常或资源耗尽 |
移动网络常见问题（2G/3G/4G/5G 环境）
移动网络的不稳定性常由信号、切换与运营商策略造成：
- 信号弱导致高丢包与高时延 → 测速、查看RSSI、切换到更稳定网络（Wi‑Fi）测试。
- 基站切换（handovers）导致短时断连 → App 需做重连与状态保存。
- 运营商 NAT / CGN（Carrier Grade NAT）造成端到端连通性问题 → 使用 STUN/TURN 或服务器中继。
- 封包被运营商劫持或限速 → 对比不同运营商、使用 VPN 作对照。
设备与路由器常见故障
- 双重 NAT 导致端口映射失败：检查家庭网络与上游运营商是否都做了 NAT。
- 端口被 ISP 或企业防火墙阻止：用 telnet host port / nmap 测试端口连通。
- 路由表错误或 MTU 设置不当导致分片问题：尝试降低 MTU（如 1400）测试。
逐步排查流程（可打印的清单）
- 重现问题并记录时间、客户端类型、网络环境（Wi‑Fi/移动/有线）。
- 收集客户端日志、浏览器控制台网络标签、App 的错误码与堆栈。
- 从客户端执行简单探测：ping、traceroute（或 tracert）、nslookup/dig、curl -v。
- 在服务器端查看访问日志、应用日志、负载均衡/代理日志和监控指标（CPU、内存、网络）。
- 抓包（tcpdump/wireshark）定位丢包、RST、FIN、TLS 握手失败点。
- 如果是链路问题，测试替代路径（更换DNS、VPN或不同运营商）。
- 修复后验证：多次重试、不同地域、不同设备确认问题彻底解决。
常用命令与如何解读输出
- ping host：测延迟与丢包。丢包高说明链路质量差。
- traceroute host / tracert：定位哪个跃点延迟或丢包。
- nslookup / dig domain：检查域名解析与TTL。
- curl -v https://host：查看HTTP头、重定向、TLS信息。
- openssl s_client -connect host:443 -servername domain：查看证书链与协商套件。
- tcpdump -i any host x.x.x.x and port 443：抓取相关流量用于wireshark分析。
一些实战小技巧（顺口溜式记忆）
- 网页 4xx 看请求，5xx 看服务器；
- 连不上先 ping，再 traceroute，看链路；
- 证书报错先看时间与域名，再看链；
- 移动网络报错先怀疑信号与运营商，再怀疑服务端。
案例演示（帮你把抽象变具体）
举个常见例子：用户在移动网络下访问 API 报 504（网关超时）。排查顺序通常是：
- 复现环境：确认只在移动网络出现还是 Wi‑Fi 也有。
- 客户端 curl -v 测试，记录时间戳与请求ID。
- 在边缘网关查看是否有大量排队或上游服务超时日志。
- traceroute 到边缘网关检查是否有丢包或跃点异常。
- 如果上游服务响应变慢，查监控看是否 CPU/IO 耗尽或 DB 慢查询。
- 临时修复可以提升超时阈值、降级或做请求限流；长期要优化上游性能或做缓存。
这种循序渐进的排查，避免了一开始就盲目改代码或重启服务器。
日志与监控要点（什么必须记录）
- 请求ID/TraceID：跨服务追踪必备。
- 客户端环境信息：App 版本、系统版本、网络类型、运营商。
- 时间戳与耗时：方便对比与定位高耗时环节。
- 错误栈与完整响应头：尤其是 Location、Set‑Cookie、WWW‑Authenticate。
- 健康检查与上游服务状态：配合告警避免延迟扩大。
总结要点（记在脑子里，而不是死记代码）
- 把网络故障分层看：应用→传输→网络→链路。
- 重现、收集证据、定位、修复、验证。按步骤永远比乱试更快。
- 常见工具是你的好朋友：ping、traceroute、dig/nslookup、curl、openssl、tcpdump。
- 日志和 TraceID 是关键——没有它，排查就像找针。
嗯，好啦，这些是我常用的对照和流程，先把这些基本套路记住，遇到具体报错可以带着代码和抓包我再帮你逐条看。下次如果你能贴出报错日志片段（时间、RequestID、抓包摘要），我们可以更快地把问题钉死。