On this page
If the phone shows VPN connected but cannot open pages by domain name, first check whether ordinary networking works. A system temporarily providing no resolver, incorrect subscription settings, and a disconnected node require different treatment. Record results on the same network and target before and after enabling VPN to distinguish this version fix from other causes.
Why do domains stop resolving on Android while the connection remains active?
On Android, record failures to resolve website and node domains after VPN connects. Compare direct access and requests in FlClash using the same domain, then check the logs. The phone network, system DNS handoff, configured upstream, or node connection can each cause failure; proceed only if the empty-list conditions match.
FlClash v0.8.99 fixes one resolution-failure path when an Android network temporarily reports no DNS servers. An empty [DNS] updateDns entry or udp://: in older logs is a useful clue, but compare it with direct access; this does not explain every Android connectivity failure.
This fix addresses Android temporarily reporting no DNS servers, preventing FlClash from resolving domains through that path. Do not apply it directly to general DNS issues on Windows, macOS or Linux, or to Android configuration errors, failed nodes or Private DNS problems.
Direct-connection comparison with VPN off and signs of an empty DNS list
If direct access works, restart the same Profile and proxy and see whether domain lookups fail only through FlClash. An empty [DNS] updateDns entry or a udp://: resolver target in older logs matches the official commit, but missing log lines do not rule this path out.
Android's LinkProperties.getDnsServers() returns the DNS servers reported for the current network link. A temporarily empty list is the input condition examined here; it does not mean the user cleared dns.nameserver in the profile.
The nameserver and nameserver-policy entries you fill in manually belong to the proxy configuration, while Android Private DNS is a system setting. Changing these options alone may not establish whether the system is reporting an empty DNS list to the client.
Keep a minimal reproducible comparison
Record the configuration and the state when the failure occurred
Record the full FlClash version, Android version, network type, current Profile and node, first failure time and whether it happened on connection, network switching or recovery. Retain logs and real domain-access results. Do not change nodes, DNS and caches together before recording the state.
Turn off the VPN and test direct access
On the same Wi-Fi or mobile network, open a real HTTPS website to check the phone network and system resolution.
Retest with the original configuration
Start FlClash with the same Profile, proxy, and target. Check the first DNS error in the logs and the actual connection result.
Check whether it matches the empty DNS failure conditions
Follow the v0.8.99 fix path only if direct access works, domains fail through FlClash, and the version and empty-DNS clues align.
Observed results and next steps
| What you observe | Next step |
|---|---|
| The same network still cannot resolve domains after the FlClash VPN is turned off | If direct connections still cannot resolve names, restore the phone network, router or carrier DNS. Upgrading FlClash is not the only answer. |
| Direct access works, but older FlClash DNS logs show an empty updateDns entry or udp://: | This matches the fix's clues. Back up the configuration, then check the official v0.8.99 release. |
| Only one proxy or domain fails while other requests work | Check the proxy address, DNS upstream, rules, and destination service. Do not infer that the entire system DNS list is empty. |
| Android Private DNS reports an unreachable server, or another VPN is active | Check system Private DNS and VPN state first. Record the settings, then change one variable at a time. |
- Why an empty DNS list can prevent normal fallback
- Before the fix, an empty list from the Android service reached the Go core as an empty string. strings.Split turned it into one empty address. Mihomo treated that as a udp://: nameserver, so the system resolver considered a server configured and skipped its default fallback. v0.8.99 passes a truly empty list instead.
Update to v0.8.99 with the official APK and keep the original configuration
Use FlClash's local backup feature before changing anything. Confirm the backup file exists and record the subscription source and selected Profile. Subscription tokens, proxy passwords, and personal addresses may be included; do not upload the raw backup to a public issue or online converter.
The project README lists arm64-v8a, armeabi-v7a, and x86_64 builds. Do not guess from another phone's model or download an APK from an unverified mirror.
Stop the FlClash VPN before updating and confirm that ordinary connectivity works. Keep the app data and pre-update backup. Do not clear the database, delete all Profiles, or replace subscription DNS with an unfamiliar public server for this fix.
The v0.8.99 code change keeps an empty system DNS list genuinely empty so the resolver can use its normal fallback. It does not force one DNS address on every device. If an upstream server is unreachable or a profile is invalid, an update does not replace that investigation.
One test that changes only the client version
Record the pre-upgrade configuration and results
Keep the local backup and failure log. Record the same network, Profile, proxy, and website so a profile change is not mistaken for a version fix.
Check the source and device ABI
Open the official chen08209/FlClash v0.8.99 Release. Select an Android APK that matches the device ABI, then install it through the device's normal app update flow.
Turn FlClash VPN back on
Confirm the Profile and settings remain, turn the FlClash VPN back on, and use the same proxy and website as before.
Compare DNS and real requests
Check DNS query logs, connection records, and a fully loaded HTTPS page. A VPN icon or proxy latency number is not enough.
Check DNS during stable connections and after network switching
Confirm the app shows v0.8.99 and that the Profile, proxy, and network type match the pre-update record. First open the same real HTTPS site on a stable network and check its resolution and outbound path in FlClash's DNS queries, requests, or logs.
Later, during everyday use, recheck the same target whenever your device switches between Wi-Fi and mobile data or reconnects after losing its connection. The official commit addresses the moment when the network reports an empty list of DNS servers. If a normal network always has DNS servers, a single success proves only that the current connection works, not that the empty-list failure described above is fixed.
If the invalid-server clue no longer appears and both domain resolution and a real HTTPS request recover, record a successful test on this device. If the domain resolves but the page still fails, inspect rules, the proxy, connection records, or the destination rather than attributing every timeout to empty system DNS.
Verification checklist
- The client is the official v0.8.99 Release, and the Android APK ABI matches the device
- The pre-update backup remains, and the original Profile, proxy, and overrides can be checked
- Direct access with the VPN off and access with it on were recorded on the same network and target
- FlClash resolves the domain, the real HTTPS page loads fully, and the connection record shows the expected outbound
- DNS and requests were rechecked after a normal network switch or reconnection, with no failure from this empty-address path in the logs
What if lookups still fail on v0.8.99, and how do you recover and report it?
Stop the VPN in FlClash first. Confirm that Android returns to ordinary connectivity and can resolve a real domain and complete an HTTPS request. If direct access also fails, avoid repeatedly reinstalling the client; restore the current Wi-Fi, mobile, or Private DNS connection instead.
If you changed a Profile, override, or other setting during diagnosis, restore only those changes and compare them with the pre-update backup. Do not erase all app data, overwrite the only backup, or force system DNS to an unfamiliar server. Reinstalling an older version can bring this bug back and is only a temporary option after preserving a backup.
If v0.8.99 still logs an empty [DNS] updateDns entry or udp://:, report the Android and FlClash versions, network type, VPN-off comparison, minimal reproduction with the same Profile, and first relevant log line in a project issue.
Record the results before and after any network switch as well. Redact subscription tokens, proxy passwords, personal domains, and device identifiers before posting; keep the original backup and full logs locally.
If only domains matched by nameserver-policy: system fail, do not merge that case into this empty-list failure. The older project issue #1393 reported a similar udp://: log on a v0.8.88 prerelease, but its triggering configuration and version differ. Present your current evidence separately.
References
- FlClashOfficial FlClash v0.8.99 DNS fix and Android release assets
- FlClashCommit e55f6d1: preserve system resolver fallback when Android reports an empty DNS list
- FlClashFlClash v0.8.99 changelog
- FlClashFlClash v0.8.99 README: Android packages, DNS logs, and local backups
- Android DevelopersAndroid LinkProperties API for the network's DNS server list
- FlClashOlder FlClash nameserver-policy: system issue #1393 (different trigger)