JS三种引入方式详解｜行内JS、内部JS、外部JS 优缺点全面对比
2026/7/19 0:55:13
“OpenClaw 明明配好了代理，聊天就是没反应……”
“有时能通有时不能通，玄学网络问题让人崩溃……”
“同样的配置在 Windows 上一切正常，换了 Linux 服务器就开始间歇性断连……”
如果你在用服务器部署 OpenClaw，尤其是 Linux 服务器，这个问题你一定不陌生。很多教程会告诉你“关掉 IPv6”，但只说其一不说其二，你照着做了也不明白为什么有效。
今天这篇文章，就从 IPv6 和 IPv4 的双栈环境差异出发，拆解为什么关掉 IPv6 能让 OpenClaw 的 API 调用稳定许多，并提供一步到位的配置方案。
一、先理解：AI API 调用的网络路径是怎样的？
当你通过 OpenClaw 向大模型 API（如 DeepSeek、Qwen、OpenAI 等）发起请求时，实际路径是这样的：
你的服务器 → 本地网络（DNS解析）→ 互联网路由 → 目标 API 服务器这个过程中第一步就是DNS 解析：把 API 的域名翻译成一个 IP 地址。而“翻译”这一步，恰恰是很多稳定性问题的根源。
当前互联网正处在IPv4 到 IPv6 的过渡期，大多数服务器默认开启了双栈（Dual Stack）网络——既支持 IPv4 也支持 IPv6。当你的 OpenClaw 发起 DNS 查询时，系统会优先尝试 IPv6 解析（因为 IPv6 的 AAAA 记录通常优先于 IPv4 的 A 记录）。如果目标 API 的 DNS 同时返回了 IPv4 和 IPv6 地址，系统会优先尝试 IPv6。而问题就出在这里。
二、为什么 IPv6 可能“拖累”AI API 调用？
2.1 IPv6 的网络环境“不够干净”
AI API 服务商通常会在全球部署 CDN 节点。这些节点的 IPv4 网络经过十几年的优化，已经非常成熟、路由清晰。而 IPv6 虽然技术本身并不落后，但在国内的网络环境中，存在几个现实问题：
| 问题 | 对 OpenClaw 的影响 |
|---|---|
| IPv6 路由未优化 | 某些地区的 IPv6 出口延迟远高于 IPv4，可能导致 API 请求超时 |
| IPv6 DNS 解析不稳定 | 部分公共 DNS 对 IPv6 AAAA 记录的解析响应慢，或返回不正确的地址 |
| 代理服务 IPv6 支持不完善 | 很多代理服务（尤其是国内的隧道代理）主要基于 IPv4 链路优化，IPv6 流量可能走不同的出口，导致代理穿透失败 |
| 防火墙/NAT 对 IPv6 的处理差异 | 一些云服务商的 IPv6 防火墙规则配置不当，可能导致 API 请求被误拦截 |
一个典型的例子是：api.z.ai同时返回 IPv4 和 IPv6 记录，IPv4 地址可以正常工作，但 IPv6 地址完全没有响应。Node.js 优先尝试 IPv6，等待连接超时（约 32 秒）后才失败。这就是很多用户遇到的“LLM request timed out”问题的根源。
核心结论：不是 IPv6“不好”，而是在当前国内网络环境下，IPv4 的路由、DNS、代理链路都更成熟稳定。优先走 IPv4，相当于走了一条“更熟的路”。
2.2 “等待 IPv6 超时 → 降级到 IPv4”的延迟问题
即使你的网络最终能用 IPv4 连上 API，这个过程也可能包含一个隐形的延迟：
系统优先查询 IPv6 AAAA 记录
如果 IPv6 不可达或超时，系统等待超时（通常 3-20 秒）
然后降级尝试 IPv4
这个等待过程会让 OpenClaw 在“转圈”时看起来像卡住了。有用户在 Linux Do 社区反馈：“使用的节点一定不要是 ipv6 或者 ipv6 优先，不然就会出现机器收不到发不出消息的情况”。
2.3 站大爷隧道代理以 IPv4 链路为主进行优化
站大爷的核心产品（如隧道代理、短效代理、独享 IP 池）主要以 IPv4 网络链路为基础进行优化，覆盖全国 300+ 城市的 IP 资源也以 IPv4 为主。在 IPv4 链路上，站大爷的 24 小时连接成功率可达 99.3%。但如果你的服务器优先走 IPv6，代理流量可能走不同的出口链路，导致站大爷的“就近路由”和“智能调度”优势无法完全发挥。
三、如何禁用 IPv6？
3.1 方案一：sysctl 临时禁用（立即生效，重启失效）
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=13.2 方案二：sysctl 永久禁用（推荐）
编辑/etc/sysctl.conf，在文件末尾添加：
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1然后执行：
sudo sysctl -p验证是否生效：
cat /proc/sys/net/ipv6/conf/all/disable_ipv6返回1表示已禁用。
3.3 方案三：GRUB 启动参数禁用（更彻底）
编辑/etc/default/grub，在GRUB_CMDLINE_LINUX中添加：
ipv6.disable=1然后更新 GRUB 并重启：
sudo update-grub # Debian/Ubuntu sudo grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS/RHEL sudo reboot3.4 方案四：Docker 容器中禁用 IPv6
在docker-compose.yml中指定：
services: openclaw: image: openclaw/openclaw:latest sysctls: - net.ipv6.conf.all.disable_ipv6=13.5 方案五：Node.js DNS 解析顺序优先 IPv4（无需禁用系统 IPv6）
如果不想修改系统 IPv6 设置，可以在启动 OpenClaw 时设置环境变量：
export NODE_OPTIONS="--dns-result-order=ipv4first" openclaw gateway start这是 OpenClaw 官方 GitHub Issue 中推荐的临时方案。有用户建议 OpenClaw Gateway 支持 DNS 解析优先级配置选项（如dnsResultOrder: "ipv4first"），让用户无需修改系统 IPv6 设置即可解决问题。
3.6 方案六：Windows 系统禁用 IPv6
打开“网络和共享中心” → “更改适配器设置”
右键点击当前使用的网络连接 → “属性”
取消勾选“Internet 协议版本 6 (TCP/IPv6)”
点击“确定”保存
四、禁用 IPv6 后的效果
根据 OpenClaw 社区和用户的实际反馈，禁用 IPv6 后经常出现的改善包括：
| 改善维度 | 典型表现 |
|---|---|
| API 连接成功率提升 | 之前经常超时的 API 调用明显稳定 |
| 首字延迟降低 | 不再有“先等 IPv6 超时再转 IPv4”的隐形等待 |
| 代理穿透更稳定 | 站大爷隧道代理的 IP 切换更快、更准确 |
| DNS 解析更可靠 | 不再出现 AAAA 记录解析失败导致的连接中断 |
一个真实案例：有用户在 OpenClaw 的 GitHub Issue 中反馈，当 API 服务器同时公布 IPv4 和 IPv6 记录但 IPv6 实际不可达时，网关的 LLM 请求会一致超时约 32 秒。解决方案就是设置NODE_OPTIONS="--dns-result-order=ipv4first"或禁用系统 IPv6。
五、怎么判断你是不是该关 IPv6？
你可以先做一个快速诊断，再决定要不要关：
# 1. 检查当前是否启用了 IPv6 ip addr | grep inet6 # 2. 测试 DNS 解析 IPv6 是否正常 nslookup -type=AAAA api.deepseek.com # 3. 测试 IPv6 连通性 ping6 -c 3 api.deepseek.com判断逻辑：
如果
nslookup返回了 IPv6 地址，但ping6超时或不通 →IPv6 路由有问题，强烈建议关闭如果
ip addr显示有 IPv6 地址，但你用 IPv4 代理（站大爷隧道代理）访问 → 建议关闭避免代理走错出口如果网络一切正常，不关也行，但关掉通常没有副作用
总结
禁用 IPv6 提升 AI API 稳定性的本质，不是 IPv6 技术不行，而是当前网络环境下 IPv4 的路由、DNS、代理链路都更成熟。
很多服务器默认 IPv6 优先，但 IPv6 链路未优化，导致 API 请求超时
站大爷隧道代理基于 IPv4 链路优化，关掉 IPv6 能确保代理流量走最优路径
禁用 IPv6 后，API 连接成功率、首字延迟都有明显改善
核心操作：修改/etc/sysctl.conf，添加三条disable_ipv6=1配置，执行sysctl -p，10 秒搞定。
现在检查一下你的服务器，如果发现 IPv6 开着，不妨试试关掉它。配合站大爷隧道代理的稳定 IPv4 链路，你会发现 OpenClaw 调用 API 的“偶尔卡顿”明显少了。