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_clientWebSocket→ Trae 云网关 → DeepSeek API聊天记录存储在ai-agent/database.dbSQLite排查过程确认网络层状态查看服务器端 Trae 日志关注 TTNet 的country_code参数grep country_code ~/.trae-server/manager-logs/*/Modular/trae-helper_*_stdout.log输出country_codetw, country_code_srcuid这里出现第一个线索服务器在境内但 Trae 网络层将客户端 IP 判定为tw。这会导致 AI 请求路由到错误的 CDN 节点。其他正常服务器的日志显示country_codehk。检查Trae Server实例数量ps aux | grep trae-server | grep -v grep发现服务器上残留了 5 个不同版本的 Trae Server 进程版本状态stable-318b0f6...(最新)2 实例活跃stable-8829057c...僵尸进程残留8 个 agent-tool-hoststable-d2e2138f...僵尸进程残留stable-97bd3e97...僵尸进程残留trae-cn-server1 实例活跃分析4054错误的时间线从ai-agent日志中提取关键指标svr_11_gateway_server_processing_time: 4927ms # 网关处理耗时 svr_06_platform_first_token_timing: 4000ms # 等 first token svr__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 之间的代理层就已经挂了。对比测试变量结果同一账号 其他服务器 DeepSeek正常 (3413ms first token)同一账号 问题服务器 DeepSeek4054问题服务器 country_codehk (修正后) DeepSeek4054关键发现即使country_code已经修正为hk错误依旧。说明问题不在路由参数而在于连接状态已经脏了。定位根因Trae 的custom_model_proxy_client在进程启动时建立了一条到 Trae 云 CDN 节点的 WebSocket 长连接。这条连接建立时的参数CDN 节点选择、路由表在进程运行期间不会自动刷新。问题链路服务器曾有多版本 Trae 混杂运行网络层参数被污染某次连接时country_code被判定为twWebSocket 被分配到一个不对的 CDN 节点该节点对 DeepSeek 的代理不稳定之后虽然country_code修正了但长连接没断一直复用错误的节点修复方案方案Arm .trae-server不推荐删除整个 Trae Server 数据目录完全重建。代价聊天记录、CKG 索引、用户设置、同事的上下文全部丢失。方案B精准重启 ai-agent推荐只重启ai-agent进程trae-server的 manager 进程会检测到子进程退出并自动拉起来新的。聊天记录完整性不受影响。#!/bin/bash # Trae AI Agent 精准重启脚本 # 只重启 ai-agent不丢聊天记录 set -e TRAE_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 ]; then BACKUP$DB_PATH.backup.$(date %Y%m%d_%H%M%S) cp $DB_PATH $BACKUP echo ✓ 数据库已备份:$BACKUP fi # 2. 找到当前活跃版本的 ai-agent 和 agent-tool-host AGENT_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. Killmanager 会自动重启 echo → 停止 ai-agent... for pid in $AGENT_PIDS; do kill $pid 2/dev/null echo killed ai-agent pid$pid done echo → 停止 agent-tool-host... for pid in $TOOL_PIDS; do kill $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; do NEW_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 ]; then echo ✓ ai-agent 已重启 (pid$NEW_AGENT) echo ✓ agent-tool-host 已重启 (pid$NEW_TOOL) break fi sleep 1 done if [ -f $DB_PATH ]; then echo ✓ 聊天数据库完好 ($(du -h $DB_PATH | cut -f1)) fi echo 完成 总结调试这个问题的过程中一个有趣的体会是在分布式系统里缓存和连接池经常是问题的来源。一个在启动时建立的 WebSocket 连接在运行了数小时甚至数天后它的路由信息可能已经完全过时了。Trae 的网络层已经自动修正了country_code但应用层的custom_model_proxy_client还在用那条旧连接。写到最后