mapleafgoSingCast 核心创作者

作者发言

GitHub·2026.10.01 19:28:33（UTC+8）

mapleafgo：SingCast 的 rule-set 代理机制本身正常，下载失败实为 DNS 解析问题

在 SingCast #71 中，mapleafgo 对用户反馈的 rule-set 代理失效做了端到端排查：`rule-set-proxy` 的值会逐层透传（GUI → Android/iOS 桥接 → 内核），并在启动时把 `raw.githubusercontent.com` 的 rule-set 链接改写为 `<proxy>/<原链接>`；用 `--rule-set-proxy` 指向一个可记录的镜像时，内核能连上镜像并成功拉取规则集，默认的 `https://gh-proxy.org` 下自动生成的各条 rule-set 链接均返回 HTTP 200。真正原因是 DNS 而非代理：Android 上内核通过不可靠的 `default_domain_resolver`（local/empty）解析 rule-set 主机名，回落到 Go 的 `::1:53` 导致连接被拒，属 #69，已在核心 v1.1.22（2026-08-02）修复；失败发生在 DNS 解析阶段，所以改代理地址无效。因此 #71 与 #69 同因，在 v1.2.0 及之后已解决。另外他们发现一个潜在缺陷：健康检查看门狗重启内核时没有重新应用 rule-set 代理，自愈重启后规则集下载会退回直连，正在核心中修复并补了回归测试。

作者原文@mapleafgo

Thanks for the detailed report — we traced this end to end. Summary: the rule-set proxy mechanism itself works; the failure you hit came from a different bug that is already fixed.

What we verified against the shipped core:

• The rule-set-proxy value is passed through every layer (GUI → Android/iOS bridge → core) and applied at startup by rewriting raw.githubusercontent.com rule-set URLs to <proxy>/<original-url>.
• Running the core with --rule-set-proxy pointed at a logging mirror shows the core connecting to that mirror and successfully fetching the rule set (router: updated rule-set …). With the default https://gh-proxy.org, every auto-generated rule-set URL (geosite-cn, geoip-cn, geosite-private, geolocation-!cn, …) returns HTTP 200.
• The real cause of your failure was DNS, not the proxy: on Android the core resolved the rule-set hostname through an unreliable default_domain_resolver (local/empty), which fell back to Go's ::1:53 → connection refused. That is issue #69, fixed in core v1.1.22 (2026-08-02). Because the failure happens during DNS resolution, changing the proxy URL has no effect — which matches exactly what you observed, and why this looked independent of VPN/TUN.

So #71 is the same root cause as #69, and is resolved on release v1.2.0 and later.

Separately, we found a latent bug in the core: the health-check watchdog restarted the core without re-applying the rule-set proxy, so after a self-heal restart the rule-set downloads would fall back to direct. It is being fixed in the core (regression test added).

If you still see failures on the latest release with a valid proxy URL, please attach the app log (Settings → Logs) — DNS and rule-set failures are recorded there.