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

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

契机

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

问题

error_code: 4054error_message: "Custom model internal error occurred. Please check the proxy response for details."

以前的解决方案都是通过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 参数：

grep 'country_code' ~/.trae-server/manager-logs/*/Modular/trae-helper_*_stdout.log

输出：

country_code=tw, country_code_src=uid

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

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

检查Trae Server实例数量

ps aux | grep 'trae-server' | grep -v grep

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

分析4054错误的时间线

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

svr_11_gateway_server_processing_time: 4927ms# 网关处理耗时svr_06_platform_first_token_timing: 4000ms# 等 first tokensvr__06_platform_provider_first_token_timing: 0 # DeepSeek 零 token 返回svr__06_platform_provider_network_latency: 0 # 零网络延迟记录

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

对比测试

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

定位根因

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

问题链路：

1. 服务器曾有多版本 Trae 混杂运行，网络层参数被污染
2. 某次连接时 country_code 被判定为 tw
3. WebSocket 被分配到一个不对的 CDN 节点
4. 该节点对 DeepSeek 的袋里不稳定
5. 之后虽然 country_code 修正了，但长连接没断，一直复用错误的节点

修复方案

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

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

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

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

#!/bin/bash# Trae AI Agent 精准重启脚本# 只重启 ai-agent，不丢聊天记录set -eTRAE_DIR="$HOME/.trae-server"DB_PATH="$TRAE_DIR/ai-agent/database.db"echo "=== Trae AI Agent 精准重启 ==="echo "时间:$(date '+%Y-%m-%d %H:%M:%S')"# 1. 备份聊天数据库if [ -f "$DB_PATH" ]; thenBACKUP="$DB_PATH.backup.$(date +%Y%m%d_%H%M%S)"cp "$DB_PATH" "$BACKUP"echo "✓ 数据库已备份:$BACKUP"fi# 2. 找到当前活跃版本的 ai-agent 和 agent-tool-hostAGENT_PIDS=$(ps aux | grep 'trae-server.*modules/ai-agent/ai-agent$' | grep -v grep | awk '{print$2}')TOOL_PIDS=$(ps aux | grep 'trae-server.*modules/ai-agent/bin/agent-tool-host$' | grep -v grep | awk '{print$2}')# 3. Kill（manager 会自动重启）echo "→ 停止 ai-agent..."for pid in $AGENT_PIDS; dokill "$pid" 2>/dev/null && echo "killed ai-agent pid=$pid"doneecho "→ 停止 agent-tool-host..."for pid in $TOOL_PIDS; dokill "$pid" 2>/dev/null && echo "killed agent-tool-host pid=$pid"done# 4. 等待 manager 自动重启echo "→ 等待 manager 自动重启..."sleep 2# 5. 验证for i in 1 2 3 4 5; doNEW_AGENT=$(ps aux | grep 'trae-server.*modules/ai-agent/ai-agent$' | grep -v grep | awk '{print$2}')NEW_TOOL=$(ps aux | grep 'trae-server.*modules/ai-agent/bin/agent-tool-host$' | grep -v grep | awk '{print$2}')if [ -n "$NEW_AGENT" ] && [ -n "$NEW_TOOL" ]; thenecho "✓ ai-agent 已重启 (pid=$NEW_AGENT)"echo "✓ agent-tool-host 已重启 (pid=$NEW_TOOL)"breakfisleep 1doneif [ -f "$DB_PATH" ]; thenecho "✓ 聊天数据库完好 ($(du -h "$DB_PATH" | cut -f1))"fiecho "=== 完成 ==="

总结

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

写到最后