阿里雲帳號開戶 阿裡雲 IPv6 網關配置後 ECS 無法透過 IPv6 訪問外網排查指南

先看清问题本质

阿里云 IPv6 网关配置完成后，ECS 仍然无法通过 IPv6 访问外网，这类问题看起来像是“网关没生效”，实际往往不是单点故障，而是链路中某一环没有接上。IPv6 访问外网至少要同时满足几个条件：实例本身拿到了可用的 IPv6 地址，子网和路由表把默认路由正确指向 IPv6 网关，系统内核和防火墙没有把 IPv6 挡住，DNS 能解析到 IPv6 目标地址，出口安全策略也没有拦截流量。只要其中一个环节断开，现象就可能是 ping6 超时、curl -6 无响应、浏览器一直转圈，或者某些站点能访问，某些站点完全打不开。

排查这类问题，不建议一上来就反复重建网关或重启 ECS。先把问题切成几层：实例层、VPC 路由层、安全策略层、DNS 层和目标站点层。只要顺着这条线往下查，通常都能在比较短的时间里找到真正的卡点。

第一步：确认 ECS 自己是否真的具备 IPv6 能力

阿里雲帳號開戶 最容易忽略的一点，是“配置了 IPv6”不等于“系统已经可用”。有些时候控制台里已经看到 IPv6 地址，但系统里并没有拿到默认路由；有些时候地址存在，系统却把 IPv6 协议栈关掉了。先进入 ECS 实例，检查本机状态。

看地址和路由

先执行以下命令：

ip -6 addr
ip -6 route

你要重点看三件事：第一，网卡上是否存在全局可用的 IPv6 地址，而不是只有 lo 或链路本地地址；第二，是否存在 default 或 ::/0 的默认路由；第三，这条默认路由是否指向正确的下一跳。很多故障的根源就在这里：地址有了，但默认路由没有；或者默认路由存在，但下一跳不是 IPv6 网关。

阿里雲帳號開戶 如果 ip -6 addr 只看到 fe80:: 开头的地址，说明这台机器只有链路本地地址，不能直接出公网。若 ip -6 route 里没有默认路由，系统就不知道 IPv6 包该往哪里送。这个时候即便云控制台里的配置是对的，实例内部依然出不去。

做一个最小连通测试

不要一开始就拿复杂业务去测，先用最基础的 IPv6 目标验证链路是否通畅：

ping6 2400:3200::1
curl -6 https://ifconfig.co

第一个命令只是测试 IPv6 基础连通，第二个命令可以验证出站访问和应用层访问是否正常。如果 ping6 不通，但默认路由存在，问题通常在路由表、安全组、NACL 或上游网关。如果 ping6 能通，curl -6 不通，则要进一步怀疑 DNS、目标站点的 TLS、MTU 或应用层策略。

第二步：检查子网、路由表和 IPv6 网关是否真正关联

在阿里云里，IPv6 网关不是“建好就完事”的组件。很多人卡在这里：控制台里已经创建了 IPv6 网关，但子网没有绑定正确的路由表，或者路由表里缺少到 ::/0 的默认路由。结果就是实例看似在同一个 VPC 里，实际上没有 IPv6 出口。

重点看三件事

• 子网是否已经关联到正确的路由表。
• 路由表里是否存在 ::/0 的默认路由。
• 这条默认路由的下一跳是否指向 IPv6 网关，而不是别的目标。

如果你的 VPC 里有多个子网，尤其要小心“创建了路由，但关联错了子网”的情况。这个问题在变更后最常见：前面一切看起来都正确，只有业务所在子网没有吃到新路由。对于排查来说，最有效的做法不是盯着网关资源看，而是直接回到 ECS 所在子网，逐项确认它实际继承了什么路由。

另一个常见误区是把 IPv6 网关和 IPv6 地址混为一谈。ECS 拿到 IPv6 地址，只代表它具备被识别为 IPv6 节点的资格，不代表它已经具备出站路径。真正决定能不能访问外网的，是默认路由是否正确，以及这条路由是否能够把包送出 VPC。

第三步：安全组和网络 ACL 不能只看 IPv4

很多人遇到 IPv6 出网失败，第一反应是怀疑系统防火墙，但在云上更常见的问题其实出在安全组和网络 ACL。尤其是一些从旧环境迁移过来的实例，规则里只放了 IPv4，IPv6 却没有单独配置，结果数据包在云平台边界就被拦下了。

先确认出方向规则

如果你的 ECS 需要主动访问外网，至少要保证安全组出方向允许 IPv6 流量通过。安全组是状态型的，正常情况下，出站放行后，回包也能自动回来；但如果你配置了很严格的自定义规则，或者叠加了网络 ACL，就不能想当然地认为“出方向放开就够了”。

对网络 ACL 来说，情况更复杂一些。ACL 是无状态的，去程和回程都要单独放行。如果只允许了出站，没有允许回包，表面上看请求发出去了，实际上连接会在中途断掉。于是你会看到一个非常迷惑的现象：ping6 偶尔有响应，HTTPS 却不稳定，或者连接建立后立刻超时。

别忽略主机防火墙

云侧规则放行后，主机内部的防火墙仍然可能拦截流量。检查 iptables、nftables、firewalld 或 ufw 的 IPv6 规则，确认没有把出站流量拦掉。很多发行版会分别维护 IPv4 和 IPv6 规则文件，改了一个，另一个却没改，最后出现“IPv4 正常、IPv6 异常”的假象。

如果机器上曾经跑过安全加固脚本，还要看一下是否把 IPv6 协议直接禁掉了。某些基线脚本为了图省事，会把 net.ipv6.conf.all.disable_ipv6 设成 1，结果系统层面根本不再处理 IPv6 包。这个问题一眼看上去像网络故障，本质却是内核参数被改坏了。

第四步：检查系统内核参数和网络栈状态

云上网络配置正确，不代表操作系统没有问题。尤其是使用自定义镜像、老旧系统模板，或者经历过大量运维手工改动的 ECS，IPv6 相关参数最容易被遗漏。

看几个关键项

sysctl net.ipv6.conf.all.disable_ipv6
sysctl net.ipv6.conf.default.disable_ipv6
sysctl net.ipv6.conf.all.accept_ra

如果 disable_ipv6 为 1，说明 IPv6 被关闭了，需要改回 0。accept_ra 的值要结合场景判断，但对普通 ECS 来说，通常不应该把它设置得过于激进，尤其是在你依赖路由通告或自动获取路由信息的时候。很多“刚配置完能通，过一会儿又不通”的问题，最后都落在这里。

另外还要注意，某些系统虽然显示有 IPv6 地址，但应用层仍然优先走 IPv4。比如你测试域名时没加 -6 参数，程序可能默认选了 IPv4 路径，于是误以为 IPv6 已经正常。真正要验证 IPv6 出口，必须强制走 IPv6 路径，否则测试结果没有意义。

第五步：DNS 是不是只会解析 IPv4

很多人说“我已经能 ping 域名了，为什么还是不行”，其实这句话本身就有问题。ping 只能说明域名解析到了可用地址，不代表解析到的是 IPv6。对于 IPv6 出网，必须确认目标域名返回的是 AAAA 记录，而不是只有 A 记录。

做一次明确的解析检查

dig AAAA example.com
nslookup -type=AAAA example.com

如果查不到 AAAA 记录，说明这个站点本身就不提供 IPv6 地址。此时你用 curl -6 访问它，失败是正常结果，不是你 ECS 的问题。很多排查被拖慢，就是因为把“目标站点没有 IPv6”误判成“本机 IPv6 出口坏了”。

还有一种情况是系统 DNS 返回了 AAAA，但实际访问被中间代理、透明网关或本地解析策略改写了。对于这类问题，建议直接用 curl -6 指定 URL 再配合抓包看结果，不要只看域名解析是否成功。

第六步：MTU 和路径问题经常被低估

如果你发现小包能通，大流量或 HTTPS 经常卡住，不要只盯着安全组。IPv6 场景下，路径 MTU 问题比很多人想象得更常见。特别是当实例挂了额外的代理、VPN、隧道，或者上层网络做过封装，包长一大就可能触发分片或路径发现异常。

可以先用较小的数据包测试，再逐步增加长度，观察是否在某个阈值后开始失败。若现象明显，说明不是简单的“网关不通”，而是路径上的某一段丢弃了需要的 ICMPv6 消息，导致 PMTU 发现失败。IPv6 对这类控制报文非常敏感，很多“网页能开头，加载到一半就停住”的问题，都和 MTU 有关。

第七步：用抓包把问题定到具体一层

当路由、规则、DNS 都看过一遍，还是找不到问题时，最有效的办法就是抓包。抓包不是为了炫技，而是为了回答一个简单问题：包到底有没有从机器上出去，回来的包又卡在哪一层。

抓包思路

在 ECS 上执行：

tcpdump -i eth0 ip6

然后再发起一次 ping6 或 curl -6 请求。观察现象时，重点分三种情况：

• 能看到请求发出，但看不到任何回包：大概率是路由、网关或上游安全策略问题。
• 请求和回包都能看到，但应用仍然失败：可能是本机防火墙、MTU 或应用协议问题。
• 连请求包都没有发出去：说明问题在本机协议栈、路由表或程序调用层。

抓包的价值在于，它能把“感觉像网络问题”的模糊判断，变成“包有没有出去”“回包有没有回来”这种非常具体的结论。定位到这一层之后，后面的修复动作就会很明确。

常见误区：IPv6 网关不是 IPv4 访问工具

这一点必须单独说清楚。很多人配置 IPv6 网关时，默认以为它能同时解决 IPv4 外网访问，或者能让所有域名都正常打开。实际上不是这样。IPv6 网关解决的是 IPv6 路径问题，不是把 IPv4 站点自动翻译成 IPv6。换句话说，如果你访问的目标站点只有 IPv4 地址，没有 AAAA 记录，那么从纯 IPv6 环境出发，本来就不应该直接连上。

所以在排查时，要先区分两类失败：一类是“IPv6 到 IPv6 的链路不通”，这属于基础网络配置问题；另一类是“IPv6 去访问只有 IPv4 的站点失败”，这属于目标地址能力不匹配的问题。前者查路由和安全组，后者查站点是否支持 IPv6，必要时再考虑代理、NAT64 或双栈方案。

阿里雲帳號開戶 按优先级整理一份实战排查顺序

如果你现在就要处理一个线上故障，可以按下面顺序执行，效率最高：

• 先在 ECS 内部执行 ip -6 addr 和 ip -6 route，确认地址和默认路由存在。
• 再检查子网关联的路由表，确认 ::/0 指向 IPv6 网关。
• 随后检查安全组出方向、网络 ACL 和本机防火墙，确认没有把 IPv6 流量拦掉。
• 接着用 dig AAAA 或 curl -6 验证目标站点是否真的支持 IPv6。
• 最后再看 MTU、系统参数和抓包结果，把问题锁定到具体层面。

阿里雲帳號開戶 这套顺序的好处是，不会在一开始就把时间浪费在无关位置。你先把最基础的链路打通，再去看复杂问题，定位会快很多。

结尾：让排查回到链路本身

阿里云 IPv6 网关配置后，ECS 仍然无法通过 IPv6 访问外网，真正难的地方不在“有没有一个网关”，而在于整条链路是否完整。地址、路由、策略、系统、DNS、目标站点，这六个环节缺一不可。只要你按照从内到外的顺序检查，通常都能很快分辨出是云侧路由问题、系统配置问题，还是目标站点根本不支持 IPv6。

实战里最有效的习惯，是把每一步都做成可验证动作，而不是凭感觉判断。能不能拿到地址，能不能看到默认路由，能不能发出 IPv6 包，能不能解析到 AAAA，能不能从外部看到返回流量。把这些问题逐个回答清楚，IPv6 故障就不再神秘。配置网关只是开始，真正决定可用性的，是链路上的每一个细节都没有掉链子。