香港自建机房速度问题诊断清单与快速修复方案

本文直接告诉你如何在90分钟内排查并恢复香港自建机房的“慢”的问题，并附带优先级清单和可落地步骤。我们聚焦：链路质量、路由策略、主机与中间件、并发与攻防场景。阅读后，你会获得一套可执行的排查路径与短中长期修复建议。

一、首诊速查表：90分钟定位关键点

这部分给出一个可在90分钟内完成的核查清单，覆盖链路、路由、服务器与应用层四大面向，确保排查有序且高效。

• 确认影响范围：单实例、子网、还是全网段？
• 链路检测：使用mtr/traceroute确认丢包与跳点延时。
• 路由策略：查看BGP表、社区标记与本地优先级（localpref）。
• 带宽与拥塞：核对端口利用率、队列丢包、SYN队列与tcp_retransmit。
• 主机与中间件：硬盘I/O、CPU steal、数据库慢查询与连接池耗尽。
• 外部因素：CDN回源延迟、ISP抖动、海缆维护窗口。

在实际项目落地中，这张清单常被当作“快速闸门”，先关掉影响最大的环节，再逐项细查，下一节将把这些项拆成可执行的检测命令与阈值。

二、链路与传输层检测（第一时间要看的3项）

链路层先查丢包与抖动，传输层看重传与窗口；三项核心检测可在15分钟内判断是否为链路问题。

1) 使用mtr/traceroute确认丢包与瓶颈节点

先跑mtr到受影响IP，观察中间跳点的丢包率与延时峰值，若某跳丢包持续>1%且延时拉高，说明链路或ISP侧问题。我们经常看到香港出口到中国大陆的跳点在高峰期出现抖动，表现为间歇性丢包。

建议：将mtr结果导出做对比，记录时间窗并提交给上游ISP；这能快速定位是否需要切换BGP策略或临时走备用链路。下一步需要看协议层重传情况。

2) tcpdump + ss看重传与窗口问题

抓包观察tcp retransmit、keepalive丢包、窗口缩小（snd_wnd/rcv_wnd）等指标；重传高且RTT不稳定，多为中间链路或丢包引发。实操中，数据库到应用层的长连接经常因网络中断触发大量重连。

操作要点：在高流量时段抓10秒级别样本，重点看SYN/ACK交互与重复ACK；如发现大量复ACK，尽快协调链路或调整TCP拥塞策略（例如tcp_congestion_control调整）。这将引到路由与BGP策略调整。

3) 带宽饱和与队列丢包（interface counters）

检查交换机/路由器端口利用率、输出队列长度、drops与errors；端口利用率持续走满常伴随延迟陡增，队列丢包表现为应用层超时。

建议：若是短时突发，先开启流量限制或丢弃策略（policing/shaping）；若是长期饱和，考虑扩容或短期走备链。接下来要看路由是否将流量引向次优路径。

三、路由与BGP策略检查（为什么流量走了“慢”路）

路由问题常把流量引到绕行路径；检查BGP邻居、AS PATH、localpref与社区标记，能快速判断是否需要调整出口策略。

1) BGP邻居状态与AS PATH异常

查看BGP邻居是否flap、AS PATH是否被洗牌或出现异常长路由；在香港，海缆切换或ISP故障会导致路径走欧洲或美洲，RTT陡增。

在实际场景里，我们遇到过BGP社区被错误打标导致公网入口被优先选择了成本更低但延迟更高的链路，这种情况应立即调整localpref或撤销社区标记。接下来判断是否需要做流量旁路。

2) 优先级与出网策略（Localpref/Prepends）

通过修改localpref提升优选线路，或用AS-path prepend将不希望的路由“拉低”优先级；短时间内可通过这些手段把流量拉回快速路径。

注意：频繁改动会影响全球收敛，在夜间低峰期先做小批量测试。若需要长期方案，则在下一节讨论冗余与CDN回源优化。

四、应用与主机层快速排查（数据库、Nginx、连接池）

应用层瓶颈往往被误判为网络问题；检查CPU steal、I/O等待、数据库慢查询与连接池耗尽，能帮你排出伪网络故障。

1) 主机资源与内核参数

查看top/iostat、vmstat，关注CPU steal和iowait；核查tcp_tw_reuse、net.core.somaxconn、file-max等内核参数是否达上限。我们的经验是，容器化环境里cgroup限速会把延迟放大成“不可解释”的慢。

快速处理：短期扩容实例或重启服务；中期调整内核参数并优化I/O路径。这样能避免将主机问题误判为链路问题，接下来看中间件状态。

2) Nginx/负载均衡与后端连接池

查看nginx的active connections、upstream响应时间、502/504比例，确认是否为后端超时或连接池耗尽导致前端表现为慢。同一时段的慢请求如果集中在某个upstream实例，说明后端资源成为瓶颈。

应对方法：调整负载均衡权重、增加健康检查频率、扩展后端或使用限流（rate limit）策略。接下来会讲安全与攻击侧的快速识别方法。

五、DDoS与安全事件的快速识别与缓解

当流量异常与资源耗尽同时发生时，优先排查是否遭遇DDoS或CC攻击；识别阶段看流量分布、源IP集中度与请求特征。

1) 流量清洗与高防IP临时启用

若发现源IP高度集中或请求按固定模式重复，应在短期内启用清洗服务或切换到高防IP；香港机房通常支持BGP社区一键切换到清洗节点。

在实际项目中，不少同行反馈：临时把回源流量走到清洗厂商，能在10–30分钟内把服务恢复到可访问状态。接下来评估是否需要长期高防方案。

2) 应用侧速率限制与WAF规则快速落地

通过nginx限流、WAF白名单/黑名单、登录验证码等手段迅速阻断应用层攻击；这些措施代价低、见效快，有时比换链路更高效。

务必在恢复后做溯源与日志留存，以便后续取证和长期防护策略制定。下一部分给出短中长期修复与优化清单。

六、修复优先级与长期优化路线图（可落地清单）

把问题按“立即修复/短期改进/长期改造”分类，给予优先级与预估时间，确保修复有闭环并可度量效果。

1. 立即（0–2小时）：切到备用链路、启用清洗、增加后端实例。
2. 短期（1–7天）：调整BGP localpref、优化tcp参数、修复慢查询、加装监控告警。
3. 长期（1–3个月）：多线冗余、部署边缘回源CDN、建立流量分发策略与自动化脚本。

我们在多家香港机房项目中验证过：将“立即修复”列表优先完成后，可把SLA恢复率提升至原来的90%以上。下面附可直接复用的Checklist。

七>可执行Checklist：90分钟排查与30天优化清单

下面是一份可打印、直接操作的CheckList，按优先级与执行人分配，便于团队快速响应和闭环。

• 90分钟排查：mtr/traceroute、tcpdump（10s）、interface counters、BGP邻居、主机top/iostat、nginx status
• 24小时操单：提交ISP工单（含mtr附件）、临时切流/清洗、扩容后端
• 7天计划：BGP策略优化、内核参数调优、慢查询优化、WAF规则固化
• 30天目标：多ISP备案、自动化切流脚本、SLA监控面板

下一步行动：把这份Checklist导入你的故障响应流程，指定值班人并演练一次切流与清洗流程，能显著缩短下次故障的恢复时间。

结语与落地建议

若要把速度稳定做成常态，必须把“应急手册”变为“自动化策略”：故障检测→预定义切流→自动报警→事后根因分析。我们建议先把90分钟清单写进SOP，然后逐步实现自动化。

可复制的下一步：1）今天导出一次mtr与BGP表作为baseline；2）在非高峰做一次BGP localpref演练；3）把Checklist放入值班看板并完成一次桌面演练。

来源：香港自建机房速度问题诊断清单与快速修复方案