Trae远程开发中DeepSeek自定义模型4054错误的排查与修复

type

Post

status

Published

date

Jul 1, 2026

slug

260701-trae

summary

目前trae还比较良心，可以自定义模型，已经成为为ssh远程debug的得力助手，可在通过SSH-Remote连接远程服务器，在trae中使用DeepSeek自定义模型（deepseek-v4-flash 或 deepseek-v4-pro）时，始终返回错误4054错误

契机

⚙

问题

以前的解决方案都是通过rm /root/.trae_server解决，可如此会丢失对话记录和其他同事的配置状态，不太优雅，故从其他方案入手

Trae 远程开发架构简要说明：

本地 Trae 客户端通过 SSH 连接到远程服务器

服务器上运行 trae-server，包含多个子进程：server-main、ai-agent、trae-helper（网络层）、ckg_server（代码知识图谱）等

AI 请求链路：ai-agent → custom_model_proxy_client（WebSocket）→ Trae 云网关 → DeepSeek API

聊天记录存储在 ai-agent/database.db（SQLite）

排查过程

确认网络层状态

查看服务器端 Trae 日志，关注 TTNet 的 country_code 参数：

输出：

这里出现第一个线索： 服务器在境内，但 Trae 网络层将客户端 IP 判定为 tw。这会导致 AI 请求路由到错误的 CDN 节点。

其他正常服务器的日志显示 country_code=hk。

检查Trae Server实例数量

发现服务器上残留了 5 个不同版本的 Trae Server 进程：

版本	状态
`stable-318b0f6...` (最新)	2 实例活跃
`stable-8829057c...`	僵尸进程残留（8 个 agent-tool-host）
`stable-d2e2138f...`	僵尸进程残留
`stable-97bd3e97...`	僵尸进程残留
`trae-cn-server`	1 实例活跃

分析4054错误的时间线

从 ai-agent 日志中提取关键指标：

请求成功到达了 Trae 云网关，但 DeepSeek 侧什么都没返回。platform_provider_first_token_timing: 0 说明在网关和 DeepSeek 之间的代理层就已经挂了。

对比测试

变量	结果
同一账号 + 其他服务器 + DeepSeek	正常 (3413ms first token)
同一账号 + 问题服务器 + DeepSeek	4054
问题服务器 + country_code=hk (修正后) + DeepSeek	4054

关键发现： 即使 country_code 已经修正为 hk，错误依旧。说明问题不在路由参数，而在于连接状态已经"脏了"。

定位根因

Trae 的 custom_model_proxy_client 在进程启动时建立了一条到 Trae 云 CDN 节点的 WebSocket 长连接。这条连接建立时的参数（CDN 节点选择、路由表）在进程运行期间不会自动刷新。

问题链路：

服务器曾有多版本 Trae 混杂运行，网络层参数被污染

某次连接时 country_code 被判定为 tw

WebSocket 被分配到一个不对的 CDN 节点

该节点对 DeepSeek 的代理不稳定

之后虽然 country_code 修正了，但长连接没断，一直复用错误的节点

修复方案

方案A：rm .trae-server（不推荐）

删除整个 Trae Server 数据目录，完全重建。代价： 聊天记录、CKG 索引、用户设置、同事的上下文全部丢失。

方案B：精准重启 ai-agent（推荐）

只重启 ai-agent 进程，trae-server 的 manager 进程会检测到子进程退出并自动拉起来新的。聊天记录完整性不受影响。

总结

调试这个问题的过程中，一个有趣的体会是：在分布式系统里，"缓存"和"连接池"经常是问题的来源。一个在启动时建立的 WebSocket 连接，在运行了数小时甚至数天后，它的路由信息可能已经完全过时了。Trae 的网络层已经自动修正了 country_code，但应用层的 custom_model_proxy_client 还在用那条旧连接。

写到最后

是在往前走就好 bothsavage.github.io

vLLM推理服务假死排查-多模态缓存幽灵Key导致死循环

OpenHarness源码研究-6-架构全景与设计模式总结