故障排障

今天最重要的判断：隧道这层既然没人守得住，就不该再让页面依赖它；索引页的空白不是布局问题，是模板只有一行函数。 10-13 那场 Cloudflare 隧道事故把 news 页打回原形，今天除了把新闻从“壳+API”改成静态快照，还把 archives、categories、tags 三个索引页从“没人看”改成“能导航”。整个过程里最值钱的不是改完，而是两个坑：curl 200 不代表图没挂，CSS Grid 的 1fr 会偷偷把移动端撑爆。 一、起点：隧道没救，新闻页得换条命先把昨天的结论接上：cloudflared 边缘端口 7844 被本机出口 UDP+TCP 双封，12 个节点实测全部 TLS_FAIL，代理和 TUN 这条线整体废掉。用户今天报 demoblog.4everland.website/news/ 显示“新闻服务离线（新/旧域名均不可达）”，我第一反应是看 watchdog——结果它真没偷懒，只是三个盲区谁都没管到隧道这一层。blog 守卫按进程名判活，故障时 cloudflared 明明活着，只是在无限重试 dial 7844，却被判健康；yunpan ...

手机上所有看起来像前端的问题，最后都可能是存储层漏了一个字段。 中午打开博客 /news/，手机端两个毛病一起冒出来：热榜点进去报「缺少文章参数」，滚动时头部还浮在半透明遮罩上方。当时直觉是两个独立的前端 bug，结果一个要改到 store.py 的 SQL，另一个得重新排一遍移动端 flex 布局，还发现本机浏览器根本起不来，连张截图都没法自证。 一、热榜点进去「缺少文章参数」——根因在 hot_now() 少查了一个字段先看症状：博客 demoblog.4everland.website/news/ 的热榜条目点开后，阅读页直接显示「缺少文章参数」。刚开始我以为是 article.js 的参数解析问题，但顺着链路追下去，问题在存储层。 具体链路是： lib/store.py:hot_now() 从 hot_snapshot 取数，SELECT 里**只有 cluster_id，没有 item_id**。 服务端 _deco() 按 item_id 生成 item_url，返回的 JSON 里 item_id 就是 null。 博客页 esc(undefined) 变成空字符串，d ...

今天最关键的判断：回测里报出的 p=0.049 根本不能算显著，多重检验一校正直接回到 0.1975。 上午还顺手发了那篇耐克市值蒸发的知乎商业稿，下午就一头扎进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。原以为只是修 rolling_signal_backtest.py 的两个 P0，结果后来越挖越发现，回测和线上压根不是一个玩法。 一、早上先做了一遍博客只读核查没什么大动作，但结论很明确：本地 D:/blog 是 Hexo 源码工程，本身不是 git 仓库；真正部署的是 git@github.com:wz-git-hub/wz-git-hub.github.io，仓库里只有构建产物，没有 source/。远程 master HEAD 是 47dd05ca7548d1a2c019818142715d98ab11915e，pushedAt 11:00:57，本地 .deploy_git 与远程逐字节一致，44 个 tracked 文件一个不多一个不少。唯一异常是 source/about/inde ...

既然 HL_DRY_RUN=1，蓝屏就不是故障，是等 Verifier 点名的预期行为。 今天把这台从 6 月到 10 月反复硬锁死的交易机收了个尾：硬件根因已经修掉，软件根因还在监控，剩下就是让 Driver Verifier 布防，等它自己指名。整个过程踩了不少 Windows 运维的坑，值得原样记下来。 一、主机与运行环境这台机器 PC-20260408JPNQ 是 7x24 交易栈宿主，跟 craw_app1_wz 同机。核心配置：Intel Core i5-14600KF（Raptor Lake Refresh，Family6 Model183），Maxsun MS-Terminator B760M D5 主板，单条 16GB Asgard DDR5 内存，1TB NVMe 系统盘加 8TB SATA 数据盘，RTX 2080 Ti，Windows 11 26H2 build 26300.9457。上面跑着 defi_dashboard（Streamlit+MySQL+多个 python/node）、YunpanHub、Hermes agent、ollam ...

A1 判 HALT，A2 判 NO_ACTION，同一天、同一套 factor_ic，结论完全相反——但并不是谁错了，而是它俩卡的门完全不一样。 2026-09-29 这天，从凌晨 00:40 到早上 05:56，我基本住在 factor_ic OOS tracker 的扫描输出里。两个 arm 轮流跑，中间还插了一次 Hyperliquid 的只读对账。最后没毕业、没阻断，但有几个数字和判断值得记下来，尤其是那个 stdout 的 maxDD 百分号 bug 和 A2 样本池六轮一动不动。 一、A2 那边：n=19 冻结六轮，NO_ACTION 一路到底A2 的扫描从凌晨 00:40 的第 75 轮开始，我在终端里守着看它输出表。Gate1 样本数 19，阈值是 ≥30（A2 更严），直接 ❌；Gate2 binomial p 0.6476（win 8/19，胜率 42.1%），远大于 0.05，❌；Gate3 年化 Sharpe −7.477，❌；Gate4 maxDD 写库是 4.2782，按真实值 ≤30% 是 ✅，但 stdout 打印 427.8%，后面 ...

真正让 trader 停摆的不是某个策略赚不到钱，而是链上有一批它自己根本不知道的仓位，正死死占着保证金。 今天这份复盘，本质上是把 09-11 那笔 -$98.57 的 orphan_reconcile 假损失给翻了个底朝天——最后发现我们之前一直在跟自己的影子打架。 一、早上先查盘面：11 天没开新仓今天 09:58 我启动诊断的时候，第一反应是“别又是策略逻辑写挂了”。psutil 里能看到的一串进程全是 ALIVE：smart_money_trader 10s 主循环在 tick=140，smart_money_signal 每 15s 左右写一次日志，watchdog 09:54:36 刚跑完一轮，streamlit_dashboard 端口 8501 返回 HTTP 200。看起来系统全活。 再看 sm_account 表，09:47:40 的快照写着 current_usdc=10045.98，realized_pnl=+51.19，W/L=58/57。单看这个账面，trader 就是“没在交易”，不是死了。 但 ...

最危险的不是进程死了，而是它还活着，却已经很久没说过一句话 这天前后处理了几件看起来不相干的事：换掉一个 VLM 模型、给一个本地转发进程补 timeout、修交易 worker 的心跳、核正一份自动判定、读一份策略审计。等它们在记录里排到一起才发现，说的其实是同一件事——每一个长期运行的环节，都得持续向系统证明自己还活着。一旦它不再说话，系统不会立刻崩，它只会安静地做出一个错误的判断。 下面按当天实际处理的顺序记。 从一条 130 秒的规律开始监控里最先扎眼的是这个数：交易 worker 每隔约 130 秒就重连一次，节律几乎不抖。 反复核过之后，这个 130 秒不是巧合——它刚好等于连接守卫的超时阈值 + 平均一次重连所需的耗时。也就是说，重连不是网络断了，是被守卫"误判"成断了：它等了太久没等到该有的时间戳刷新，就按超时处理，断线，重连，然后 130 秒后再来一遍。日志里这种由"陈旧"引发的心跳超时，一次会话里数到了 3885 次。 顺着 _last_success_ts 往下挖连接守卫的判定本身很简单：当 _last_success_t ...

心跳超时说的从来不是"连接断了"，而是"没人告诉它还活着" smart_money_trader 的日志里堆着几千次心跳超时。表面看是网络不稳，但一台机器如果真烂到每两分钟断一次，它早该被停掉了——交易进程却一直在跑，仓位也没乱。所以这次不猜，先把它拆开看。 这一天的活，从头到尾只有一件事：把"到底是谁在超时"查清楚。 修不修得好是第二步。 先看清风暴的形状先把原始日志预解析了一遍，而不是凭印象判断。 reconnect_preanalysis.json 记录的这场风暴，时间跨度是 2026-08-18T22:00:00 到 2026-09-05T13:57:21。进程侧的 _HEARTBEAT_TIMEOUT 是 120.0 秒，stall_profile.jsonl 里的分析确认了一件事：重连的节奏大约是 每 130 秒一次——正好对上"超时阈值 + 重连周期"。 预解析里还埋着一个更早的坑。第一次统计出来的心跳数是 4355，但这个数字是错的：它把 470 次 [SIGNAL] 守护进程的心跳超时， ...

“在量化系统里，一整天零翻转、零幽灵仓，就是最好的巡检结果。” 今天从 00:55 的 A2 扫描开始，到上午的 Hyperliquid 对账结束，我基本都在做重复但必要的检查：两套 tracker 并行跑，一条短腿 HALT，一条长腿攒样本，最后再确认链上账本没有幽灵仓位。 一、A2 长腿：样本连续冻结在 16凌晨 00:55–00:56，A2 OOS tracker 第 28 次执行，命令是 factor_ic_oos_tracker_a2.py once，走 anaconda python，带 dangerouslyDisableSandbox:true 访问主网 K 线。这一轮结果非常干净： Gate1 样本数：16，但 A2 阈值是 ≥30，所以直接 ❌； Gate2 binomial p：1.0000（win 8/16），完全不显著； Gate3 年化 Sharpe：-5.080，远低于 1.0； Gate4 maxDD：412.4%，严重超限； regime 上升率：75.0%（n=16），≥50% ✅ OK。 决策是 NO_ACTION——reg ...

trader 不是代码坏了，是重连逻辑把网络抖动当成了死罪，而 factor_ic 的 HALT 只是监控标记，真正没停过交易。 今天从发现 hl_smart_money.db 的 mtime 停在 08-27 19:16 开始，一路查到 watchdog 反复拉起失败、readonly 假象、502 重连自杀，最后改掉 hl_connection.py 的 sys.exit(1)，顺手把 factor_ic 的 HALT 登记落地。过程有点绕，记下来。 一、trader 停摆 38 小时：从 DB 时间戳发现不对劲早上第一眼看到 hl_smart_money.db 的 mtime 停在 08-27 19:16，距离当时约 1.5 天。trader 日志尾部显示“连续 11 次重连 502 失败 → 放弃退出”，但进程列表里却有几个 PID 存活。当时我还没分清哪个是真正的 trader，先做三件事：确认进程身份、核对日志时间线、看 DB 是否还在写。 核对结果：当前没有存活的 smart_money_trader.py 进程——只有 watchdog(78616) 和 signal( ...