1. 定义问题范围与初步信息收集

步骤：1) 确认“连接已重置（connection reset）”的触发时段、频率、受影响服务与客户端分布；2) 收集受影响时间段的服务端日志（/var/log/syslog、nginx/error.log、应用日志）；3) 用 ss -tanp 和 netstat -anp 快照当前连接状态并保存：sudo ss -s; sudo ss -tanp > /root/ss_before.txt。

2. 基础网络连通性与路径检测

小分段：1) 使用 ping 与 mtr 测试从客户端到服务器的延迟与丢包：mtr -rw 客户端IP 或 mtr -rw 目标域名；2) traceroute/tracert 确认中间路由路径：traceroute -n 目标IP；3) 若存在跨境链路（大陆→香港），记录具体跳数和高丢点，作为后续向运营商/云商的证据。

3. 抓包定位重置原因（必须步骤，越早越好）

小分段：1) 在服务器上用 tcpdump 抓取重置发生时的流量：sudo tcpdump -i eth0 -s 0 -w /root/reset.pcap 'tcp and (tcp[13] & 0x04 != 0 or tcp[tcpflags] & tcp-rst != 0)'; 2) 用 Wireshark 或 tshark 分析 SYN/ACK/RST/FIN 序列，确认是服务器发出的 RST 还是中间设备或客户端发出；3) 若为 TLS 连接，抓取 ClientHello/ServerHello 能帮助辨别握手失败。

4. 检查服务器内核/驱动与网卡设置（常见原因）

小分段：1) 查看 dmesg 是否有网卡重置/驱动报错：dmesg | egrep -i 'eth|net|link|reset'; 2) 关闭网卡 offload（测试是否解决）：sudo ethtool -K eth0 gro off gso off tso off；3) 检查并更新网卡驱动，必要时联系云厂商或更换实例规格；4) 查看 /proc/interrupts 是否有中断风暴。

5. 防火墙、负载均衡与中间设备校验

小分段：1) 列出 iptables/nftables 规则并检查是否有短连接/timeout 策略：sudo iptables -L -n -v --line-numbers；2) 检查 conntrack 表是否满：sudo cat /proc/sys/net/netfilter/nf_conntrack_count 和 nf_conntrack_max，必要时增大：sudo sysctl -w net.netfilter.nf_conntrack_max=262144；3) 在有 HAProxy/Nginx/LVS 的环境核对超时配置（proxy_read_timeout、timeout client、tcp-check 等）。

6. TCP 与系统级参数优化（建议写入 /etc/sysctl.conf）

小分段：1) 临时测试以下参数，确认对连接稳定性影响：sudo sysctl -w net.ipv4.tcp_keepalive_time=300; sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60; sudo sysctl -w net.ipv4.tcp_keepalive_probes=5;2) 调整重试与超时：net.ipv4.tcp_retries2=8（减少长期半开连接）；3) 将变更写入 /etc/sysctl.conf 并执行 sudo sysctl -p。

7. 应用层与代理配置建议（减少被外部重置概率）

小分段：1) nginx/应用后端设置长连接保活并适当加超时：keepalive_timeout 65，proxy_read_timeout、proxy_send_timeout 根据业务调整；2) 对 HTTP/2 或 websocket 保活进行专项测试，必要时降级到 HTTP/1.1 以排查协议问题；3) 在应用端实现 TCP keepalive 或定期心跳。

8. 长期监控、告警与自动化运维规范

小分段：1) 建立专用监控项：连接重置率、RST 包比率、conntrack 使用率、网卡错误计数；2) 使用 Prometheus + Alertmanager + Grafana，设定阈值并自动开 ticket；3) 编写 Ansible playbook 管理 sysctl、iptables、ethtool 等配置，实现配置一致性与可回滚。

9. 变更管理与应急演练（运维流程化）

小分段：1) 所有调整必须通过变更单，包含回滚步骤与影响范围；2) 定期进行应急演练（例如模拟高连接、丢包、MTU异常），并记录恢复时间与根因；3) 与香港云/网络供应商建立 NOC 联系流程与 SLA 评估，必要时升级链路或更换区域。

10. 问：如何判断“连接已重置”是服务器端还是网络中间设备导致？

答案：通过抓包判断 RST 包来源：在服务器抓包（tcpdump）看 RST 的源MAC和源IP；若 RST 源自服务器进程（pid 可在 ss -tanp 中看到），则为服务器应用或内核生成；若 RST 来自中间设备或网关，则抓包会显示不同的源地址，或在 mtr/traceroute 中出现丢包点。

11. 问：调整 conntrack、tcp_keepalive 会不会导致其他问题？

答案：可能会影响系统资源和连接寿命。增大 conntrack_max 会占用更多内存；降低 tcp_retries2 会使长时间无响应的连接更快释放。建议先在预生产逐步验证，再写入变更单并监控内存/连接数等指标。

12. 问：部署规范后如何做长期验证与回归监测？

答案：制定周期性验证计划：1) 每日/每周自动跑 mtr/ping 到关键客户端并保存历史；2) 用黑盒探测（Prometheus blackbox-exporter）验证 HTTP/TCP 握手成功率；3) 每次变更后做 48-72 小时的回归观察，保存抓包与日志作为比对依据。

来源：针对香港服务器 连接已重置的持久性问题制定长期运维规范