自己遇到的 本机的tun模式影响hermes调用newapi

自己小白一枚，把自己这段时间遇到的hermes调用newapi报错的一个问题初步解决了，大概的情况分享下。

佬们的回复我可能不会回复，因为我是真的不懂，只是因为ai才把这问题解决了。

不太会专业术语或者表达不准确，具体分析让AI整理成html文档，7-zip压缩放在附件里了。

源于薅老黄的免费api

注册了一百多个老黄的免费api，平均分配扔在7台美日的vps上，每台10～20个老黄账号。大概是这样调用的：

hermes → newapi/sub2api(7台vps聚合) → sub2api(10~20账号) → integrate.api.nvidia.com

在sub2api里有时候会出现输入输出都是0的错误。

在newapi里长上下文经常就会报错（下图）：

解决：

这问题从开始用这套调用就一直存在，自己也修改过透传、流式、出口ip等等，依然报错。

今天把整个链路的超时时间提高到900s，依然无解。

这里要吐槽下，之前解决这个问题一直用的glm-5.3-max，让他分析了三四次了都没解决。。。

今天用的gpt-terra-xhigh，terra第一次让我调整的超时时间，没管用。第二次给我分析的是tun模式导致的，让我试着关闭tun模式后就解决了。

而且terra的思路很清晰，分析了哪些数据、最可能是哪里的问题，感觉思路清晰而且我这小白能看懂了。

而后ai大概排除了服务器层面，认为可能是我本机：

这说明更可能是本机 TUN/代理路径在流连接期间短暂重置或 DNS 瞬断

然后把tun关闭，切换到系统代理，这才解决了。下面是解决后的调用情况：

结论

• 中途 WinError 10054 / client_gone错误：主要由本机 TUN + gVisor 长流转发路径触发或放大。


• 系统代理：绕过该 TUN 数据面，因此稳定性更好。

附件：

Hermes-v2rayN-TUN-长流稳定性分析-2026-10-02.zip (5.3 KB)