Nginx正向代理双栈访问的核心是resolver配置与上游连接控制：需显式指定IPv6/IPv4双栈DNS服务器（如resolver 2001:4860::8888 8.8.8.8 valid=30s），或禁用IPv6解析（ipv6=off）规避不稳定AAAA记录；依赖系统gai.conf调整优先级或proxy_bind绑定IPv4出口；并通过tcpdump、debug日志及curl测试验证实际连接协议与fallback时效。
在 Nginx 作为正向代理（例如代理内部服务访问公网 API）时，要同时支持 IPv4 和 IPv6 双栈外网访问，核心不是监听本地端口的双栈配置，而是确保 Nginx 能正确解析、选择并连接上游目标的 IPv4/IPv6 地址——尤其当上游域名同时提供 A 和 AAAA 记录时。常见问题如 connect() to [2402:...]:443 failed (101: Network is unreachable) 就源于此。
确保 resolver 支持 IPv6 DNS 查询
Nginx 默认 resolver 不自动启用 IPv6 查询。需显式配置支持双栈解析：
- 使用系统 DNS（推荐）：
resolver 2001:4860:4860::8888 8.8.8.8 valid=30s;
同时指定 IPv6 和 IPv4 的 DNS 服务器，Nginx 会按顺序尝试，优先返回可用地址。 - 禁用 IPv6 解析（临时规避）：
resolver 8.8.8.8 ipv6=off;
强制只查 A 记录，适用于上游 AAAA 不稳定场景（如微信 API）。 - 避免仅写 IPv4 resolver：
单写resolver 8.8.8.8;仍可能触发 IPv6 连接失败（取决于操作系统 getaddrinfo 行为），必须明确控制。
控制 upstream 连接优先级与 fallback
Nginx 本身不内置“IPv4 优先 fallback”逻辑，依赖底层 libc 的 getaddrinfo() 结果顺序。可通过以下方式干预：
- 在操作系统层面设置策略（生效范围广）：
编辑/etc/gai.conf，取消注释并调整：precedence ::ffff:0:0/96 100
这会让 IPv4-mapped IPv6 地址优先级高于原生 IPv6，间接实现 IPv4 优先。 - 使用
proxy_bind绑定特定协议栈（精细控制）：proxy_bind $remote_addr transparent;或指定 IPv4 接口；
若需强制走 IPv4，可写proxy_bind 192.168.1.100;（对应 IPv4 出口 IP）。 - 避免依赖不可靠的 AAAA：
对已知 IPv6 不稳定的上游（如api.weixin.qq.com），直接在upstream块中硬编码 IPv4 地址：upstream wechat_api { server 119.29.29.29:443; }
验证与调试关键点
双栈正向代理是否真正可靠，不能只看 Nginx 启动成功，而要看实际请求路径：
- 检查 resolver 是否生效：
在配置中添加error_log /var/log/nginx/proxy.log debug;，观察日志中resolving行是否同时输出 A 和 AAAA 地址。 - 确认连接使用的 IP 协议：
用tcpdump -i any port 443抓包，过滤ip6或ip，确认出向连接是 IPv4 还是 IPv6。 - 测试 fallback 延迟：
模拟 AAAA 不可达（如屏蔽 IPv6 路由），用curl -v http://example.com观察是否在超时后自动切到 IPv4 —— 正常应在 1–3 秒内完成，而非默认 5 秒以上。 - 注意 timeout 设置：
proxy_connect_timeout 5s;可缩短 IPv6 失败后的等待时间，加快 fallback。
防火墙与网络层必须连通
即使 Nginx 配置正确，若底层不通，一切无效：
- 确保服务器已启用 IPv6：
sysctl net.ipv6.conf.all.disable_ipv6返回0；ip -6 addr show应显示有效 global scope IPv6 地址。 - 开放出向 IPv6 连接：
ufw：允许out on eth0 to any port 443 proto tcp；
iptables：检查ip6tables -L OUTPUT是否放行 ESTABLISHED 和 NEW 连接。 - 验证公网可达性：
ping6 -c 3 google.com和curl -6 https://google.com -I必须成功，否则问题不在 Nginx 层。
