mike
b660debd06
新增 8 reference: - dividend-stability-score: A 股 5 维评分 (派息年数/CAGR/波动/最近/连续) → 0-100 分 + 5 星 - dividend-yield-rate-sort: 按股息率% 倒序 (用户偏好 2026-07-13) - longport-http-module: longport_http.py 公共模块 (替代 SDK WSS) - leverage-pass-through-bug: process_signal.py 丢失 leverage 字段 (5x 实际 10x) - follow-trading-iron-laws: 跟单铁律 (用户原话 5+ 次 2026-07-21) - forced-skill-entry-okx-trade: okx_trade.sh 强制入口 (替代 ccxt 裸调) - mihomo-clash-node-supplier-dns: Clash 节点供应商 DNS 失败处理 - mihomo-ssl-reconnect-pattern: mihomo 反复 SSL/Timeout 模式 - v4.5.44-mu-add-to-75pct-cap: MU 加仓 75% 单币种 cap 标准流程 改 2 SKILL.md: - dividend-investing: 加 5 维评分 + 长桥 http 模块 - longbridge-cli: 标注 '不要写 openapi.QuoteContext' + 迁移说明
3.5 KiB
3.5 KiB
mihomo 反复 SSL/Timeout 模式 (2026-07-21 实测)
现象
ccxt 调 OKX API 时频繁遇到:
urllib3.exceptions.SSLError: [SSL: UNEXPECTED_EOF_WHILE_READING]ccxt.base.errors.NetworkError: okx GET https://www.okx.com/api/v5/asset/currenciesRequestTimeout: HTTPSConnectionPool(host='www.okx.com', port=443): Read timed out
根因 (按概率)
1. mihomo 选了"挂掉的"出口节点 (最常见)
诊断:
# 看 mihomo 日志找超时节点
tail -50 ~/.hermes/cron/output/.../mihomo.log 2>/dev/null
# 或实时:
tail -f /tmp/mihomo.log | grep "dial\|timeout"
症状:
[TCP] dial BiXin Network (match Match/) ... ns1.accor.zone:23100 connect error: connect failed: dial tcp 112.119.223.235:23100: i/o timeout
修复:
- 节点真挂了 → 等节点恢复,或换 BiXin Network selector 顺序
- 改 selector 从
type: select为type: fallback(自动跳过死的):- { name: BiXin Network, type: fallback, url: 'http://cp.cloudflare.com/generate_204', interval: 300, proxies: [活的节点, 死的节点] }
2. 同一节点 TCP 连接被 mihomo 复用,服务器端 RST
症状:
Connection reset by peer(Errno 104)- 同一进程跑 5-10 次 OKX API 后开始 EOF
修复:
- 短连: process_signal 每次新 process
- 长连: 不可行(进程池问题)
3. mihomo 版本或 config 异常
症状:
- 重启 mihomo 后短暂能用,再 5-10 分钟又坏
- 节点 timeout 时间越来越长
修复:
- 升级 mihomo (当前 v1.19.8, 2025-05-13)
- 换 sing-box (国内 VPS 更稳)
实战: 排查 + 临时恢复
Step 1: 看 mihomo 是否活着
pgrep mihomo
# 期望: 输出 1-2 个 PID
Step 2: 看节点 timeout 日志
tail -30 /tmp/mihomo.log | grep -E "dial|error|timeout"
Step 3: 临时恢复
pkill mihomo
sleep 2
nohup bash ~/clash/start.sh > /tmp/mihomo.log 2>&1 &
sleep 5
pgrep mihomo
Step 4: 验证 OKX 通了
curl -x http://127.0.0.1:7890 --max-time 8 -s https://www.okx.com/api/v5/public/time
# 期望: {"code":"0","data":...}
永久修复建议
-
process_signal.py 加 mihomo 健康检查 + 自动重启
- 每次 advisor.execute 前 ping OKX
- 失败 2 次 → 自动 kill mihomo + restart
- 重试 advisor.execute 1 次
-
proxychains 升级到 4.17+
- 当前 4.14 已知有 TLS 重协商问题
- 4.17+ 修复 + SOCKS5 keepalive 改进
-
BiXin Network 改 fallback + 加健康检查 cron
- 每 5 分钟 cron ping 一次所有节点
- 死节点自动踢出 selector
-
关键路径双 proxy
- mihomo 7890 (HTTP)
- clash 7891 (SOCKS5)
- 任一不通立刻切另一条
已知 FAIL 模式 (写进 cron)
| 错误 | 触发 | 修复 |
|---|---|---|
| SSL EOF | 节点死/拥塞 | 切 fallback |
| Connection reset | 节点 RST 复用连接 | 换节点 |
| Request timeout | 节点慢/丢包 | 换节点 |
| 5xx OKX 错误 | OKX 服务问题 | 立即重试 1 次 |
| 401 auth | API key 过期 | 立即停(需人工) |
| 429 rate limit | 频率高 | 退避 30s 重试 |
agent 实战原则
当遇到 SSL/timeout 错误:
- 立即尝试 1 次重试(同 selector)
- 重试失败 →
pkill mihomo && nohup start.sh30 秒内恢复 - 仍失败 → 提示用户"网络问题,需手动处理",不假装成功
- 绝不把 advisor 计算值当成交回报 (铁律 15)
对用户:
- "网络 SSL 错误,正在重启 mihomo..." 简短告知
- 重启成功 → 立即重试原任务
- 重启 2 次失败 → 停止并报告,不无限循环