六六云 11 月 3 日整段收回 38.34 段：24 小时免费换 IP，免费名额其实只有开通后 1 小时

六六云在 11 月 3 日 20:37 发了一份公告：美国 38.34.20.* 到 38.34.28.* 段的实例要在 24 小时内免费换到 38.69.24x.x 段，原来的 IP 直接停用。补偿是 3 天服务期加一次本期流量重置。如果你是这批实例的用户，真正的麻烦不在换 IP 这个动作本身，而在换完之后：域名解析、CDN 回源、防火墙白名单、对象存储的授权名单、邮箱的 SPF 记录、CI 里的部署地址，任何一处漏改都会在公告承诺的"短暂中断"之外再造一段更长的故障。这篇文章先把这次更换的边界条件讲清楚（谁受影响、补偿值多少钱、换 IP 的次数还剩几次），再给一份按依赖关系排好序的迁移清单，最后把条款里两条互相矛盾的可用性承诺摆出来，让准备下单的人知道该向工单问什么。

这次换下的不是一台机器的地址，而是整段 /24

公告原文的四句话各自对应一个读者会踩的坑，先逐句拆开。第一条讲范围与时限："现用 38.34.20.*～38.34.28.* 段的相关实例，将在本公告发布后 24 小时内免费更换至 38.69.24x.x 段，原IP将停止使用。"注意两个细节。一是"段"：受影响的不是零散几个 IP，而是 38.34.20.0/24 到 38.34.28.0/24 这九个 /24 整段，按每段 254 个可用地址算，理论上接近 2300 个地址位处在这次调整范围内，实际分配出去的实例远少于这个数，但意味着同一批客户很可能共享相邻地址。二是"原IP将停止使用"：这不是旧 IP 保留一段时间做过渡，而是停用。任何还把流量打向旧地址的东西，在更换完成后就会直接落到黑洞里。

第二条把需要改的地方点出来了，但说得很轻："更换期间可能出现短暂中断，系统、数据、套餐及续费价格保持不变。完成后请登录官网查看新IP，及时更新域名解析、IP白名单及相关连接配置。"公告只列了域名解析和 IP 白名单两项，实际上"相关连接配置"这四个字能盖住的场景远不止两个，后面第四节按依赖顺序列全。第三条是补偿："受影响实例统一赠送3天服务时间，并免费重置一次本期已用流量，套餐容量不变，无需支付额外费用。"第四条是通道："如遇异常，请通过官网提交工单。"

受影响的是哪条产品线，从商品描述能对上。同组商品里"美西原生IP双ISP - 国际带宽"的测试 IP 写的是 38.34.23.1，正好落在 38.34.20.* 到 38.34.28.* 区间内；它在货架上目前标着"暂时缺货、暂无在售配置"。同一分区下另外两条千兆线"双ISP /CU4837/G口"与"双ISP - NTT（新IP）"的测试 IP 分别是 38.79.117.254 和 216.167.52.254 / 192.220.71.254，不在公告范围内。也就是说这次的变动只落在 38.34.x 这批国际带宽实例上，同价位的另两条线不受影响。

3 天服务期加一次流量重置，值多少钱

补偿只有两项，都能算成钱，算完也就知道该不该拿它当"额外赠送"看待。3 天服务期按档位折算：1 核 1G 1TB 档月付 50 元，日均 1.67 元，3 天约 5 元；1 核 1G 2TB 档月付 80 元，3 天约 8 元；2 核 2G 3TB 档月付 160 元，3 天约 16 元；4 核 4G 5TB 档月付 320 元，3 天约 32 元。年付客户还要再低一截，因为年付总额是月付的 10 倍而不是 12 倍，折算下来 1 核 1G 1TB 的年付日均约 1.39 元，3 天只有 4.17 元。

另一项补偿是一次流量重置，这项的价值取决于换 IP 那天你已经用了多少。AUP 第三条写明配额按上行与下行之和计算、按每台机器自己的开通日重置而不是自然月 1 号，所以"本期已用流量"是一个跟账单月份错位的数。如果更换恰好发生在周期末尾、当月额度已经用掉大半，这次重置等于白送将近一个整月的额度，按 1 核 1G 1TB 档折算就是接近 50 元的量；如果更换发生在周期刚开始的第 3 天，已用流量才一百多 GB，重置的实得只有十几 GB，价值十元上下。公告没有写明重置的判定基准日，这一条值得在下单前问清楚：补救的流量是按更换日重算，还是按原开通日重算。

把这次事件放回商家的公告时间线里看，它不是孤立的。往前翻，10 月 26 日连发了两条：150 号标题就叫"墙高峰"，正文写"最近几天用户侧可能会出现 IP 被墙、用户流量伪装强度不高被大陆防火墙识别到进而被干扰等情况，建议关机保护 IP"；151 号写"最近不少用户遇到服务器 Ping 得通，但 SSH 或业务端口连不上的情况，主要表现为 TCP 连接在中国大路段受限"。11 天之内，同一家商家先提示 IP 可能被干扰并建议关机，再发通知整段收回并更换。我不认为这足以证明两件事有因果关系，公告 152 对原因只说"因IP资源调整"，没有更多细节；把两件事并排看的意义在于，它提醒读者：这家商家的美国线在不到两周时间里已经发生过两次与 IP 可达性相关的事件。如果你把某台机器的可用性完全押在"IP 在中国大陆可达"这一条上，那么对这台机器的预案不能只写"出问题就换 IP"，还要写"换 IP 之后所有下游配置怎么跟着变"，因为换 IP 这个动作本身会重复发生。

换 IP 真正的工作量在下游，按依赖顺序排一遍

公告只提了域名解析和 IP 白名单。实际做下来，一台机器换 IP 会牵动七类位置，顺序错了会互相打架。下面按"先改不会引故障的，后改会引故障的"排，理由是：越是下游的东西，改早了越容易在旧 IP 还活着的时候被打断；越是上游的东西，改晚了越容易让请求落到已经停用的地址。

在动手之前，如果你还在评估要不要继续用这条线，可以先核对六六云美国各条线的当前端口与流量配置，确认自己这台机器在不在支持自助换 IP 的产品范围内，再看下面的迁移顺序。

第一步：先在旧机器上留一条回程通道

换 IP 后最先失效的往往不是业务，而是你自己的 SSH。如果安全组或 iptables 只放通了办公网出口 IP，新 IP 分配下来、旧 IP 停用的那一刻，你连不上机器，也没法在新 IP 上做任何配置。所以要动之前先确认两件事：云平台侧的安全组是否对新 IP 默认放通 22 端口，机器内的 sshd_config 是否有 AllowUsers 或 Match Address 限定。更好的做法是提前给这台机器配一个带外通道，比如平台自带的 VNC 或控制台，它不经过公网 IP，换 IP 期间仍然能用。这一步不做，后面六步都可能卡住。

第二步：确认新 IP 是否换了上游与归属地

公告写的是从 38.34.x 换到 38.69.24x.x。两组地址的第一段相同，但第二个字节从 34 变成 69，属于不同的 /16，大概率不是同一家上游的同一个宣告段。这件事影响两件事：一是新 IP 的归属地数据库要重新查，有些商家宣传的"原生 IP"或"双 ISP"属性绑定在具体的地址段上，换段之后属性可能变化；二是如果你在别的系统里按 IP 段做了地域判断（比如广告投放的地区定向、支付风控的国家判断），按旧段写死的规则要跟着改。用 whois 或任何公开的 IP 归属查询查一次新地址，比凭公告里的段猜更可靠。

第三步：改 DNS，并且先把 TTL 降下来

这一步是公告明写的，但顺序常常做反。正确做法是在换 IP 之前就把记录的 TTL 降到一个短值，等旧 IP 停用、新 IP 生效后再改 A 记录，再等一个 TTL 周期后把 TTL 调回去。原因是 A 记录切换的等待时间由改之前那个 TTL 决定，不由改之后的值决定：一条 TTL 86400 的记录，最坏情况下客户端还会把旧地址缓存 24 小时；TTL 3600 的话最坏 1 小时；TTL 300 的话最坏 5 分钟。如果你在更换当天才想起改 TTL，那你已经错过了把它调低的时机，只能接受最长 24 小时的解析毛刺。

还有一处容易漏：如果域名走了第三方 CDN 或托管 DNS，回源地址往往写在 CDN 的回源配置里而不在公共 DNS 记录里，改 A 记录不会同步改回源。这类配置要在 CDN 控制台单独改，并且顺序是"先加新源、再摘旧源"，而不是直接把旧源替换掉，这样在新源还没验证通过的情况下至少有一条退路。

第四步：白名单与授权名单，一处漏改就是 403

公告提到的"IP 白名单"至少包括四类不同的东西，它们的配置位置和验证方式都不一样：云平台侧的安全组规则；机器内的 iptables 或 nftables 规则；应用层的访问控制（Nginx 的 allow/deny、面板的 IP 白名单）；以及第三方服务的调用方授权名单（对象存储的 bucket policy、数据库的 pg_hba.conf 或 host 表、支付或短信网关的 IP 白名单、API 平台的调用方 IP 限制）。第四类最容易漏，因为它在别人的控制台里，而且失效的表现是 403 或连接被拒，看上去像"服务挂了"而不是"IP 变了"。如果这台机器是作为调用方访问别人，要改的是别人家的白名单；如果它是被调用方，要改的是自己的入站规则。两个方向都要过一遍。

第五步：邮件送达相关的 DNS 记录

这台机器如果承担发信（哪怕是发验证码这类事务邮件），换 IP 之后 SPF 记录里如果用了 ip4: 精确写法就会失效，而 ip4: 指向旧地址的表现是邮件进垃圾箱或直接被拒，不会报错。同理，如果对方按 IP 做反向解析校验，新 IP 的 PTR 记录也要等平台更新，这段时间正向解析和反向解析对不上，部分收件方会直接拒收。发信场景要在换 IP 之后单独验一遍，不能只看网页能不能打开。

第六步：编排与部署系统里的硬编码

这是百度下拉里真实有人问的那一类。"服务器换ip之后docker有影响嘛"这种问题通常有三种来源：一是 docker run 时用 -p 旧IP:端口:端口 绑定了具体地址，IP 一换容器起不来；二是 compose 文件或 /etc/hosts 里写死了旧地址；三是部署脚本、CI 的 known_hosts、Kubernetes 的 node 地址或 kubelet 注册地址里存了旧 IP。这类问题不会在换 IP 的瞬间暴露，往往等到下一次重启或下一次部署才炸，排查成本高。换完之后跑一遍 grep -rn "38.34." /etc /opt /srv 这类搜索，把写死旧段的配置全找出来，比等它报错便宜得多。同一批搜索也应该覆盖 ~/.ssh/known_hosts：换 IP 之后第一次连会报 host key 变更，那不是被攻击，是地址复用，按提示删掉旧条目即可。

第七步：备份与监控，最后一步也是最容易被跳过的一步

换 IP 这件事本身不改磁盘、不改系统，所以很多人默认数据安全。TOS 7.1 写得很直白："我们不提供数据备份服务，服务器未配置数据冗余。请务必自行做好异地备份。（磁盘阵列用于提升硬件可靠性，不等同于备份。）"也就是说这次更换过程中万一出现不可预期的问题，商家侧没有可回滚的数据副本。换 IP 前后各做一次快照或异地备份，成本是一点磁盘和十几分钟，换掉的是"出问题只能从零重装"的选项。同时把监控里的探活目标从旧 IP 换成域名或者新 IP，否则换完之后监控会一直报"目标不可达"，你会以为新机器坏了，实际上是监控自己还盯着一个已停用的地址。

免费换 IP 的窗口只有 1 小时，之后每一次都要算次数

这次公告用的是"免费更换"，属于商家主动发起的调整。但读者更该看清的是日常换 IP 的规则，因为它决定了你在未来一年里能承受几次不可达。TOS 5.2 的原文是："支持自助更换IP的产品，每台服务首次开通成功记录起1小时内，可针对被墙IP提交一次免费更换工单。其它原因不支持免费更换。"免费窗口从"首次开通成功记录"起算 1 小时，且只针对被墙这一种原因。这意味着一个新客户拿到机器后，如果 IP 是在第 3 小时才被封，免费机会已经用掉了；如果第 1 小时内没被封，这个机会就随开通时间一起过期，不会留到后面。这一点和很多人的直觉相反：免费换 IP 不是"一次备用机会"，而是"开通后一小时的验收窗口"。合理用法是开通后一小时内就把 IP 的可达性验一遍，而不是等业务上线之后再发现。

过了这一小时，TOS 5.4 规定的次数是三重限制叠加："每台服务滚动72小时最多成功更换1次、每个流量重置周期最多2次；每个账户按UTC+08自然月合计最多5次。"

三条约束里，单台的"滚动 72 小时最多 1 次"算下来一个月理论上限是 10 次，但"每个流量重置周期最多 2 次"把上限压到 2 次，因为六六云的流量周期是一个月一次。于是单台机器的全年有效换 IP 次数是 24 次左右。真正卡住多机用户的是第三条：每个账户按 UTC+8 自然月合计最多 5 次，这是账户级的池子，不分机器。

把这张表和前面的免费窗口放在一起，能得出一个具体的采购判断：如果你打算在同一账户下开 5 台以上、且业务对 IP 可达性高度敏感，那么这台机器的 IP 风险不是"换个 IP 就好"，而是"每月只有一次机会"。这种情况下，分散到多个账户并不能解决，因为 TOS 3.4 对退款频次明确写了"按支付账户计算，而非按登录账户，同一支付账户以及经查实由同一人控制的关联账户合并计算为一个主体"，同样的合并认定在 1.2 条也出现过。合理的策略是留一台随时能顶上的备用机，而不是指望换 IP 次数够用。

条款里有一处互相打架的地方，下单前该问清楚

这是本文最想让你留意的一节。TOS 5.3 写的是："除 5.2 的一次性保证外，我们不对 IP 在任何特定网络（包括中国大陆）下的持续可达性作出承诺。IP 因运营商、上游网络或其他我们不可控的原因被屏蔽、丢包或不可达，不属于服务故障，不构成退款理由。"而 TOS 6.2 又写："灾难性故障指物理服务器硬盘损坏导致数据丢失，或连续中断超过 72 小时无法恢复。发生此类故障时，我们按以下方式补偿：延长服务到期时间，并同步顺延流量重置周期；或按剩余周期退款，不收手续费。"

两条摆在一起，问题就出来了：如果一台机器从中国大陆连续 72 小时不可达，算不算 6.2 说的"连续中断超过 72 小时"？按 5.3，运营商或上游原因造成的不可达"不属于服务故障"，而 6.4 又把"上游网络故障"明确排除在 6.2 的补偿之外。但 5.3 同时又承认"这是跨境网络的固有属性"。于是两条条款合起来的实际效果是：72 小时这条补偿线对"IP 被屏蔽"这种最可能发生的长时间中断几乎不可能触发，因为原因方永远是上游或运营商。它在硬盘损坏、平台侧彻底失联这类商家自己可控的故障上才有意义。

这不等于说条款有问题，很多同类商家写的是同一套逻辑，只是很少把两条并排放。对读者的用处在于：不要用"连续中断 72 小时可以退款"来给自己的可用性做兜底，因为触发条件里"不是上游原因"这一条很难满足。真正能兜底的是自己的多机或多商家部署。下单前值得用工单问三个具体问题：一是 IP 被屏蔽造成的不可达，是否计入 6.2 的"连续中断"；二是如果计入，需要什么形式的证据（从哪些节点探测、多久一次的记录）；三是 5.5 那句"特殊时期我们有权暂停提供换 IP 服务，或临时调整价格"在实际执行时，暂停期间次数是否照常消耗。

另外两个与时间有关的口径也值得一并在同一张工单里问完，因为它们决定出问题时你有多少操作余量。退款窗口是"自订单生成起 48 小时内"，TOS 3.1 特意强调时效以订单生成时间和工单提交时间为准、不以工单回复时间也不以服务开通时间为准，3.1 后面还跟了一句提醒："因时效自订单生成时起算，请在下单后及时完成支付，拖延付款会占用您的退款窗口。"也就是说从生成订单到付款之间的等待时间是从你的退款时间里扣的。超过 48 小时按 3.2 不再受理，3.3 还列了七种不支持退款的情形，其中最容易被忽略的是"促销、特价、活动产品及预售产品"，上一轮全站 8 折的活动产品就落在这条里。另一个是到期删除：4.3 写到"到期后第 5 天仍未续费的，服务及其全部数据将被自动删除"，4.6 又补了一句"遇服务器硬件故障、机房下架、节点维护或数据迁移等特殊情况，我们可能对处于暂停状态的服务提前终止，不再等待 4.3 约定的第 5 天"。这次公告 152 就是数据迁移类事件，虽然公告写明"系统、数据、套餐及续费价格保持不变"，但 4.6 的存在说明"暂停中的机器有 4 天挽回期"并不是一个可以依赖的承诺。

同样 1000Mbps，这条线在六六云价目表里站在哪一格

这次被收回的"国际带宽"线目前在货架上标着暂时缺货，没有在售配置，所以不能直接比价。但同分区另外两条千兆线还在卖，它们的定价方式能说明六六云对"1000Mbps 端口 + 原生 IP"这个组合的定价逻辑，也顺便解释了为什么这台机器的用户对 IP 更换特别敏感。三条美国千兆线在相同配置下的差价只有 5 到 40 元：1 核 1G 1TB 档，CU4837/G 口与 NTT 都是 50 元，GTT 是 55 元；1 核 1G 2TB 档分别是 80、80、90 元；2 核 2G 3TB 档是 160、160、180 元；4 核 4G 5TB 档是 320、320、360 元。GTT 每条线固定贵 5、10、20、40 元，比例上从 10% 一路降到 12.5%，属于同一条线上不同回程的价差。

这张表最值得注意的不是 GTT 贵多少，而是除了 GTT 那条溢价线以外，同一档 CPU 和内存的机器，在 200Mbps 优化线与 1000Mbps 双 ISP 线上的月费完全一样。拿 1 核 1G 档说，美西双 ISP 的千兆线 50 元，美国 CN2 GIA 的 200Mbps 线 55 元，德国优化 200Mbps 线也是 55 元；如果只看"每兆端口多少钱"，千兆线是 5 元每 100Mbps，200Mbps 线是 27.5 元每 100Mbps，差了 5.5 倍。但价格几乎相同，说明商家定价的锚是"每核多少钱"而不是"每兆多少钱"。这也解释了为什么这次事件影响面不只是"换了个 IP"：这批机器的价值有很大一部分就落在那个 38.34 段的具体地址上，地址一换，配置单上的数字一个没变，实际能做的事可能变了。

现在该怎么用这次补偿

如果你是受影响实例的用户，剩下能做的判断只有三项，都不复杂。第一项是确认自己有没有被这次更换覆盖：公告给的是 38.34.20.* 到 38.34.28.*，在机器上跑 curl -s ifconfig.me 或看控制台里显示的当前公网 IP，落在区间内就是受影响的，已经在 38.69.24x.x 就说明更换完成。第二项是核对补偿有没有到账：3 天服务期体现在到期时间上，流量重置体现在本周期已用量归零，两项都是可以在控制台直接看到的，看不到就提工单，别等。第三项是把前面第四节那七步当成一次演练机会：这次是商家主动换的，中断窗口在公告里提前写了，正好用来验证自己的迁移清单是否完整，下次是 IP 自己出问题时就不会手忙脚乱。

如果你正在选一台美国原生 IP 的机器，这次公告给的信息是：在六六云这条线上，"原生 IP"是一个会被上游调整的资源，不是一个买到就固定的资产。下单前把三件事问清楚：这台机器在不在支持自助换 IP 的产品范围内（5.2 原文是"支持自助更换IP的产品"，意味着有不支持的产品）；换 IP 的实际费用是多少（5.4 写"按产品配置价格收费，具体费用在确认前展示"，也就是下单前那个数看不到，要以工单答复为准）；以及如果 IP 在开通 1 小时后被墙，除了付费换 IP 之外还有没有别的处置方式。这三个问题的答案会直接决定这台机器在你的架构里该扮演什么角色：能接受每月一次 IP 变更的，可以当主入口；不能接受的，只适合当出口或中转。

六六云美国线的在售档位和库存都在选购页实时显示，想按自己需要的端口与内存组合核对当前价格的，可以查看六六云美西双 ISP 千兆线各档的端口、内存与流量组合，选购页把 cpu、内存、端口、流量四列直接摊在每张商品卡上，不需要逐条点进去。如果更关心条款原文，六六云的服务条款与可接受使用政策都在站内可查，本文引用的 5.2、5.3、5.4、6.2、6.4 与 AUP 3.3 都能逐条对上，建议在付款前把这些条目和工单答复一并留存。

最后补一句关于这次事件的边界：本文只依据六六云自己发布的公告、条款与商城页面做判断，没有实测这批新 IP 在中国大陆各地的可达性，也没有验证补偿是否已经发放到每一台受影响实例。公告承诺的 24 小时更换时限，对照公告发布日期推算应在 11 月 4 日 20:37 前完成，截至本文写作时已过去约 63 小时；如果你名下的实例仍在旧段上，值得立刻提一次工单确认，而不是等下一个周期结算时才发现。

资料来源

六六云公告：美国部分实例IP更换及补偿通知（2026-11-03 20:37）；六六云公告：墙高峰（2026-10-26）；六六云公告：【墙高峰】近期连接异常说明（2026-10-26）；六六云服务条款 TOS v2.1（生效 2026-09-06）；六六云可接受使用政策 AUP；六六云选购页（2026-11-06 核对在售档位与库存）；六六云公告列表（折扣活动均已过期，仅供参考）