VPS要不要开IPv6：实际影响

一、结论先说：默认别开，除非你能说清理由

大部分人开 IPv6 是出于「听说以后会普及，先开着省事」的想法。这个理由站不住，原因有三个，而且每一个都是硬性的：

第一，你的服务器大概率本来就只有一个 IPv4 地址。快照里全部 28 个有价套餐中，IPv4 数量写明的只有 RosCloud 系列，明确是每台 1 个；云途系列的 IP 描述统一标注为「IPv4（原页未注明具体数量）」；sixtynet 全部套餐的 IPv4 字段都是空的。也就是说，没有一个套餐在快照里写明了会分配 IPv6 地址——ipv6_count 字段在全部 28 条记录里都是空的。

第二，开了之后流量不会自动走 IPv6。要让访客用 IPv6 访问，你还需要给域名加 AAAA 记录，还要确保你的机房真的把 IPv6 前缀路由到了这台机器，还要确保访客的运营商没把 IPv6 挡住。三者缺一，流量照旧走 IPv4。

第三，开了会扩大暴露面。IPv4 地址稀缺，扫描器覆盖有限；IPv6 地址空间巨大，理论上任何一台机器的 IPv6 都能被扫到。唯一的实际防线是防火墙规则，而大多数默认安装的防火墙配置里，IPv6 是被单独放行的。

查看 iwebfusion 当前月价与库存

所以本文的立场是：IPv6 对绝大多数个人用户是「可以开但开了没用」，对有明确需求的场景是「必须开且要配对」。下面先把机制讲清楚，你再对照自己的情况做决定。

二、库里这批套餐的 IPv6 字段实际情况

先把数据摊开。2026 年 11 月 5 日 12:02 的商品库快照，28 个有价套餐的 IP 相关字段：

商家	套餐数	ipv4_count	ipv6_count	ip_description
RosCloud	6	1（全部写明）	全部为空	全部为空
sixtynet	13	全部为空	全部为空	全部为空
云途	9	全部为空	全部为空	全部为「IPv4（原页未注明具体数量）」

查 justg 在售套餐与库存

这里有一个值得注意的细节：云途的 IP 描述字段里明确写了「IPv4」二字。这不是「IPv4 加 IPv6」，而是标注了协议族是 IPv4，并补充说明原页面未注明具体数量。RosCloud 则是结构化字段直接写 ipv4_count: 1，ipv6_count 为空。

结论很明确：在当前快照里，没有任何一家提供可确认的 IPv6 地址。你在商家页面上看到的「支持 IPv6」表述，如果存在，那是产品页的泛化描述，不是分配给你的资源。

这带来一个直接的操作后果：在你能向商家确认「这台机器会分到一个可路由的 IPv6 地址」之前，讨论「要不要开 IPv6」这个问题是无意义的。开不开不取决于你的系统配置，取决于服务商有没有给你这个地址。

对以官网当日报价为准的商家，这个问题必须单独问，而且要问具体：分到的 IPv6 是 /64 还是 /128？是原生 IPv6 还是有 NAT 转换？是否支持双栈（同时保留 IPv4 出站）？这四个答案决定了你后面所有配置的可行路径。

三、IPv4 和 IPv6 在服务器上的三处不同

即使你拿到了 IPv6 地址，服务器上有三处需要分别确认，缺一处就会出现「配了但没生效」的情况。

第一处：网卡地址与路由。 你需要看接口上是否真的配了 IPv6 地址，以及默认路由是否存在：

# 查看所有网卡的 IPv6 地址（注意区分 link-local 和 global）
ip -6 addr show

# 查看 IPv6 路由表，重点看有没有 default 项
ip -6 route show

# 只看全局地址，过滤掉 fe80 开头的链路本地地址
ip -6 addr show scope global

如果 ip -6 addr show scope global 没有任何输出，说明这台机器上根本没有可对外通信的 IPv6 地址。fe80:: 开头的地址是链路本地地址，只能在同一二层网络内用，不能路由到公网。

第二处：DNS 记录。 你的域名要有 AAAA 记录指向这个 IPv6。没有 AAAA 记录，访客的 DNS 解析只会返回 A 记录对应的 IPv4。

第三处：Web 服务器监听。 很多教程只改 Nginx 配置却忘了这一层。Nginx 要显式监听 IPv6 套接字：

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    # ...
}

Apache 则是加载 mod_ipv6 模块并加 Listen [::]:80。改完记得 nginx -t 检查语法再 reload。

查 racknerd 在售套餐与库存

这三处缺任何一处，你的 IPv6 地址就是「配了但不生效」。

四、怎么判断你的服务器到底有没有 IPv6

在动手配置之前，先做一次完整的事实核查。这套流程能区分「没有地址」「有地址但不通」「通了但客户端不用」三种情况。

# 第一步：本机能不能 ping 通自己的公网 IPv6
ping -6 -c 4 2606:4700:4700::1111

# 第二步：能不能 ping 通外部的 IPv6 地址（这一步最关键）
ping6 -c 4 2001:4860:4860::8888

# 第三步：看 DNS 解析有没有返回 AAAA 记录
dig AAAA example.com +short

# 第四步：看解析出来的地址是不是你服务器上的那个
ip -6 addr show scope global | grep -oP 'inet6 \K[0-9a-f:]+'

# 第五步：测试双栈下的连接建立
curl -6 -s -o /dev/null -w "IPv6 HTTP: %{http_code} 连接耗时 %{time_connect}s\n" https://example.com
curl -4 -s -o /dev/null -w "IPv4 HTTP: %{http_code} 连接耗时 %{time_connect}s\n" https://example.com

第二步是最有判别力的一步。 如果外部 IPv6 地址 ping 得通，说明机房真给你接入了 IPv6 路由；如果 ping 不通（且不是被本地防火墙拦），说明地址可能是分了但没路由，或者根本没分。

第五步的对比最有价值。 如果 curl -6 和 curl -4 都能返回 200 且连接耗时接近，说明双栈是通的，访客可以走 IPv6。如果 -6 直接失败，那 IPv6 这条路在你的机器上是断的，配再多也没用。

再从外部验证一次，用另一台机器或在线工具访问你的域名，确认 AAAA 记录解析出来的地址确实能建立连接。这一步能排掉「本机通、外面不通」的情况——通常意味着路由或防火墙的入站策略问题。

配 AAAA 记录时有几个技术细节容易踩坑：

AAAA 记录必须指向地址本身，不能带端口或路径。 和 A 记录一样，AAAA 的值就是一个纯地址，比如 2606:4700:4700::1111。很多人从 ip -6 addr 里复制时带上了 /64 前缀长度，写进 DNS 就成了无效记录，服务商会直接拒绝或者解析出错误结果。

多台机器要加多条 AAAA 记录。 如果你有多台服务器做负载均衡，每个 IP 都要单独加一条 AAAA 记录，不能把 /64 写进去。

CDN 场景下 AAAA 记录指向 CDN 而不是源站。 如果你用了 Cloudflare 之类的代理，DNS 服务商那边开启「IPv6 兼容性」开关即可，源站不需要有 IPv6 地址。

TTL 设置要和 A 记录一致。 两条记录的 TTL 不一致会导致切换时出现状态不一致——比如 A 记录已经切到新服务器、AAAA 记录还指向旧的，造成部分请求打到旧机器。

别忘了 IPv6 的地址压缩写法。 2606:4700:4700::1111 里中间的连续零被压缩成 ::，但一行里只能用一次。这个规则写错，DNS 记录会指向完全不同的地址，而 ping6 会直接报「网络不可达」而不是「地址不对」，排查方向容易被带偏。

查 spinservers 在售套餐与库存

# 检查 AAAA 记录是否有效、是否能被正确解析回 IPv4 对应的地址
dig AAAA example.com +short
# 从外部视角确认返回的地址可达
curl -6 -s -o /dev/null -w "IPv6 访问: %{http_code} 耗时 %{time_total}s\n" https://example.com

五、客户端的实际情况：谁会走 IPv6

服务器准备好了，访客会不会真的用 IPv6？这取决于客户端栈和运营商策略，实测下来的规律很稳定。

桌面系统（Windows 10/11、macOS、主流 Linux 桌面）几乎都默认启用 IPv6，且大多配置了 IPv4/IPv6 双栈（Happy Eyeballs）。这类客户端访问你的站点时，如果 AAAA 记录可达就走 IPv6，不可达就自动退回 IPv4，过程对用户完全透明。

移动端（iOS、Android）同样默认启用 IPv6，且大量手机流量是纯 IPv6 网络（运营商给终端分配 IPv6 地址，IPv4 通过 NAT64 转换）。在这些网络上，你的站点只有 AAAA 记录才能被访问，只有 A 记录则可能完全打不开——这是纯 IPv6 网络最常见的表现形式。

IPv4-only 的网络依然大量存在，尤其是部分企业内网、老旧宽带、部分代理环境。这类环境下 IPv6 地址会被完全忽略，走 IPv4。

部分代理和 CDN 节点有自己的一套解析和回源逻辑，可能优先用 IPv4，也可能只支持其中一种协议。

所以「要不要开 IPv6」的真正判断依据不是技术偏好，而是你的访客构成。如果你的主要访客在移动网络或使用现代桌面系统，IPv6 是必要的补充；如果是纯 IPv4 的企业环境，IPv6 只是个摆设。

对使用 Cloudflare 等支持双栈的 CDN 的站点，这个问题的优先级会下降——CDN 会在边缘完成 IPv4 到 IPv6 的转换，源站只看到 IPv4。但在没有 CDN 的情况下，源站的双栈支持就直接决定了你能覆盖多少访客。

IPv4 和 IPv6 的连接建立顺序并不相同，这点值得留意。 双栈客户端在同时拿到 A 和 AAAA 记录时，Happy Eyeballs 算法会并行发起两种连接，通常在 300 毫秒内选出先完成握手的那个。实际效果是：即使你的 IPv6 路径质量略差，客户端也基本感知不到，因为它会在 IPv6 慢的时候切到 IPv4。

但这个机制有个前提：两种地址都必须在合理时间内有回应。如果你的 IPv6 路由是「黑洞」状态——既不返回失败也不建立连接，而是静默丢包——客户端就要等到超时才会回退，这会让首访用户多等几秒。这种情况下，AAAA 记录反而变成了负优化。

判断是不是黑洞，看第五节那两条 curl 命令的耗时：如果 curl -6 不是快速失败而是卡到超时（比如 --max-time 10 触发），基本可以确认是丢包而不是拒绝。这种情况下的正确处理是：要么修好 IPv6 路由，要么把 AAAA 记录撤掉，中间状态最糟。

zenlayer 官网机型与实时报价

还有一个容易被忽略的细节：AAAA 记录会同时出现在 DNS 查询和证书签发流程里。你的域名一旦有 AAAA 记录，ACME 证书验证时就会走 IPv6，如果你 443 端口只监听了 IPv4，证书续期可能失败——而这通常在 60 天后才暴露，排查起来非常折磨。所以第四节那五步检查里，「Web 服务器监听」这一项必须在配 AAAA 记录之前完成。

六、机房路由差异：为什么同一台机器有时通有时不通

这是最容易被误判为「我机器坏了」的问题。IPv6 的连通性受到访客所在地的多条路径影响，而不同机房、不同运营商的 IPv6 路由质量差别很大。

典型的失败模式是部分通：你的网站一部分访客走 IPv6 正常，另一部分走 IPv6 超时，然后自动退回 IPv4。这个现象在访问日志里表现为 IPv6 请求大量 499 或超时，但 IPv4 请求正常。访问者感觉「有时慢有时快」，开发者却查不出原因。

排查方法是分别从不同网络测试：

# 分别用 IPv4 和 IPv6 测同一个地址，对比成功率
for i in $(seq 1 20); do
  curl -4 -s -o /dev/null -w "%{http_code} %{time_total}\n" --max-time 10 https://example.com
done | sort | uniq -c

for i in $(seq 1 20); do
  curl -6 -s -o /dev/null -w "%{http_code} %{time_total}\n" --max-time 10 https://example.com
done | sort | uniq -c

如果 IPv6 的失败率明显高于 IPv4，那就是路由质量问题，不是配置问题。 这时候只有两条路：换机房，或者只在确认 IPv6 路由良好时才对特定区域启用 AAAA 记录。

还有一个数据点值得注意：快照里 sixtynet 的产品命名里就带着机房和线路属性——LAX（洛杉矶）、IRVINE（尔湾）、Residential（住宅）、以及一款明确标注 China Unicom（联通）的线路。这说明这类商家的产品线是按机房位置和线路类型细分的，而不同机房的 IPv6 路由质量是完全独立的资源属性。新增一个洛杉矶机房的 IPv6 前缀，和新增一个住宅 IP 的 IPv6 前缀，路由路径不一样。

查 cloudcone 在售套餐与库存

在快照里，这些套餐的 datacenter 字段全是空的，机房位置只能从名称推断。这意味着机房位置这一决策依据，在数据层面是不完整的，下单前必须到商品页确认具体机房。

七、开了 IPv6 之后，安全暴露面怎么变

这是最该认真对待的部分。原理不复杂：IPv4 地址空间约 43 亿，扫描器可以完整遍历；IPv6 地址空间大到无法遍历，但扫描器可以针对你的具体 IPv6 前缀做定向扫描——只要你的主机名或服务器 IP 出现在任何公开的地方（DNS 记录、SSL 证书透明度日志、代码仓库、错误日志），对应的 IPv6 地址就可能被定位并扫描。

所以「IPv6 地址空间太大扫不到」是误解，正确的说法是「IPv6 不会被无差别扫到，但会被定向扫到」。

防护的核心是让 IPv6 和 IPv4 遵循完全相同的防火墙策略。最常见的翻车方式是：IPv4 的规则只写在 iptables 的 inet 表 filter 链，而 IPv6 走的是 ip6tables——两套独立的表，默认规则可能不一致。ufw 的用户可以用 ufw status 同时确认两套规则都存在；firewalld 用户可以用 firewall-cmd --list-all 确认 ipv6: yes 没有被关闭。

# 检查 IPv6 防火墙规则是否与 IPv4 对等
sudo ufw status verbose
sudo ip6tables -L -n -v

# 确认 nginx 的 IPv6 监听端口在防火墙里也放行了
sudo ss -lntp | grep -E ':80|:443'

# 查看是否有来自 IPv6 的连接记录
sudo ss -tn state established '( sport = :443 )' | grep ':' | head -20

实战中最常见的安全事故：IPv4 防火墙只放行了 22 和 80/443，而 IPv6 因为用了另一套默认放行规则，导致 IPv6 地址上的 SSH 和数据库端口对全网开放。修复方式是让两套规则严格对等，并用 ip6tables 明确列出允许的端口。

另一个要点：IPv6 绕过了部分基于 IPv4 的封禁手段**。如果你用 deny 规则封禁某个恶意 IP 段，那只对 IPv4 生效，来自同一 IPv6 段的连接不受影响。

第三层暴露：日志和统计口径。 很多站点在统计访问来源时默认把 IPv6 地址截断成 /64 前缀展示（这是正确的做法，因为单个终端通常会获得一整个前缀），但如果在反向代理层做限流时用了完整 IPv6 地址，同一个用户换几个地址就能绕过限流。反过来说，你的限流规则如果只按 IPv4 的习惯设计（比如假设一个 IP 就是一个用户），在 IPv6 下会严重失准——一个终端就能有上万个地址。

第四层暴露：ICMPv6 是必须放行的。 IPv6 的邻居发现（ND）、路径 MTU 发现都依赖 ICMPv6。如果你的防火墙把 ICMPv6 全拦了，会出现非常典型的症状：能 ping 通外部地址，但 TCP 连接建立失败；能建立连接，但传输大包时卡住不动。这不是玄学问题，就是 ICMPv6 被拦了。所以「最小化放行原则」在 IPv6 上有个例外——ICMPv6 不能全拦。

# 确认 ICMPv6 没有被误拦（规则里应有 icmpv6 相关条目）
sudo ip6tables -L -n -v | grep -i icmpv6

# 如果是 ufw，确认 ip6tables 链存在且规则与 iptables 对等
sudo ufw status | grep -A20 "Default: deny (incoming)"

# 抓包看 ICMPv6 是否被丢弃（需要 root）
sudo tcpdump -i eth0 icmp6 -c 20 -v

digitalocean 官网机型与实时报价

抓包是最直接的验证方式：如果能看到 ICMPv6 的请求但看不到回应，就是被防火墙丢了；如果连请求都收不到，那是上游路由的问题。

八、算账：开 IPv6 值不值这个钱

IPv6 本身通常不额外收费，所以「值不值」这个问题的答案是：它的成本不是钱，是复杂度和风险。但既然要求给算账，那就把这笔账算清楚——用真实价格看 IPv6 会给你带来什么样的实际收益。

收益一：移动端访客的可达性。 纯 IPv6 网络的访客只能通过 IPv6 访问你。如果你的站有 AAAA 记录，假设你的月 PV 中有 20% 来自纯 IPv6 网络（这在移动端占比高的站点是常见量级），那么没有 IPv6 就意味着这 20% 的访客直接访问失败，而不是「慢一点」。

收益二：IPv6 地址不计入某些服务商的 IP 数量限制。 快照里 RosCloud 每个套餐明确是 1 个 IPv4（ipv4_count: 1）。当你需要多 IP 用途——多站点、多业务隔离、避免同 IP 段连带封禁——IPv6 是一份几乎免费的额外地址资源，前提是它真的路由通。

收益三：省掉 NAT 层的转发开销。 如果你的机房给你的是原生 IPv6，流量不需要经过 NAT64 或双栈网关的转换，路径更短，理论上延迟更低。实测差异通常在几毫秒到几十毫秒量级，具体取决于机房架构。

成本侧要算清楚三笔账：

第一笔是配置成本。改 Nginx 监听、加 AAAA 记录、对齐两套防火墙规则、验证客户端行为，每一项本身只要几分钟，但出错时的排查成本很高——尤其是第六节说的「部分通」现象。

第二笔是误封风险。第七节讲的 IPv6 暴露面扩大，是真实的安全成本，不是理论风险。

第三笔是机会成本。同样一笔钱，你可以用来升级配置或流量额度。以真实价格算：把一台 8 核 8 GB、10000 Mbps、20000 GB 流量的 sixtynet LAX-MEDIUM（800 美元/年，折月 66.67 美元）算作参照，它的内存单位成本是 8.33 美元/GB、流量单价 3.41 美元/TB。把同样的钱花在 IPv6 的可用性上，还是花在把内存从 8 GB 提到 12 GB 上，这是个明确的取舍。

但有一条是反过来的：如果你必须支持纯 IPv6 访客，那 IPv6 不是「值不值」的问题，而是「有没有」的问题——没有就是直接丢失这部分流量，没有替代方案。这种情况下，配对的时间成本是必须付出的。

验收阈值：如果决定开 IPv6，用这组数字判定是否算配成功。

检查项	合格线	说明
IPv6 外网连通性	20 次 ping 成功 20 次	失败 1 次即视为路由有问题
AAAA 记录解析	与服务器地址完全一致	不一致说明 DNS 没配对
IPv6 访问 HTTP 状态码	200，且与 IPv4 一致	出现超时或 5xx 即为部分通
IPv4/IPv6 连接耗时差	绝对值小于 50 毫秒	差距大说明路由绕远
IPv6 防火墙放行端口数	与 IPv4 完全相同	多一个就是暴露面
混合网络访问成功率	不低于 IPv4 的 95%	低于此值应关闭 AAAA 记录

查 hostwinds 在售套餐与库存

九、什么情况下不该开 IPv6

这一节给明确的否定答案。依据全部是公开事实——协议支持范围、机房位置、计费方式、IP 资源——不涉及对任何商家好坏的评价。每种情况都配了替代方案。

不该开的情况一：你的业务只面向 IPv4 环境。 依据：企业内网、老旧网络、部分代理环境完全不部署 IPv6。对这类访客，AAAA 记录不产生任何收益，只增加 DNS 查询和回退逻辑的复杂度。

替代方案：不做任何 IPv6 相关配置，把精力放在 IPv4 的响应时间和稳定性上。选型时优先看线路质量和实测延迟。

不该开的情况二：机房没有可确认的 IPv6 路由。 依据：快照里全部 28 个套餐的 ipv6_count 字段为空，云途的 IP 描述明确写的是「IPv4」，sixtynet 的 IP 字段全空。数据层面没有任何一个套餐承诺 IPv6 地址。

替代方案：换机房或换服务商时，把「是否提供可路由的 IPv6」列进需求清单，并要求商家在订单页写明前缀长度和是否支持双栈。这一条对新购机尤其重要——年付套餐（sixtynet 全系）一旦买错无法短期更换。

不该开的情况三：你的安全策略目前只覆盖 IPv4。 依据：IPv4 与 IPv6 使用独立的防火墙表，规则不对等就会产生暴露面。第七节列出的正是这种翻车方式。

替代方案：先花时间把两套规则对齐，再考虑开 IPv6。具体做法是在 ip6tables 里显式复制 IPv4 的规则集，配置完成后用 ss -lntp 逐个端口核对。

不该开的情况四：你的站点有大量第三方回调或白名单机制。 依据：部分支付网关、推送服务、API 集成方的 IP 白名单只记录了 IPv4 地址。这类回调如果你的服务器以 IPv6 源地址发起请求，会被对方的白名单拒绝。

替代方案：对这类出站请求显式强制使用 IPv4，Nginx 层面用 proxy_bind 绑定 IPv4 地址，或在应用层设置连接偏好。

不该开的情况五：你的访客以 IPv4 为主，且你不需要纯 IPv6 网络的覆盖。 依据：现代客户端的双栈回退机制是自动的、透明，IPv4-only 的访客不会因为你没有 IPv6 而受损。

替代方案：保持现状不变，把预算投向响应时间优化（第八节的验收阈值）。

不该开的情况六：你打算用 CDN 代理。 依据：支持双栈的 CDN 在边缘完成协议转换，源站只需 IPv4 就能覆盖 IPv6 访客。此时在源站上配 IPv6 属于重复投入。

查看 interserver 当前月价与库存

替代方案：确认 CDN 是否支持双栈和你源站所在地区的回源线路，把源站 IP 保护在 CDN 后面。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 spinservers 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、结论：四类人该怎么做

第一类：个人博客、企业展示站，访客以国内桌面和移动端为主。 建议暂时不开。理由是收益不明朗而复杂度真实存在——国内移动网络的 IPv6 覆盖确实在扩大，但纯 IPv6 流量占你总流量的比例通常还低，不足以抵消配置和排查成本。把资源投到响应速度上，你的用户感受改善更明显。下单时顺带问一句商家是否支持 IPv6，为将来留个选项。

第二类：面向海外访客、且有大量移动端用户的站点。 建议开，并且认真配对。这类场景下 IPv4-only 网络反而是少数，IPv6 是覆盖率的基础设施而非加分项。按第三节把网卡、路由、DNS、Web 监听四处配全，按第八节的验收阈值逐项确认，再按第七节对齐防火墙。这一类最适合用双栈方案——两个协议同时提供，任一路径故障都能自动回退。

第三类：需要多 IP 用途的建站者（多站点、多业务隔离、避免连带封禁）。 建议先确认商家提供 IPv6 前缀再决定。快照里 RosCloud 明确是 1 个 IPv4，多 IP 需求的成本压力是真实存在的。但只有在确认拿到的是可路由的 /64 前缀、且机房 IPv6 路由质量过关时才值得投入——拿一个路由不通的 IPv6 做多 IP 方案是浪费。

第四类：纯 IPv6 网络内的业务（特定 IoT、运营商合作、跨境专线场景）。 必须开，且不能只靠 IPv6。同时保留 IPv4 作为回退通道，因为运维入口、监控探针、部分第三方服务仍然只有 IPv4 可用。这类场景的正确做法是双栈并行，然后用第四节的脚本持续验证两条链路都健康。

第五类：已经在用 Cloudflare 等双栈 CDN 的站点。 建议源站不用开，除非你确认 CDN 的回源链路对你的源站机房有特殊要求。源站保持 IPv4 简单，IPv6 的覆盖交给边缘层。

查看 itldc 当前月价与库存

不管你属于哪一类，落到操作上都是同一条路径：先向商家确认「这台机器会不会分到一个可路由的 IPv6 地址」，拿到肯定答复再动手。在当前商品库快照里，这个问题的答案对所有套餐都是「没有明确承诺」。IPv6 是一项值得配置的能力，但它从来不是「先开着再说」——先确认资源，再配协议，最后按阈值验收。