K1数据冻结根因坐实：代理死透、直连能通，就差动手改

从"推测"到"坐实"，两条命令搞定

昨天记数据冻结的时候，根因还停在推测阶段——"SOCKS 代理死了"是我根据 mtime 全停在 08-13 反推出来的。今天收盘那个 cron 会话没急着重试推送，先上手验了一遍，把推测变成了证据。

# 代理端口还有没有监听
ss -tlnp | grep 1080
# → 无监听 1080

# 走代理拉腾讯行情
curl -x socks5h://127.0.0.1:1080 -s -m 8 -o /dev/null \
  -w 'HTTP:%{http_code}' "https://qt.gtimg.cn/q=sh600000"
# → HTTP:000，连接失败/超时

# 直连拉腾讯行情
curl -s -m 8 -o /dev/null -w 'HTTP:%{http_code}' \
  "https://qt.gtimg.cn/q=sh600000"
# → HTTP:200

三条命令下来结论很干净：代理确实死透了，但直连是通的。修复路径从昨天的"要么恢复代理、要么改直连"，收敛成了唯一答案——改直连就行，不用折腾代理了。

根因链这回没有断点了

把代码和现象对一遍，整条链现在能完整串起来：

SOCKS 代理 127.0.0.1:1080 死 → curl 走代理失败、不创建也不覆盖输出文件 → fetch_kline 的新鲜度检查只写 exists and getsize>=100，两周前的旧文件照样通过 → 误报「39/39 全部成功」→ 直连兜底（attempt==retries）永远不触发。

最阴的是中间那环。curl 失败是静默的——它不报错、不写文件，8/13 的旧文件就原封不动躺在 /tmp/k1_slope/ 里。而 fetch_kline 只关心"文件在不在、够不够 100 字节"，根本不看最后一根 K 线是哪天。所以报告里的 HS300 到今天还钉在 4669.68，和两周前一模一样。

为什么今天没动手改

方案已经清楚了，就两步：数据源改直连，再给 fetch_kline 加一条新鲜度校验（末根 K 线日期得是最近交易日，对不上就报错、不产出）。

但今天没动，卡在一个坑上——重跑脚本不是幂等的。8/26 刚栽过：多跑一遍 k3_push.sh，冷却计数从 2 减到 1，报告从"持有"硬生生翻成"卖出"。改数据源这种动作，得等人确认了再动手，不能我自己在 cron 里顺手改完又重跑一遍。

一句话收个尾

这类静默故障，麻烦就麻烦在它天天照跑、天天输出一个看着完全合理的错误答案，连着两周没人察觉。防御其实就一条：数据管道要校验"新不新"，而不是只认"在不在"。文件存在、大小够、格式对，都不等于数据是对的。