模型接口要挂代理才能通，和账号登录冲突了怎么办？

一、模型通了，三个账号一天内全掉登录

去年十月，我们给媒体助理接了两个国外的模型接口。这两个接口直连是不通的，用户自己配了代理服务器才能调，我们顺势把代理做进了基础设置层，填地址端口就能用。功能上线第二天，运营反馈说有三个账号同时触发了登录验证，都是同一个现象，账号在异地登录，平台要求重新验证，其中两个账号的发布权限被临时限制了。

排查的过程有点反直觉。我们查了这三个账号的登录记录，登录时间、设备指纹都正常，明显异常的是登录请求的出口地址，全走了代理服务器。代理本来是给模型调用开的，账号登录的请求不知道怎么也跟着走了同一条出口。平台侧看到的就是一个账号昨天还在本地登录，今天换了个境外地址登录，风控模型直接判定异常。

那三天里我们做了个粗统计，挂着代理登录的账号，触发验证的比例接近一半，不挂代理的账号一次都没触发。用户侧体感更差，有用户的账号被限制发布，以为是我们的工具有问题，要退订。这件事让我们意识到，代理不是配一次就完事的开关，它和账号登录之间的关系必须有人管。

二、出口只有一根管，两类流量互相污染

问题的本质在于出口没有分类。软件里发出去的请求分两类，一类是模型调用，走模型服务商的接口，目标地址在国外，本来就该走代理。另一类是媒体账号登录，走的是平台侧的登录接口，平台看的是账号的登录地和设备，本该走用户本地直连。两类流量性质完全相反，却共用同一个出口，代理一开，模型通了，账号登录也被送到了境外。

直觉做法是代理分使用时段，比如用模型的时候开，用完手动关。这条路的问题是把安全依赖在了人的记性上。用户跑完模型去干别的，代理就挂在头上，哪天用媒体账号登录一下，验证就来了。我们自己的运营同事都忘过关过两次，何况是面向用户的产品。工具层面的约定不能建立在用户自律上。

还有一层是健康检查的缺失。早期版本代理配了就不管了，通不通、快不快、目标模型域名能不能达，全都没有探测。用户配错地址端口，要等到调用模型超时才知道，而超时是三十分钟后的事。出口这条路本身的质量，也需要在调用前就心里有数。

三、两条路，一条图省事，一条分得清

第一条路是代理全局开关，用户自己掌握，开就全走，关就全不走，工具只负责提供入口和文档提醒。这条路实现最省事，配置项一个布尔值加一个地址端口。代价是把冲突原样留给用户，账号验证的锅也由用户背，工具的口碑跟着吃亏。我们内部评估过，这条路等于把第一版的问题原样发布。

第二条路是出口分离，代理只对模型流量生效，账号登录、媒体发布这类账号行为强制走本地直连，模型调用完代理自动关闭。代价是实现复杂一圈，每一类请求都要标清它该走哪条出口，切换要有开销控制，代理的健康检查也要单独做。还有切换时机，开太早浪费，关太晚会污染下一次登录。

我们选第二条。理由很直接，这个工具的核心价值是帮用户同时管好模型调用和账号运营两件事，两件事的出口混在一起是工具的失职，不是用户的错误。分离之后，代理从一个全局开关变成一个只在模型调用期间生效的临时通道，账号行为的干净程度有了机制保障。

四、出口分离加用完即关

AI智能媒体助理把代理出口和媒体账号登录分开管，模型调用完代理就建议关掉。具体做法是在基础设置层把代理配置拆成三块，开关、地址端口、生效范围，生效范围默认锁定为仅模型调用，这个默认值不给用户改，账号登录和媒体发布永远走本地直连。模型调用开始时临时挂上代理，调用结束无论成败都关掉，关掉这个动作是代码里的 finally，不是用户界面上的一个提醒。

用完即关还带一层兜底。万一哪条异常路径漏了 finally，代理会一直挂着，下次账号登录就中招。兜底是启动自检，软件启动时检查代理残留状态，发现有上次没关的，直接关掉并记一条提示日志。这个自检救过我们两次，都是凌晨的定时任务异常退出导致的残留。

代理的健康检查做在调用前。点保存配置的时候探一次连通性，测一次到目标模型域名的延迟，超时五秒判不可用。配置界面直接显示结果，连通加延迟多少毫秒，不通就告诉用户是地址错了还是端口不通。这个检查不拦截调用，只提供信息，真正调用时的失败还是走任务层的重试。

五、配置字段和调用链的伪代码

代理相关配置收敛成四个字段。proxy_enabled 是总开关，proxy_addr 是地址端口，proxy_scope 是生效范围，默认锁死 model_only，proxy_health 记最近一次健康检查的结果和时间。模型路由表按模型名分流，每个模型一条路由，路由里标注需不需要代理、走哪个代理、目标域名是什么，多模型多出口的切换靠这张表，不在代码里写死。

多模型多出口是这张路由表的自然延伸。有的模型走代理 A，有的走代理 B，还有的国内模型压根不需要代理，路由表里每行配齐，调用时按模型名查表。用户换了代理服务器，改表里对应行，不动代码。这个表早期写在配置文件里，后来挪到设置界面，用户换代理的频率比预期的高。

延迟数据也顺手沉淀了下来，每次健康检查和每次调用都记录延迟，任务详情里能看到这个模型的出口质量趋势。有用户反馈某个模型时快时慢，我们把延迟曲线调出来，发现每天晚高峰延迟翻三倍，那是代理服务器本身的带宽问题，换一台就解决了。没有这份数据，这类问题只能靠猜。

六、三个坑，每个都付过学费

第一个坑是异常路径漏关代理。上线两周后，有用户第二天早上账号批量触发验证，一查代理从凌晨挂到了早上。根因是模型调用里有一条异常分支提前返回了，没走 finally 的关闭逻辑，代理就那么挂在进程状态里。改法是把开关收敛到调用链路的进出两个点，中间任何路径返回都必须经过 finally，再补上启动自检兜底。改完之后，代理挂过夜这类事再没发生过。

第二个坑是健康检查通过但调用照样失败。有用户配置保存时显示连通、延迟 80 毫秒，一调用模型就超时。根因是健康检查只探了代理服务器通不通，没探代理到目标模型域名这条完整链路，代理服务器活着，但它到模型服务商的出口是堵的。改法是健康检查带上目标域名探活，用一次轻量请求验证完整链路，只探代理端口的旧版逻辑废弃。

第三个坑是系统代理和软件代理打架。有用户自己开着系统代理，又在我们软件里配了一个代理，两层叠加，请求在两层之间打转，模型调用全部超时。根因是软件只管自己设的进程级代理，不知道用户还挂了系统级代理，两层同时生效互相打架。改法是软件只用进程级代理，启动和退出都不碰系统代理设置，健康检查的结果里加一条系统代理检测提示，发现用户开着系统代理就提醒可能冲突。

七、这层解决不了的事

出口分离把账号验证的概率降了下来，但没有降成零。平台侧的风控是黑盒，除了登录地，它还看设备指纹、登录频率、行为序列，这些维度里任何一项异常都可能触发验证。我们能守住的是登录地这一维干净，其他维度该验证还是会验证，这个预期要提前讲清楚。

还有两类不归这层管。一类是代理服务器本身的质量和合规，代理稳不稳定、快不快、用的是什么线路，是用户选服务商的事，我们只消费一个地址端口。另一类是国内模型，压根不需要代理，走直连就行，为了统一而非给国内模型套代理，反而白白多一跳。

八、小结

出口分离这条约定写进了 AI智能媒体助理 的使用手册，境外登录引发的验证掉了一大半。上线至今，因代理污染导致的账号验证从每月十几起降到了两三起，剩下的两三起查下来都是用户手动挂了系统代理这类软件外的因素。用户侧关于登录的投诉少了一大批，退订的那个用户后来又续了。

回头看，代理这件事的技术含量不高，难的是想清楚哪些流量该走哪条路。模型调用要出境，账号登录要干净，两类流量在一根管里混了三个月才出问题，分开只用了三天。工程上很多事都是这样，分开不难，难的是意识到该分。