当拿到一个 /64 IPv6 网段后，能做些什么？

很多人买 IPv6 VPS 时，会看到商家写着：

IPv6 Prefix: /64

然后第一反应是：不就是一个 IPv6 地址吗？

当然不是。

如果服务商真的把整个 /64 路由给了你的服务器，那么你拿到的并不是一个 IPv6，而是一整个巨大的 IPv6 地址空间。

一个 /64 包含：

2^(128-64) = 2^64

也就是：

18,446,744,073,709,551,616

个 IPv6 地址。

当然，现实中你几乎不可能真的使用这么多地址，但它带来的意义并不是地址数量多，而是你可以给不同服务、不同进程、不同容器、不同用途分配完全独立的公网 IPv6。

这和传统 IPv4 VPS 的体验完全不同。

假设服务器拿到的网段是：

2a0c:9a40:9210:4::/64

默认 IPv6 是：

2a0c:9a40:9210:4::164

如果服务商没有限制，你可以继续给网卡添加：

2a0c:9a40:9210:4::100

2a0c:9a40:9210:4::101

2a0c:9a40:9210:4::102

2a0c:9a40:9210:4::103

Linux 上甚至只需要一条命令：

ip -6 addr add 2a0c:9a40:9210:4::100/64 dev eth0

然后查看：

ip -6 addr show dev eth0

如果配置正常，这个地址就已经属于这台服务器了。

但真正关键的不是能不能加上，而是要测试服务商是否真的允许这些地址通信。

例如强制使用新 IPv6 出站：

curl -6 \

  --interface 2a0c:9a40:9210:4::100 \

  https://api64.ipify.org

如果返回：

2a0c:9a40:9210:4::100

说明这个新增地址确实能够作为公网出口。

进一步，在服务器上监听：

python3 -m http.server 8080 \

  --bind 2a0c:9a40:9210:4::100

然后从另一台 IPv6 主机访问：

curl -g -6 \

  'http://[2a0c:9a40:9210:4::100]:8080/'

如果也成功，那么基本可以确认这个 /64 不只是面板里写着好看，而是真的可以使用。

一、不同服务使用不同公网 IP

这是 /64 最直观的玩法。

传统 VPS 往往是：

一个公网 IPv4

├── 80   网站

├── 443  HTTPS

├── 22   SSH

├── 5201 iperf3

└── 其他服务

所有服务都共享同一个公网 IP。

有了 /64 后，可以变成：

::100  网站

::101  API

::102  监控

::103  iperf3

::104  DNS

::105  代理服务

这样服务之间在网络身份上可以完全分离。

甚至相同的端口都可以重复使用。

例如：

[::100]:443

[::101]:443

[::102]:443

三个服务都监听 443，但因为 IP 不同，所以完全不冲突。

这在做多站点、多实例、多协议实验时非常方便。

二、让不同程序拥有不同出口 IP

这是更有意思的地方。

例如：

curl --interface 2a0c:9a40:9210:4::100 https://api64.ipify.org

curl --interface 2a0c:9a40:9210:4::101 https://api64.ipify.org

curl --interface 2a0c:9a40:9210:4::102 https://api64.ipify.org

服务器虽然只有一张网卡，但是外部网站看到的却是三个不同 IPv6。

因此可以设计：

程序 A → ::100

程序 B → ::101

程序 C → ::102

这对于：

• 网络测试
• 多出口测试
• API 连通性测试
• CDN 测试
• DNS 测试
• IPv6 应用开发

都很方便。

三、搭建 IPv6 网络探针

如果你本身有多台服务器，那么 /64 VPS 很适合变成一个网络探针节点。

例如定时执行：

ping -6

mtr -6

traceroute -6

curl -6

dig AAAA

iperf3

可以监测：

美国 → 日本

美国 → 香港

美国 → 欧洲

美国 → Cloudflare

美国 → Google

长期记录后，还能得到：

• RTT 延迟
• 丢包率
• 路由变化
• 网络抖动
• IPv6 可达性
• 不同运营商线路变化

这样一台很便宜的 VPS，实际上可以变成自己的小型 RIPE Atlas。

四、测试网站真正的 IPv6 支持

很多网站虽然有 AAAA 记录，但 IPv6 并不一定真的工作正常。

比如可以测试：

dig AAAA example.com

然后：

curl -6 https://example.com

或者：

mtr -6 example.com

这样可以检查：

• AAAA 是否配置正确
• IPv6 HTTPS 是否正常
• CDN 是否支持 IPv6
• IPv6 路由是否异常
• IPv6 与 IPv4 延迟差异

如果自己运营网站，甚至可以专门从这个 VPS 定期检测 IPv6 可用性。

五、做多地址 Web 服务

假设一台机器有：

::100

::101

::102

Nginx 可以分别监听：

listen [2a0c:9a40:9210:4::100]:443 ssl;

listen [2a0c:9a40:9210:4::101]:443 ssl;

listen [2a0c:9a40:9210:4::102]:443 ssl;

于是同一台服务器可以拥有多个独立公网入口。

这比传统依赖端口区分服务更干净。

甚至可以做到：

IPv6 A → 网站 A

IPv6 B → 网站 B

IPv6 C → API

IPv6 D → 测试环境

六、给 Docker 或容器分配公网 IPv6

这是 /64 很适合玩的一个方向。

传统 Docker 经常：

公网 IP

   ↓

宿主机 NAT

   ↓

容器

而 IPv6 的设计理念本来就不是依赖 NAT。

如果路由和 Docker 网络配置正确，可以做到：

宿主机    ::100

容器 A    ::101

容器 B    ::102

容器 C    ::103

每个容器直接拥有公网 IPv6。

这样很多网络结构会简单很多。

例如：

Internet

   │

   ├── ::101 → nginx container

   ├── ::102 → API container

   └── ::103 → monitoring container

不再必须依赖大量端口映射。

七、虚拟机和 LXC 也可以拥有独立 IPv6

如果 VPS 支持嵌套虚拟化或者运行 LXC，那么理论上还可以进一步：

宿主机        ::100

LXC-1         ::101

LXC-2         ::102

LXC-3         ::103

每个虚拟环境都有自己的公网 IPv6。

从网络角度，它们就像不同服务器一样。

这也是 IPv6 地址空间充足之后非常自然的一种架构。

八、测试源地址选择和多地址行为

IPv6 一个很值得研究的地方，就是 Source Address Selection。

如果一台 Linux 同时拥有：

::100

::101

::102

::103

那么：

curl https://example.com

系统到底会选择哪一个？

可以进一步研究：

ip -6 route get

例如：

ip -6 route get 2606:4700:4700::1111

系统会告诉你类似：

via ...

dev eth0

src 2a0c:...

这对于理解 Linux IPv6 路由、源地址选择、策略路由非常有帮助。

九、配合策略路由

进一步还可以做到：

用户 A → ::100 出口

用户 B → ::101 出口

程序 C → ::102 出口

可以结合：

ip rule

ip route

fwmark

nftables

做 IPv6 Policy Routing。

例如：

进程/流量类型

      ↓

nftables mark

      ↓

ip rule

      ↓

不同 source IPv6

这是比较高级，但也非常有实验价值的玩法。

十、跑 IPv6 Only 服务

如果这台 VPS 本身就是 IPv6 Only，那么也非常适合拿来检查自己的软件到底有没有偷偷依赖 IPv4？

很多程序平时在双栈环境下工作正常，但放到 IPv6-only 环境之后，会暴露很多问题：

• DNS 只查 A 记录
• 程序写死 IPv4 地址
• 第三方 API 不支持 IPv6
• Docker 网络不支持 IPv6
• 软件默认绑定 0.0.0.0
• 数据库连接地址只有 IPv4
• SDK IPv6 兼容问题

所以 IPv6-only VPS 本身就是一个非常好的兼容性测试环境。

十一、可以研究 NAT64

IPv6-only VPS 最大的问题是：如果目标网站只有 IPv4 怎么办？

这就会涉及：

NAT64

DNS64

464XLAT

例如 IPv6-only 客户端：

IPv6 Client

    ↓

DNS64

    ↓

NAT64 Gateway

    ↓

IPv4 Internet

如果服务商本身提供 NAT64，那么 IPv6-only VPS 甚至可以访问 IPv4-only 网站。

这也是非常值得研究的网络技术。

十二、搭建 DNS 服务

有一个 /64 后，可以给不同 DNS 服务分配独立地址。

比如：

::53     Unbound

::54     SmartDNS

::55     dnsmasq

::56     测试 DNS

当然地址尾数完全可以自己定义。

可以对比不同 DNS：

• 响应时间
• AAAA 解析
• DNSSEC
• ECS
• 缓存命中
• DoH/DoT

对于网络实验来说很方便。

十三、做 iperf3 测速节点

例如：

iperf3 -s

然后从其他机器：

iperf3 -6 -c 2a0c:9a40:9210:4::101

可以测试：

东京 → 美国

香港 → 美国

欧洲 → 美国

国内 → 美国

的 IPv6 带宽。

如果你有多个 VPS，这种节点非常实用。

十四、给监控系统单独分 IP

例如：

::100  Prometheus exporter

::101  uptime monitor

::102  HTTP health check

::103  network probe

这样日志里看到目标 IP 就能知道是哪项服务。

相比 同一个 IP + 一堆不同端口，可读性会好很多。

十五、可以构建自己的 IPv6 实验室

实际上，一个真正能使用 /64 的 VPS，本质上已经是一座小型 IPv6 实验室。

你可以拿它研究：

IPv6 地址配置

IPv6 路由

NDP

SLAAC

静态 IPv6

多源地址

策略路由

DNS64

NAT64

IPv6 防火墙

Docker IPv6

Nginx IPv6

Tailscale IPv6

WireGuard IPv6

BGP 基础

网络监控

而且不需要非常高的服务器配置。

因为这些实验大部分吃的是网络，而不是 CPU 和内存。

所以哪怕只有：

1 Core

512 MB RAM

10 GB Disk

依然可以玩很多东西。

但有一个非常重要的误区

看到 /64 不等于一定可以随便使用整个 /64。

有些 VPS 服务商虽然系统显示：

xxxx:xxxx:xxxx:xxxx::/64

但上游实际上可能限制：

只能使用分配给你的一个 IPv6

或者做：

NDP 限制

MAC/IP Binding

Source Address Filtering

Anti-Spoofing

所以一定要实际验证。

至少做两个测试。

第一：

ip -6 addr add 新IPv6/64 dev eth0

curl -6 --interface 新IPv6 https://api64.ipify.org

验证出站。

第二：

python3 -m http.server 8080 --bind 新IPv6

从另外一台 IPv6 主机：

curl -g -6 'http://[新IPv6]:8080/'

验证入站。

只有这两个都成功，才可以比较有把握地说服务商真的把这个 /64 给你用了。