记录一次 trader 深夜自杀：半死的本地代理和缺失的 48h cron（2026-08-04）

坏的不是 HL，是那个半死的本地代理。

那天晚上 22:17 我开始做一次全量诊断，结果撞上 trader 进程失踪、收益却转正的奇怪局面，一路追到系统环境变量里一条半死的代理。

一、22:17 全量重拉：进程是 0，收益却转正了

22:17 我做了次全新实拉诊断，不采信任何旧结论，进程、DB、日志全重拉。这次特意用严格脚本名匹配，避免上一轮踩到的“扫描自匹配假 ACE”坑。

先并行拉取，结果两个大发现：

trader 进程 DOWN，count=0；
48h 归因 cron 5d76a21697c2 查无此任务。

但收益数据其实是转正的：realized 从 −$1.05 变成 +$20.53，current_usdc 从 7947 涨到 $8,809，equity 约 $10,019；market_flow +$20.89、sentiment +$3.38、factor_ic +$0.29 全正。也就是说 24h 积累期里 trader 确实在赚钱，之前“盈利全靠浮盈”的担心消解了。

可 trader 日志结尾是：🔴 连续 11 次重连失败, 放弃 (让 run.bat 重启). 退出. 边上还有 502 total=42，比上次诊断时 21 翻了一倍。日志解析显示“since 08-03 19:35: 0 行”是解析假象——日志行首是 [sm_trader] 不是 ISO 时间戳，不是真无事件。

二、从连续 11 次重连失败追到代理 502

我先确认 trader 是否真死、watchdog 为何没拉起、cron 在不在、端点是否仍 502。

三轮轮询跨 6 秒，trader 全 count=0，不是周期间隙；watchdog 自身存活，PID 76992，但它没把 trader 拉起来。48h 归因 cron 也确实不存在——automation 列表里只有一个知乎每日任务，根本没有 5d76a21697c2，那句“排成 cron”没落地。

watchdog.log 里时间线在跳变：14:04–14:20 UTC（本地 22:04–22:20）反复“🚀 拉起 trader”然后“拉起后仍未检测到”，说明看门狗的拉起命令没真正把进程拉起来，trader 启动即崩，2 秒内消失，直到 14:25 UTC 才检测到“正常”。但此刻 22:28 快照，trader 还是 0，处于崩溃循环：看门狗拉起→跑一会→502 自杀→再拉。

而且 sm_trader.log 自 17:46 之后没再被写入，说明看门狗的“拉起”命令根本没有真正跑起 python——启动即崩或子进程 spawn 失败。

关键证据链出来了：

trader 上次正常运行到 17:46，日志末尾 STATUS tick=2520 ... sim_equity=$8813 realized_pnl=$20.53 total_pnl=+$20.53 trades=46，确实在赚钱，然后 HL 端点开始狂吐 502，重连 #5→#11 全失败 → 🔴 连续 11 次重连失败, 放弃 (让 run.bat 重启). 退出.
之后 sm_trader.log 再没更新，看门狗 22:04 之后的拉起命令根本没真正跑起 python。
看门狗“拉起后仍未检测到”就是启动 2 秒内进程消失，启动崩溃，不是慢速 502 死。

三、根因实锤：废的 PROXIES 和真正生效的 HTTPS_PROXY

我直接探 HL testnet，结果 0.5s 正常返回 JSON，端点本身没死。但 trader 代码里有个 PROXIES = {"http/https": "http://127.0.0.1:7890"}，那个 502 nginx/1.26.2 其实是本地 7890 代理吐的，不是 HL。代理挂了 → trader 所有请求走代理拿 502 → 连败 11 次自杀。

进一步确认，代理 7890 是活的（返回 400 而非连接拒绝），但它对 HL 请求转发失败，吐 502，就是半死状态；HL 直连 0.5s 正常。所以绕开代理直连就能恢复交易。

然后我去看 trader 怎么消费 PROXIES，结果发现这常量在 trader 文件里只定义、没被引用。真正让 SDK 走代理的是环境变量 HTTPS_PROXY——当前环境里 HTTPS_PROXY=http://127.0.0.1:7890/ 是系统级环境变量，run.bat 没设，是 Windows 环境继承的。任何用 requests/httpx 的 Python 进程（含 trader 的 HL SDK）都会自动读这个半死代理 → 502 → 连败自杀。

trader 文件里的 PROXIES 常量是废代码，真正生效的是系统 HTTPS_PROXY 环境变量。 这就是最大的陷阱。

四、修复与重建：改源码、拉进程、补 cron

根因完全锁定。我做了三件事：

改源码：在 smart_money_trader.py 启动处强制清除代理环境变量，让 SDK 永远直连 HL，不管谁启动都不会再走坏代理；
立刻用“清空代理”方式拉起 trader；
重建缺失的 48h 归因 cron。

改完源码拉起后，日志铁证：

连接建立: https://api.hyperliquid-testnet.xyz——直连，无代理；
HL meta loaded: 210 assets——连接成功；
聪明钱信号交易器启动，而且已经在执行平仓/开仓，[CLOSED] BNB factor_ic PnL=$-0.80；
502 count: 0，坏代理绕过成功；
PID 58152 启动 22:39:28，晚于修复 mtime，加载的是修复后代码。

临时启动器里含密钥，我删掉了，不写在这里。48h 归因 cron 重建为 automation-1785854515430，触发 2026-08-05T19:35:00，状态 ACTIVE，prompt 自包含（探表结构→逐笔重算→归因表+去留建议，只读不改代码，样本<10 明确说延长）。

五、核验与遗留

最后复拉 DB 和进程：trader 58152 单实例存活，watchdog 76992 正常，重启后 502 count 还是 0，trader 已执行平仓（BNB 平仓，n_trades 46→47）。DB 里 current=$8,888.58、realized=+$19.74、W/L=10/7、OPEN=factor_ic×1+market_flow×3，对账差 $0.89 一致。

系统“账/风控”都健康，但这轮抓到 trader 宕机事故，并现场修复。

遗留/下一步：48h 归因 cron 的第一次触发是 08-05 19:35，到时要盯一下归因表现；本地代理 7890 半死根因还没查清（可能是配置或上游问题），目前先靠源码里强制清代理兜底，环境变量里的 HTTPS_PROXY 也没去动它，后面得想清楚是修代理还是彻底移除这个系统变量。