PROXY-FINDINGS — ghcr.io 慢速排查结果（代理侧）¶
排查对象：
192.168.31.2（OpenWrt 24.10.0 x86_64，旁路网关 + DNS） 执行时间：2026-10-01 ｜ 对应交接文档：ghcr-slow-20261001/PROXY-CHECK-AND-HARBOR.md凭据（订阅链接、密码、UUID、节点服务器域名）一律不记录。
1. 代理软件与版本¶
| 项 | 值 |
|---|---|
| 代理插件 | OpenClash（Luci 插件） |
| 内核 | Mihomo Meta v1.19.31 linux amd64（go1.26.8，with_gvisor） |
| 内核 / 配置路径 | /etc/openclash/clash；/etc/openclash/fsc.yaml（38 KB，2026-09-30 04:00 生成） |
| 工作模式 | mode: rule；OpenClash operation_mode=redir-host、DNS en_mode=fake-ip、core_type=Meta |
| 监听端口 | 7890(http) / 7891(socks) / 7892(redir) / 7893(mixed) / 7895(tproxy) / 9090(API)，进程均为 clash |
| 本机代理端口 | 7890 返回 407（Mihomo authentication 已启用，非故障）；7891/7893 直连返回 000 |
| 其它隧道 | tun0 = OpenVPN(hk)（10.8.0.9/24）；frpc（/etc/frp/frpc.toml）在运行 |
2. ghcr.io 命中规则与出口节点¶
- DNS：
ghcr.io→198.18.0.107（fake-ip，段198.18.0.1/16） - 规则链（
fsc.yaml第 769–1288 行）： - 无任何
ghcr专条； ghcr.io域名不含关键字github，不命中第 1068 行DOMAIN-KEYWORD,github,便宜机场；- 域名经 nft
redirect to :7892进入 clash 后自上而下匹配，落入末条MATCH,便宜机场。 - 出口链：
便宜机场（type=select，当前选中自动选择） →自动选择（type=url-test，url=http://www.gstatic.com/generate_204，interval=300，仅按延迟选路） → 本次观察到的出口节点：美国-HY2-27（排查期间曾为 美国-HY2-35，佐证会自动切换）。 - 层数据来源：
ghcr.io的 blob 请求 302 重定向至pkg-containers.githubusercontent.com（→198.18.0.113，与 manifest 同属便宜机场、同一出口节点）。
3. 实测速率对比¶
测速方法（4 台 k8s 节点，均经默认网关 .2 走 clash，与文档同路径）：
- 通用带宽：curl https://speed.cloudflare.com/__down?bytes=10000000（--max-time 15）
- ghcr 拉取：ctr -n probe images pull --platform linux/amd64 ghcr.io/jkroepke/kube-webhook-certgen:1.8.8（9.0 MiB，单次计时）
- ghcr 单层：curl 直取镜像层 blob（9.45 MB）
| 节点 | ctr pull（9.0 MiB） | 拉取速率 | 通用带宽 |
|---|---|---|---|
| k8s-master-01 (.10) | 7.6 s | 1.2 MiB/s | 5.3 MB/s |
| k8s-node-01 (.13) | 6.9 s | 1.3 MiB/s | 12.5 MB/s |
| k8s-node-02 (.14) | 5.1 s | 1.8 MiB/s | 10.9 MB/s |
| k8s-node-03 (.15) | 5.1 s | 1.8 MiB/s | 6.2 MB/s |
其它单点：
- ghcr 单层（9.45 MB）curl 直取：3.4 MB/s（2.66 s，来源 198.18.0.113）
- ghcr manifest：0.68 s / 3066 B / HTTP 200
- github CDN（codeload.github.com）：5.2 MB/s（20 s 下 104 MB）
- cloudflare：9.5 MB/s
对比原记录：文档记 1.0 MiB / 89.8 s ≈ 11.5 KiB/s。本次 未复现，实测快约两个数量级。
4. 是否存在限速或链路瓶颈¶
- 无 tc 限速：
tc qdisc show为空（无整形队列）。 - 无 SQM/QoS：
uci show sqm为空。 - 订阅节点侧限速：无法从节点配置读取；但 4 台节点同时段稳定 1.2–1.8 MiB/s，未见硬性限速生效。
- 链路拓扑：
.2默认路由192.168.31.1；出向走 OpenClash 订阅节点；frpc仅承担内网穿透入向（非正向代理），tun0为 OpenVPN(hk)。 - fake-ip：
198.18.0.1/16；内网域名+.rainchen.top与机场订阅域名已列入fake-ip-filter（排除在外），解析正常。
5. 结论¶
未复现，当前速率正常。 当前证据不落「可修复 / 物理上限」二选一的任一项： 本轮未做任何修复改动，且实测速率远未触及物理上限。
- 当前 ghcr 拉取 1.2–1.8 MiB/s，已高于文档设定的 ≥500 KiB/s 目标。
- 代理侧四项（规则命中、出口节点、限速、fake-ip）均未见异常。
- 历史 11.5 KiB/s 的根因无法证实（按排障纪律，「未复现」即本次合法结论，不臆造根因）。
观测到
自动选择(url-test) 在排查期间自动换过节点（美国-HY2-35 → 美国-HY2-27）； 「按延迟选路、不看带宽」是已存在的隐患，但不能据此断定历史慢速由其造成。 - 建议①：对 ghcr 拉取速率做周期性采样并设告警，再次出现时立即取证（避免又变成「历史不可复现」）。
- 建议②：若再次复现，先把
自动选择冻结到固定节点做单变量对比，再决定是否固化选路策略。
6. 已做的改动与回滚方式¶
.2代理配置：零改动（未修改fsc.yaml或 OpenClash 任何设置，无备份文件产生）。- 临时动作（均已在当次命令内回滚）：
- 4 台节点各执行 1 次
ctr -n probe images pull ...（独立命名空间probe），测速后立即ctr -n probe images rm ...； 共享 content store 中的层内容交由 containerd 自身 GC 回收，对 k8s.io 命名空间无影响。 .10上一次codeload.github.com测试下载（仅产生流量，无状态变更）。
附：取证留痕（主机 / 命令 / 结论）¶
| 主机 | 命令要点 | 结论 |
|---|---|---|
| .2 | ps w \| grep -iE "clash\|openclash"；clash -v |
OpenClash + Mihomo v1.19.31 |
| .2 | sed -n 769,1288p fsc.yaml；clash API /configs |
ghcr.io → MATCH,便宜机场 |
| .2 | clash API /proxies |
出口 = 自动选择(url-test) → 美国-HY2-27 |
| .2 | tc qdisc show；uci show sqm |
无限速/整形 |
| .10 | ctr -n probe images pull … + 计时 |
7.6 s / 9.0 MiB |
| .13/.14/.15 | 同上（并行） | 6.9 / 5.1 / 5.1 s |
| .10 | curl speed.cloudflare.com / codeload.github.com |
5.3 MB/s / 5.2 MB/s |
| .10 | curl https://ghcr.io/v2/…/blobs/<layer> |
3.4 MB/s |
来源：
/home/rain/Documents/k8s_ins/ghcr-slow-20261001/PROXY-FINDINGS.md｜ 最后更新：2026-10-01 02:22（由build/sync.py同步，请勿在站点侧修改）