CloudCone的鬼才运营：提前 10 小时通知“机房物理搬迁”，还说不服不给退款？

直接给我气笑了的通知邮件

今天早上一上班，邮箱里突然躺进了一封来自 CloudCone 的邮件，标题写着：[Important Notice] Scheduled Collocation Migration Details。

幸亏点开时我没喝水，点进去一看，直接直接给我气笑了。

CloudCone 宣布要对洛杉矶机房的所有 VPS 进行物理机房迁移。注意，这可不是什么热迁移，也不是内网数据同步，而是“物理意义上的搬家”：邮件里说他们要把 200 多个服务器机架及相关硬件在物理意义上的拆走、打包、运输到新机房，然后重新上架、接线、通电、配置环境。

机房物理搬迁服务器没啥稀奇的，关键是他们给出的搬家时间和通知时间。

只留 10 小时准备时间的“突袭”搬迁

你们看啊
我收到邮件的时间是北京时间（UTC+8）7 月 7 日 22:39。
折算成机房所在的太平洋时间（PST/PDT），大概是 7 月 7 日上午 07:39。

那他们计划什么时候开始切断电源呢？
邮件里写着：05:00 PM PST 准时开始断电，05:30 PM 开始物理下架。
也就是说，从他们发出这封“重要通知”到正式拔掉服务器电源，中间一共只给我留了不到 10 个小时时间。对于他们来说是当天早上7点半上班时发通知邮件，当前5点下班就拔电源搬家。

对于身处东八区的我们来说，他们断电的时间（PST 17:00），是我们这边的次日（7月8日）早上 9点左右。合着我昨晚没有在深夜修仙，保持了健康作息的行为，导致在我完全不知情的情况下，在新一天要面对一个已经断电、正在被塞进卡车里运输的服务器。

更何况，这还不是一次短暂的服务中断。CloudCone 在邮件的 FAQ 里也说了：由于涉及 200 多个服务器的物理搬迁，整套流程走完，预计的宕机时间可能长达 24 小时。（以我对他们运维水平的了解，24小时肯定搞不定）

这可是动辄两百多个机柜的机房整体大搬迁啊！合同的谈判、新机房的准备、物流的对接，这些流程少说也得提前几周甚至几个月准备，绝对不可能是发通知的当天一拍脑门才谈好的。

既然早有搬迁计划，提前一周甚至三天发个通知，在流程上有任何难度吗？没有！

那我不禁要用最大的恶意揣测一下了：难道是因为害怕提前通知了，大家一听说要断电停机 24 小时，纷纷选择退款、关机、把业务迁到竞争对手那里，导致用户大面积流失吧？所以才故意拖到当天、只留 10 个小时，搞一场“闪电突袭式”搬家。这点时间，用户连找个新 VPS、把几十上百 G 的数据同步过去的时间都不够。用极限时间“绑架”用户的数据，不给用户备份数据的时间，从而堵死了任何迁移数据走人的可能性。

流氓条款：不接受迁移？那正好，你自己走吧，不退款！

翻开他们在邮件里的 FAQ 第 5 条：

Q: What happens if I choose not to proceed with the migration?

Unfortunately, if you do not wish to continue with the migration, the user would have to cancel the service without a refund. Please note that this migration does not breach the service location promise, as your service will remain hosted within the city of Los Angeles, USA, within a brand new state-of-the-art data center facility.

大意是说：如果你不希望服务被迁移，那不好意思，你只能自己去后台取消服务，而且我们一分钱都不会退给你，因为我们进行服务器搬迁并没有违约，反倒是你提前终止服务违约了。

明明是 CloudCone 单方面无法履行原有的服务协议，结果用户不想受这窝囊气、想退款走人居然成了“用户主动取消”。这逻辑高低得是个商业鬼才才能写得出来：

1. 用 10 个小时的极限时间差逼我来不及转出数据。（我只能忍着起码一天一夜的停机和硬件损坏风险任由他们折腾）
2. 用“不予退款”的流氓条款直接扣下我机器的剩余价值。（要么我自己走人，白送他们剩余的租金。）

反正不管怎样，CloudCone 横竖不亏。

作为一家主打高性价比的 VPS 服务商，大家平时对 CloudCone 的网络偶尔抽风啊、机器性能一般啊、工单回复极慢啊，也都有心理预期，毕竟价格摆在那里是不，要啥自行车。
但“便宜”不等于可以把运维和运营视作儿戏吧。如此巨大的基础设施的物理迁移行为，在业界，提前一周乃至一个月通知、并提供多次进度提醒是基本常识。像这样“早上上班发通知、下班就拔线、搬车拉走”的粗暴作风，真配得的上“鬼才运营”的称号。

别赌阿三服务商的人品，跨平台异地备份才是硬道理

自从上次他们被黑导致所有服务器都被格式化之后，我就把能搬走的服务都搬走了，自用的只剩下一台大盘鸡（还有两台是帮人代购代运维的），因为我实在找不到其他的，能给这么大硬盘和内存还1年只要我 20 多刀的 VPS 了。

哎，这次事件也算是再次提醒了我们这些独立开发者和站长：永远不要把鸡蛋放在同一个篮子里，更不要对高性价比主机的在线率抱有任何期待。 自动化的异地跨服务商备份是必须要搞的。毕竟你永远不知道，你的服务商会不会在某个夜黑风高夜，只留给你 9 个多小时，然后把你整台服务器抗在肩上连夜跑路搬家了。

PS：以后标题图是AI画的这件事，就不单独写AI辅助创作声明了，这些图一看也不可能是我自己画的

更新一下吐槽

• 好消息：现在是20260708 23:00，他们在晚上20:00左右完成了对我小鸡所在服务器的搬家，并启动了服务器，我的小鸡已经恢复运行了。（根据他们的状态页，还有机器没上线）
• 坏消息：上游交换机配置有问题，他们还在修，1、IPv6 是残废状态，封包能进不能出。2、上游估计比之前套多了一层隧道或者上游交换机的 MSS 自动修改没开，导致小鸡以默认的 MTU = 1500 发包时，会因为包过大而发不出去。所以我只能自己手动配置网卡把 IPv6 关了、MTU 调到 1420 。还是熟悉的一言难尽的运维技术水平。
• 绝了，居然还没彻底修好，收到了 CloudCone 的邮件，建议用户执行ip link set dev eth0 mtu 1400，这不是进入交换机，把 MSS 自动修改功能打开就好了吗？总不能是他们的垃圾交换机完全没提供这个功能吧。
  

CloudCone 网络问题的临时解决办法（并不是解决，只是改善）

1. 反复尝试登录你的SSH，一定几率下会成功链接的到服务器（或者用CloudCone后台网页vnc）

2. 在终端输入ping -M do -s 1400 www.google.com，看下能不能ping通谷歌（也可以试试其他数字比如1420、1450、1470等稍大的数值，1400 是最保守的参数）

3. 如果确定可以ping通的话

• 如果你使用的是 Ubuntu / Debian：打开 /etc/netplan/ 目录下的 .yaml 配置文件（名字通常叫 50-cloud-init.yaml 或 01-netcfg.yaml之类的，你就改那个数字最大的文件）在你的网卡（如 eth0）下面缩进加上 mtu: 1400，保存退出后执行：netplan apply类似这样：

  network:
  version: 2
  ethernets:
      eth0:
          dhcp4: true # 这行只是示例，不要照抄
          mtu: 1400  # <--- 加在这一行
  

• 如果你使用的是 CentOS / RHEL: 打开 /etc/sysconfig/network-scripts/ 目录下的 ifcfg-eth* 配置文件。在文件末尾新起一行，加上MTU="1400"，保存退出后，重启网络：systemctl restart network。

4. 这个操作能有什么作用呢，不过是将你的小鸡消失的比例从95%以上降到到了20%以下罢了。放心吧，你就算把 MTU 设置成 1000 ，该断的时候也要断。