被 CloudCone 强制换 IP 邮件支配的夜晚：说好的自动化无缝丝滑切换呢
收到 CloudCone 的邮件通知要换IPv4
今天收到 CloudCone 的邮件通知，提醒我机房正在进行 IPv4 的变更，我名下的服务器 IP 需要进行更换：
因为之前在其他服务商那里有过类似的换IP经验，通常流程非常自动化——在控制台确认切换后，服务器会自动做好临时映射，我进入系统确认无误后，在控制台选择重启即可。所以我是抱着轻松愉快的心情操作的，觉得是个几分钟就能搞定的小调整。
登录后台后发现，有两台部署了业务的 Ubuntu 24.04 服务器都在变更名单中（截图时我已经换了一台了）。
开始更换服务器的IPv4
按照面板的提示，这个过程是完全自动化的，只需要点击「Auto Configure New IP」按钮，系统就会自动为我配置服务器内的新IPv4地址，并且在48小时内，旧的IPv4地址和新的IPv4地址都可以使用。这还有啥好说的，看起来是个无脑点按钮的操作，我点。
很快啊，很快，页面就提示我
新的IPv4地址已经在你的服务器内部配置好，并且很快就可以访问。如果从外部
ping不通新IP，请尝试通过旧IP连入VPS，执行ping 103.232.95.1
行，那我先通过尚未失效的旧 IP 连接进 SSH，在系统内部对新网关 103.232.95.1 进行了测试：
ping 103.232.95.1
PING 103.232.95.1 (103.232.95.1) 56(84) bytes of data.
64 bytes from 103.232.95.1: icmp_seq=1 ttl=255 time=0.882 ms
网关响应正常，延迟很低。说明上游路由策略服务商已经下发。但当我尝试在本地直接用新 IP 建立新的 SSH 连接时，终端却还是无响应，最终提示超时：
ssh: connect to host 103.232.95.122 port 22: Connection timed out
从内部能 ping 通网关，但是外部 ping 不通也连不上，既然现在旧 IP 的SSH连接依然在，那我从内部往外 ping 就没啥意义，现在的感觉是系统内部有地方阻断了新 IP 的入站。诶，这就有点头秃了，趁着旧 IP 还有 48 小时的回收缓冲期，开始排查网络状态。
1. 排查服务器网卡路由：说好的自动化更换呢
首先那肯定是排查网卡怎么配置的。运行 ip route show 后，丝毫不意外呢：
default via 142.171.126.1 dev eth0 proto dhcp src 142.171.126.132
显示出来的只有旧网关，不是啥玩意啊，不是说自动换好 IP 了吗？我那么大的新 IP 去哪里了？得，还是要手动换，强行塞入新 IP（注意我的网卡名就是默认的 eth0, 请根据实际情况替换）先用 ip 命令绑个临时的配置试试水
# 给网卡绑上新IP
sudo ip addr add 103.232.95.122/24 dev eth0
# 把新网关也设置上
sudo ip route add 103.232.95.1 dev eth0
再运行ip route show看看情况
default via 142.171.126.132 dev eth0 onlink
default via 103.232.95.1 dev eth0 metric 10
103.232.95.0/24 dev eth0 proto kernel scope link src 103.232.95.122
142.171.126.132/26 dev eth0 proto kernel scope link src 142.171.126.132
我都不好吐槽 Ubuntu 这波算智能还是不智能了，新网关的路由虽然自动给我带了 metric 10，但原本由 cloud-init 生成的旧网关路由（via 142.171.126.132）并没有指定 metric 值啊。在 Linux 的缺省规则下，未指定 metric 的路由会是最高优先级（相当于 metric 0）。
这意味着当本地的连接请求到达新 IP 时，服务器尝试进行返回封包，但路由表强制将所有默认流量传给了旧网关。由于跨网段且上级链路已经变更，旧网关无法正确转发新 IP 的返回封包，导致网络表现为现在这样的状态，单向连通，外部连接超时。
明确原因后，首先在终端里删除旧的默认路由：
sudo ip route del default via 142.171.126.132 dev eth0
唯一的默认路由已正确指向新网关。按理说这时候 CloudCone 更换 IP 的系统层面操作就该结束了，可现实又给我浇了一盆冷水……在本地再次尝试 SSH 连接新 IP，依然提示超时。我去，这我就有点坐不住了，按说这时候服务器该配置的都配置了，为啥啊。
2. 外部依旧超时？原来是上级交换机 ARP 缓存延迟在作妖
现在网卡的路由正确却依旧无法连通，一般是意味着流量在进入服务器之前就被拦截了。
难道我之前设置了什么奇怪的安全配置？我又检查了UFW防火墙和iptables规则，诶，也没啥毛病呀。
我这时候突然想起来，我其实根本没试过能不能用新IP作为出入口访问外网呢。
于是直接ping 8.8.8.8 完犊子，超时了，这可咋整……
诶，之前自动切换完IP时，后台页面提示过我，「如果从外部ping不通新IP，请尝试通过旧IP连入VPS，执行ping 103.232.95.1」他这个操作是在做什么？激活网关？让网关知道我的存在？
灵光一闪，懂了，这应该是想让我手动刷新上级路由吧，这时候虽然新 IP 已经被分配了，但机房上级交换机的 ARP 缓存可能并没有实时刷新，导致流量进入上级路由后，上级路由还不知道 103.232.95.122 此时对应哪一台主机。
为了强制刷新上级路由，最直接的选择就是从服务器内使用 -I 参数，强行指定新 IP 作为源地址持续向外发送数据包，督促上级路由：
ping -I 103.232.95.122 8.8.8.8
前两分钟里，数据包全部超时，直到持续运行到大概第 3 分钟左右，终端开始接收到来自 8.8.8.8 的返回封包了。
经过2分多钟的由内向外的持续请求，终于成功触发了上级交换机的路由刷新。现在从本地电脑再次测试 SSH 连接新 IP，顺利登录。
3. 别指望自动化了，静态配置防止服务器重启后新 IP 失效
之前的改动都是通过 ip 命令临时生效的，如果此时直接重启，那配置就全部丢了。
由于CloudCone使用的是 cloud-init 动态接管，导致 /etc/netplan/ 目录下是空的，真实的动态配置文件躺在内存目录 /run/netplan/ 中。
为了让配置未来在重启后生效，需要写一个高优先级的静态配置文件：
sudo vim /etc/netplan/99-custom-config.yaml
将新 IP 和网关信息静态写入（我这里用的vim，你可以换成你喜欢的编辑器）。
network:
version: 2
renderer: networkd
ethernets:
eth0: # 注意替换为你实际网卡名称
dhcp4: no
addresses:
- 103.232.95.122/24
routes:
- to: default
via: 103.232.95.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
由于 Netplan 对权限有严格限制，顺手修改权限为 600 以免应用时弹出安全警告，随后正式应用配置：
sudo chmod 600 /etc/netplan/99-custom-config.yaml
sudo netplan apply
执行完毕无报错，运行 sudo reboot 重启服务器。
系统重启后，新 IP 依然能够秒连。
搞定，网络层面的切换就算全部完成啦。
总结与后续
这次换个 IP 如此折腾，一次就踩了 Ubuntu Netplan 配置 和机房 ARP 缓存延迟 两个巨坑。
归根到底还是CC这家一贯的风格，便宜归便宜，但是遇到问题自己折腾去吧。
网络通了只是第一步，由于旧 IP 会在 48 小时内彻底失效，后续还需要迁移 Cloudflare 的 DNS 记录、更新 Docker 容器内部的网络绑定，以及修改第三方 API 和另一台服务器上 Telegram 机器人的 IP 访问白名单。明天起床再折腾吧，晚安。
【20260521更新：经过测试新 IP 的解锁流媒体能力下降了，但是网速快了…利好建站和备份用途，对做代理/解锁用途的用户就不太友好了】
顺带一提，CloudCone特价机部分机型补货了
HASHTAG-26-SSD-VPS-2+ 有货，位于 St. Louis, MO（美国中部）
配置 3核心、2GB内存、30GB SSD、4TB流量、1Gb/s带宽，1个 IPv4，$23.5/年（￥160/年）。
购买地址：https://app.cloudcone.com/vps/501/ （链接带AFF） 先充值，后下单（支持支付宝）
zhecydn
2026-06-14 16:25
我也是cc，今天刚换的新ip，但是巧合的是我没有碰到你这个问题，点击配置新ip按钮以后，不一会儿我就可以直接访问新ip了，也可以直接在我cn的电脑中ping通
去年夏天
2026-06-14 16:30
所以有人怀疑CC不是真自动化的，实际是客服手动在后台操作的，不然为啥人少了就设置的快，人多的时候就慢。
starlin
2026-05-30 21:48
我也是cloudcone的服务器，也提示要求我换ip，服务器用来翻墙解锁的，结果特么换完后ip查询跑到澳大利亚去了，而且谷歌gemini显示不在服务地址无法使用了，无也是醉了。确实解锁流媒体能力下降太多，关键网速没感觉有任何提升，不知道我申请重新换一次ip能不能解决。cloudcone的ip和服务太烂了
去年夏天
2026-06-01 11:43
CC可以说就没有服务……
之前他家唯二优势就是：1、便宜。2、线路解锁情况较好。
这IP一换，优势直接少了一个。
junerun
2026-06-16 17:24
道友解决了没？我也是同样问题，提工单三个工作日了，还未回复，gemini不能用/(ㄒoㄒ)/
Hary
2026-05-23 17:47
更新啥正常ip应该不会变的啊，这搞的
wp张
2026-05-22 12:59
该不会是因为机场问题导致要换IP 吧
去年夏天
2026-05-22 14:05
最近不止一个机房要换IP，大家推测可能和上游供应商变化有关
wp张
2026-05-23 09:06
我从机场圈听到的消失是运营商封IP导致机房不得不更换IP
我是军爸
2026-05-21 22:19
最近服务器被换IP很频繁啊，我就碰到了2次，一次是CC，还有就VIR。
去年夏天
2026-05-22 14:33
可不，大家推测和上游供应商有关
石樱灯笼
2026-05-21 14:51
只遇到一次服务商更换IP，因为我服务器的网卡IP是DHCP的所以本质上不需要我操作。
但是那一次更换IP没有发邮件，所以根本不知情，DNS解析都是旧了，业务全炸了。
去年夏天
2026-05-21 15:13
所以我说 CloudCone 的自动化拉跨，后台提示新IP已经就绪，结果 IP 其实没绑进去，能跨网段 ping 通新网关，说明已经做好onlink了，结果 路由表还不赶紧更新。
石樱灯笼
2026-05-21 15:34
所谓的自动化约等于动态路由。
世界上没有几个人能把动态路由配置好。
动态路由基本上就是你在一个粪坑中泻一坨稀的，啥时候风干了啥时候配置完成。手动干预就相当于苍蝇，顶多算个蛆。
去年夏天
2026-05-22 14:32
屎山代码自然是屎山构成的
网友小宋
2026-05-21 13:41
我面板IP还是原来的，域名已经指向新IP了
去年夏天
2026-05-21 14:34
面板按说是还需要改面板设置里的服务器地址，不过也没实际试过不改会如何
阿涛Atao
2026-05-21 12:47
我昨天下午收到邮件我第一时间到cc官网查看并自动更换ip了，也是跟你一样的情况ping不通，然后我就不管，到了晚上居然可以ping通了，
去年夏天
2026-05-21 14:04
感觉就是他们自动化太糟了，正常新加一个IP能要多久嘛，分分钟就搞定了
acevs
2026-05-21 11:15
不错。学习了。
去年夏天
2026-05-21 14:02
互相学习~
obaby
2026-05-21 08:51
这种是bug了吧？一般不应该这么智障
去年夏天
2026-05-21 09:01
CC的问题，他后台说已经自动配置好了其实并没有，最后还是手动绑的IP和网关，这本来也不是什么复杂事，偏偏上游路由的ARP缓存那么久，配置好了还不通，害我研究了半天到底怎么了
匡文成的网络日志
2026-05-21 08:43
看不懂，但很厉害的感觉😁
去年夏天
2026-05-21 09:04
哈哈，有点唬人，其实就是自动配置IP失败，手动配置IP和网关，只是恰好遇到了上游路由ARP缓存的问题。
匡文成的网络日志
2026-05-21 09:06
我对技术一无所知，遇到问题全靠 AI🙃🙃🙃
花非花
2026-05-21 08:24
CC的邮件自动进了我邮箱的垃圾箱，不是看到这文章我都不知道IP换了
去年夏天
2026-05-21 09:03
换吧换吧，他们家最近可真折腾，先是被入侵服务器全部重置，现在又全体换IP（虽然他通知邮件里的意思是部分服务器需要换，但我现在没听说谁不用换的）
花非花
2026-05-21 09:10
换IP前几年已经经历过一次了，上次换后感觉比换前访问要流畅点，现在换新的不知道会怎样
去年夏天
2026-05-21 09:30
确实，昨晚刚换完时网速超级快
织梦岁月
2026-05-21 07:22
哎呀，看下了似乎有点明白，但实际上也没看懂。。幸好我没遇到过这样的情况。
去年夏天
2026-05-21 08:23
哈哈哈，写的有点唬人，就是自动化配置失败，手动配了一下网，只是又遇到了上游交换机的缓存问题。
fengc's Blog
2026-05-21 07:21
虽然看不懂，但感觉好折腾😂
去年夏天
2026-05-21 08:57
其实不算上游路由的ARP延迟，就是个正常的手动配置IP和网关的过程……