大模型应用全面支持 IPv6：从入口可达走向端到端可用

预计阅读时间：7 分钟

中央网信办联合北京、上海、浙江、深圳四地网信办，并会同 5 家头部大模型企业，在雄安新区启动“人工智能大模型 IPv6 能力提升专项行动”。这项行动指向一个正在变得具体的工程问题：随着生成式 AI 应用增长，Token 流量快速上升，模型服务需要更强的网络承载能力，而“支持 IPv6”不能只停留在域名增加一条 AAAA 记录。

对大模型平台而言，真正的 IPv6 能力覆盖客户端接入、负载均衡、API 网关、推理服务、数据访问、监控告警和故障切换。任何一段只支持 IPv4，都可能让整个调用链退回旧路径，甚至出现连接超时。

Token 流量改变了网络压力模型

传统 Web API 往往在较短时间内完成一次请求与响应。大模型接口则经常使用 SSE 或其他流式传输方式，连接持续时间更长，响应由大量 Token 分批返回。并发用户增加后，平台同时承受连接数、带宽、网关状态和超时管理等压力。

IPv6 能力提升并不意味着 IPv6 本身会自动解决这些问题。它的直接价值在于扩大地址空间、减少对复杂地址转换的依赖，并为终端、边缘节点和云服务之间建立更清晰的端到端连接基础。平台仍需单独验证长连接容量、首 Token 延迟、连接重置率和双栈切换行为。

工程验收至少应覆盖以下链路：

公网域名同时发布 A 和 AAAA 记录。
CDN、WAF、负载均衡器和 API 网关能够通过 IPv6 接收连接。
网关到推理服务、向量数据库及对象存储的内部链路符合既定双栈策略。
日志、限流、访问控制和审计系统能够正确存储与匹配 IPv6 地址。
IPv6 不可用时，客户端可以按预期回退，并且不会经历过长等待。

“能够解析”不等于“能够调用”

一条 AAAA 记录只能证明 DNS 配置存在，不能证明服务可用。常见缺口包括防火墙未放行 IPv6、程序只监听 IPv4 地址、证书与域名不匹配，以及上游代理无法连接 IPv6 后端。

可以这样实践：把下面脚本保存为 check-ipv6.sh，将 api.example.com 和 /v1/models 改成待测服务，然后执行。脚本会分别检查 DNS、IPv4 HTTPS 和 IPv6 HTTPS。

#!/usr/bin/env bash
set -euo pipefail

HOST="${1:-api.example.com}"
PATH_TO_CHECK="${2:-/v1/models}"
URL="https://${HOST}${PATH_TO_CHECK}"

echo "== DNS A =="
dig +short A "$HOST"

echo "== DNS AAAA =="
dig +short AAAA "$HOST"

echo "== IPv4 HTTPS =="
curl -4 --fail --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  -o /dev/null -w 'status=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  "$URL"

echo "== IPv6 HTTPS =="
curl -6 --fail --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  -o /dev/null -w 'status=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  "$URL"

运行方式：

chmod +x check-ipv6.sh
./check-ipv6.sh api.example.com /health

如果 AAAA 查询有结果，但 curl -6 失败，应依次检查本机 IPv6 出口、云安全组、网络 ACL、负载均衡器监听器和应用进程监听地址。不要直接把问题归因于 DNS。

给模型 API 配置双栈入口

假设模型服务运行在 127.0.0.1:8000，可以这样实践：使用 Nginx 同时监听 IPv4 与 IPv6，并为流式输出关闭代理缓冲。以下配置需要替换域名和证书路径。

upstream model_backend {
    server 127.0.0.1:8000;
    keepalive 64;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/privkey.pem;

    location /v1/ {
        proxy_pass http://model_backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

检查并加载配置：

sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp | grep ':443'

这里的重点不只是出现 [::]:443。还要确认操作系统的 bindv6only 行为、云负载均衡器是否启用 IPv6，以及真实客户端地址是否经过可信代理头传递。限流系统若把 IPv6 地址错误截断，可能导致大量用户共享同一个限流桶。

按链路推进，而不是一次性切换

大模型平台适合采用双栈渐进方案：先建立 IPv4 基线，再启用 IPv6 测试域名和小比例流量，观察连接成功率、首 Token 延迟、流中断率及状态码分布，确认稳定后再扩大范围。

上线前可以使用这份检查表：

DNS、证书、WAF、负载均衡器和网关均完成 IPv6 验证。
健康检查同时覆盖 curl -4 与 curl -6。
SSE 等流式接口经过长连接和连接中断测试。
日志平台保留完整 IPv6 地址，并对敏感网络标识执行必要的脱敏与访问控制。
限流、黑白名单和风控规则支持 IPv6 地址及网段表达。
监控看板能够按 IP 协议版本拆分成功率与延迟。
回退方案已演练，撤销 AAAA 记录时考虑 DNS TTL 和缓存影响。

专项行动给出了明确方向，具体成效仍取决于每条生产调用链的改造质量。对于大模型服务，IPv6 验收标准不应是“域名能解析”，而应是“真实用户可以稳定建立连接、持续接收 Token，并在异常时被监控系统准确识别”。

大模型应用全面支持 IPv6：从入口可达走向端到端可用

Token 流量改变了网络压力模型

“能够解析”不等于“能够调用”

给模型 API 配置双栈入口

按链路推进，而不是一次性切换

相关推荐

建议反馈