
1、关键摘要:先抓取基础连通性信息(ping/traceroute/路由)+面板与服务日志,再给供应商看tcpdump或pcap,能把恢复时间从“无法判断”压缩为“可执行动作”。
2、优先级:先证明是链路/路由问题还是服务器本身(网络接口/防火墙/内核)。供应商只接受可复现的数据,空口白话只会拖延。
3、交付物:时间戳、公网IP、ASN、traceroute全量、mtr或ping的丢包与延迟曲线、服务器网卡状态与面板日志、tcpdump样本和压缩包(tar.gz)。
作为一名有多年运维与安全背景的作者,我要直接告诉你:在与供应商沟通时,最致命的错误是“只说断网,不给证据”。下面这份清单是你该在第一时间准备并发送的诊断信息,格式化清楚、证据确凿,会让对方当场行动。
先收集基础信息:服务器公网IP(例:203.x.x.x)、提供商机房(例如香港)、实例ID、操作系统版本、宝塔面板版本。附上最近一次重启时间(uname -a & uptime)与当前时间戳,让供应商能对应日志窗口。
执行连通性测试:本地或第三方VPS对目标服务器做ping(建议5-10秒间隔,持续60秒),并保存输出;执行traceroute -n或tracepath,将全跳数输出(从源到目的的每跳IP与延迟)。如果可以,请同时运行mtr -r -c 100做连续丢包统计。
抓取服务器端网络状态:在服务器上运行并保存以下命令输出:
ip addr show; ip route show; ss -tunlp; netstat -rn; ethtool eth0 或 ifconfig eth0; dmesg | tail -n 200
检查防火墙与安全策略:输出
iptables -L -n -v(或 nft list ruleset);ufw status verbose;/etc/hosts.allow 与 /etc/hosts.deny。若使用宝塔面板,请导出面板防火墙规则并保存面板日志(默认路径通常为 /www/server/panel/logs/panel.log)。
服务与应用日志:web 服务(nginx/apache)日志路径通常在 /www/wwwlogs;PHP-FPM、MySQL(或MariaDB)也需截图状态和错误日志。说明某端口是否处于TIME_WAIT或被重复泄露也很关键。
抓包证据是金牌:在断网时间窗口内采集tcpdump(或tshark)片段,例如:
tcpdump -i eth0 -n host 203.x.x.x and \(icmp or tcp port 80 or port 443\) -c 1000 -w /root/capture.pcap
截取前后各几分钟的pcap并压缩发送(tar -czf capture.tgz capture.pcap)。如果数据量过大,过滤到目的端口或ICMP即可。
路由与BGP信息:如果你有异地VPS或公网BGP工具,抓取从多个地区的traceroute;记录你的公网IP的ASN(whois 查询),并把这些信息发给供应商,提示可能是上游链路或BGP策略导致。
MTU与碎片问题:若有特定路由或VPN,检查 MTU(ip link show dev eth0;ping -M do -s 1472 -c 3 8.8.8.8)来排除大包被丢弃的情况。
如何组织并发送给供应商(模板要点):时间(UTC+时区)、公网IP、影响范围(全部流量还是仅特定端口)、重现步骤、已尝试动作(重启网络/重启面板/关闭防火墙),附上压缩包(日志/pcap/命令输出)。清晰的目录结构示例:report_YYYYMMDD/{commands.txt, traceroute.txt, mtr.csv, capture.tgz, panel.log}。
若对方要求远程调试权限:只授权临时SSH密钥或开启堡垒主机,记录所有会话并要求写明操作范围。不要在未确认对方身份时直接提供root密码。
应急缓解措施(短期可用):- 通过控制面板尝试重启网络服务或整个实例;- 切换到备份公网IP或弹性IP;- 临时开启端口映射或利用另一个节点做反向代理。所有操作都应记录并告知供应商。
最后,给供应商的“冲击”证据要一目了然:把关键截图(traceroute 丢包位置、tcpdump 显示链路丢包或RST、服务端网卡报错)放在报告最前面,并用红色标注(邮件正文)指出怀疑点:上游链路、黑洞路由、机房交换故障或防火墙误拦截。
总结:当你的宝塔管理的香港服务器断网时,准备好时间戳、IP/ASN、traceroute/mtr、服务器网络状态、面板与服务日志、tcpdump 样本,这是你能立刻交付给供应商的“可执行诊断包”。有了这些,供应商要么快速修复,要么给出确切的排查方向——这才是真正的效率。