IPv6无法解析通常源于DNS查询环节故障，而非地址配置问题；需重点检查DNS服务器是否支持AAAA记录、/etc/resolv.conf配置、glibc的IPv6优先级策略、IPv6 DNS流量是否被防火墙拦截，并通过dig和tcpdump验证请求与响应。
IPv6 无法解析，通常不是地址没配好，而是 DNS 查询环节断在了 IPv6 路径上——比如 DNS 服务器本身不支持 IPv6、本地 resolver 配置绕过了 IPv6、或者网络中间链路丢弃了 IPv6 DNS 请求。排查重点不在 ping 通不通，而在“发出去的 AAAA 查询有没有回包”。
确认 DNS 解析器是否启用 IPv6 支持
Linux 默认使用 /etc/resolv.conf 中的 nameserver。先检查它是否指向一个能处理 IPv6 查询的 DNS 服务：
- 运行 cat /etc/resolv.conf，看 nameserver 地址是 IPv4（如 114.114.114.114）还是 IPv6（如 2001:4860:4860::8888）；
- 如果全是 IPv4 地址，系统仍可发 AAAA 查询，但 DNS 请求本身走的是 IPv4 通道——这没问题；真正的问题是：那个 IPv4 DNS 服务器是否实际支持并返回 AAAA 记录？
- 用 dig AAAA example.com @2001:4860:4860::8888 +short 直接向知名 IPv6 DNS 发起查询，验证其响应能力；若超时或无结果，说明该 DNS 不可用或被拦截。
检查本地 resolver 行为与 glibc 配置
Linux 应用通过 libc 的 getaddrinfo() 解析域名，默认按 RFC 6724 规则做地址排序（优先 IPv6）。但某些环境会主动降级：
- 查看 /etc/gai.conf 是否有类似 precedence ::ffff:0:0/96 100 的行——这会强制 IPv4 优先，导致 AAAA 查询被跳过；
- 临时绕过配置测试：运行 getent ahosts example.com，观察输出是否含 IPv6 地址；若无，再试 getent ahostsv6 example.com（专查 IPv6），看是否有 AAAA 返回；
- 若 ahostsv6 有结果但 ahosts 没有，说明 resolver 策略压制了 IPv6，而非 DNS 本身故障。
抓包验证 DNS 查询是否发出及响应
这是最直接的判断方式，能看清请求发没发、发给谁、有没有回包：
- 在终端执行：sudo tcpdump -i any port 53 and ip6 -w dns6.pcap（只捕 IPv6 上的 DNS 流量）；
- 另开窗口运行：dig AAAA example.com；
- 停止抓包后用 Wireshark 打开 pcap，检查：是否有 UDPv6 到 DNS 服务器 53 端口的查询包？是否有来自该服务器的 AAAA 响应？
- 若只有请求、无响应，问题在 DNS 服务器或中间防火墙（如 iptables/ip6tables 丢弃了 DNS 回包）；若连请求都没有，说明应用根本没走 IPv6 DNS 路径（可能是 /etc/resolv.conf 为空、glibc 强制降级，或应用自身禁用了 IPv6）。
排除防火墙和策略路由干扰
IPv6 DNS 流量容易被默认规则误杀：
- 检查 ip6tables -L -n -v | grep :53，确认 OUTPUT 和 INPUT 链是否允许 UDP 53 端口；
- 运行 ip -6 rule show，看是否有自定义策略路由把 DNS 查询导向了错误接口（比如只配了 IPv4 的网卡）；
- 临时关闭防火墙测试：sudo systemctl stop firewalld 或 sudo ip6tables -P INPUT ACCEPT; sudo ip6tables -P OUTPUT ACCEPT，再试 dig；若恢复，则需细化放行规则（如 ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT）。
