服务器搬新家后网络变慢?排查思路与 IPv6 避坑指南
最近入手了一台刚换机房的 VPS,本想着新环境新气象,结果一上手就给我来了个“下马威”。这台机器的网速简直让人抓狂,别说跑满带宽了,连最基本的系统更新都费劲。
今天就借着这个踩坑经历,跟大家聊聊服务器搬新家后遇到网络拉胯时的排查思路,特别是那个容易被忽视的“元凶”——IPv6。
终端显示 apt update 连接超时的报错信息
🚨 故障现象:连不上网还是网太慢?
刚拿到 Root 权限,我习惯性先跑个 apt update 升级一下包。结果就出现了下面这种令人窒息的画面:
终端里一直在重复尝试连接 http://security.debian.org 和 http://deb.debian.org,一会儿显示 Get,一会儿又是 Ign(忽略),最后直接报错 Connection timed out,IP 地址显示为 151.101.x.x。
编辑 sysctl.conf 文件以永久禁用 IPv6
整个更新过程卡了足足两分钟才勉强通过部分请求。这显然不是正常的服务器延迟,更像是某种深层的网络协议“打架”了。
为了验证是不是个例,我又装了经典的 speedtest-cli 想测个速。结果更离谱,直接报错:
Error: [0] Cannot open socket
Latency: FAILED
这就很尴尬了,既然 SSH 能连上去,说明 TCP 连接没问题,但为什么 HTTP 请求和 Socket 测速全都废了?
🔍 问题根源:IPv6 的优先级陷阱
在社区发帖求助后,有大佬一针见血地指出:“你把 IPv6 禁用掉试试。”
这确实是老司机的经验之谈。很多 VPS 商家在机房迁移后,会默认开启或重新分配 IPv6 地址。虽然听起来是加量不加价的好事,但在实际网络环境中,往往会引发“双栈优先级”问题。
很多 Linux 发行版在网络配置中,默认会优先尝试使用 IPv6 进行连接。如果新机房的 IPv6 路由配置不完善,或者上游对 IPv6 的支持糟糕(比如常见的丢包、高延迟甚至连通性问题),系统就会死磕 IPv6 地址,直到超时失败后,才肯降级去用 IPv4。
这就解释了为什么我的 apt update 会反复超时——它在等 IPv6 响应,而 speedtest 脚本也可能因为双栈解析混乱导致 Socket 无法正确初始化。
🛠️ 实操解决方案
既然锁定了嫌疑对象,解决办法主要有两种,一种是彻底关闭 IPv6,一种是强制使用 IPv4。建议大家按需选择。
方法一:通过 sysctl 临时或永久禁用 IPv6
如果你确定当前业务不需要用到 IPv6,一劳永逸的方法是直接关掉它。
临时关闭(重启后失效): 在终端执行以下命令:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=1
执行完立刻再试一次 apt update 或 curl,你会惊讶地发现速度瞬间起飞。
永久关闭:
编辑 /etc/sysctl.conf 文件,添加或修改以下内容:
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
保存后执行 sysctl -p 使配置生效。这样哪怕机器重启,也不会再被 IPv6 拖后腿了。
方法二:强制命令使用 IPv4
如果你还需要保留 IPv6 地址(比如用于某些特定服务),但又想避开它对日常运维的影响,可以在关键命令上强制指定 IPv4。
例如,更新软件源时只走 IPv4:
apt -o Acquire::ForceIPv4=true update
或者在使用 wget、curl 时加上参数:
curl -4 https://www.google.com
wget -4 https://example.com/file.zip
对于 speedtest-cli,通常也可以指定服务器或检查脚本是否在双栈环境下解析异常,必要时可以通过修改 /etc/gai.conf 来调整地址解析的优先级,不过这就比较进阶了,一般人用第一种方法足以解决 99% 的问题。
💡 写在最后
服务器换机房后的网络问题,往往不一定是带宽缩水,更多时候是网络栈层面的配置冲突。尤其是当你看到类似 Connection timed out 但 SSH 还能连的时候,第一反应不应该是去骂商家,而是先查查是不是 IPv6 在“捣乱”。
希望这篇排查笔记能帮到遇到类似情况的朋友,毕竟时间就是金钱,别让这些小配置浪费了我们宝贵的摸鱼时光。

评论已关闭