Summary
In rule mode, NetProxy can become unusable when the built-in Cloudflare DoH resolver fails. The service is running, subscriptions and nodes are loaded, and app whitelist matching works, but proxied domains fail during DNS resolution because the cloudflare DNS server is a single point of failure.
Environment
- NetProxy-Magisk version: v7.0.2
- Core: sing-box version 1.14.0-alpha.26-reF1nd
- Root environment: KernelSU 3.2.4
- Module mode: rule
- TProxy: enabled
- App proxy: whitelist mode
Symptoms
- Subscription import succeeds.
- Nodes are listed and latency tests succeed.
- Service status shows sing-box running.
- Whitelisted app traffic reaches
tproxy_in and process/package lookup succeeds.
- However, proxied websites such as
www.google.com / ipinfo.io fail to load.
Relevant log examples:
inbound/tproxy[tproxy_in]: inbound connection to 34.117.59.81:443
router: found package name: mark.via
outbound/vless[CF...]: outbound connection to 1.1.1.1:443
dns: lookup failed for ipinfo.io: remote error: tls: handshake failure
router: lookup ipinfo.io: remote error: tls: handshake failure
Similar failures happen for other proxied domains:
dns: lookup failed for www.google.com: remote error: tls: handshake failure
router: lookup www.google.com: remote error: tls: handshake failure
Suspected cause
The default route config contains a mandatory resolve step using the cloudflare DNS server:
{
"action": "resolve",
"match_only": true,
"strategy": "ipv4_only",
"server": "cloudflare"
}And the DNS server is configured as DoH via Proxy:
{
"tag": "cloudflare",
"type": "https",
"server": "1.1.1.1",
"detour": "Proxy"
}When the selected proxy node cannot complete TLS handshake to Cloudflare DoH, the route resolve step fails and the whole connection fails. This makes rule mode fragile even though the node itself may work for normal proxied HTTPS destinations.
Workaround tested
Backing up config/singbox/confdir/06_route.json and removing only the mandatory resolve rule above restores connectivity. After restarting the service, www.google.com returns 200 OK in rule mode through the mixed proxy.
This workaround reduces CN-IP fallback precision for domains not covered by domain rules, but restores usability.
Expected behavior
Please consider making this DNS resolve step fault-tolerant, for example:
- add DNS fallback when Cloudflare DoH fails;
- skip
cn-ip match-only resolve if the resolver is unavailable;
- allow choosing resolver from the app UI;
- or avoid making a single DoH endpoint a hard dependency for all unmatched proxied domains.
This would make rule mode more robust on networks or nodes where 1.1.1.1:443 / Cloudflare DoH is blocked or unstable.
Summary
In rule mode, NetProxy can become unusable when the built-in Cloudflare DoH resolver fails. The service is running, subscriptions and nodes are loaded, and app whitelist matching works, but proxied domains fail during DNS resolution because the
cloudflareDNS server is a single point of failure.Environment
Symptoms
tproxy_inand process/package lookup succeeds.www.google.com/ipinfo.iofail to load.Relevant log examples:
Similar failures happen for other proxied domains:
Suspected cause
The default route config contains a mandatory resolve step using the
cloudflareDNS server:{ "action": "resolve", "match_only": true, "strategy": "ipv4_only", "server": "cloudflare" }And the DNS server is configured as DoH via Proxy:
{ "tag": "cloudflare", "type": "https", "server": "1.1.1.1", "detour": "Proxy" }When the selected proxy node cannot complete TLS handshake to Cloudflare DoH, the route resolve step fails and the whole connection fails. This makes rule mode fragile even though the node itself may work for normal proxied HTTPS destinations.
Workaround tested
Backing up
config/singbox/confdir/06_route.jsonand removing only the mandatoryresolverule above restores connectivity. After restarting the service,www.google.comreturns200 OKin rule mode through the mixed proxy.This workaround reduces CN-IP fallback precision for domains not covered by domain rules, but restores usability.
Expected behavior
Please consider making this DNS resolve step fault-tolerant, for example:
cn-ipmatch-only resolve if the resolver is unavailable;This would make rule mode more robust on networks or nodes where
1.1.1.1:443/ Cloudflare DoH is blocked or unstable.