Clash Party Changed macOS DNS to 223.5.5.5? How to Restore It

Clash Party issue #2176 is one macOS user's report on v2.0.3: 223.5.5.5 appeared in the network service despite selecting system-default DNS in the app, and reappeared on the next launch after manual removal. Maintainers have not confirmed it as a general bug or identified a fixed version for this issue.

The v2.0.3 source shows that setPublicDNS() first reads the current network service's DNS and then tries to write 223.5.5.5, but only on macOS when a connection is detected and originDNS is empty.

This write path, which does not set a timeout, tries the local Helper first; only if that fails does it fall back to networksetup with administrator authorization. Recovery calls that set a timeout do not use that fallback. This does not mean the Helper unconditionally rewrites DNS at every launch.

In the same file, recoverDNS() attempts to restore the original value when originDNS is available. The UI's “Use system-default DNS” setting and this temporary system-level DNS path are distinct; changing a core DNS option alone does not prove that the macOS network service has been restored.

This guide applies to a macOS network service's DNS being rewritten while using Clash Party, particularly the scenario reported for v2.0.3. Troubleshoot Windows, router DNS, browser DoH, and ordinary proxy-node failures separately; seeing 223.5.5.5 does not by itself prove that Clash Party wrote it.

In macOS System Settings > Network, select the Wi-Fi or Ethernet service actually in use, then open Details > DNS. Apple documents this as the place to view that service's DNS servers and search domains; do not rely solely on Clash Party's core DNS screen.

First, capture or record the DNS list, network service name, any existing work or home custom DNS, and the Clash Party version, TUN state, and Helper state. If you intentionally configured 223.5.5.5 or the device is managed by an organization, do not treat the address as an error and remove it outright.

Compare the same network service's server list before and after opening Clash Party, then check it again after quitting. Proceed with this guide only if that address was newly added to the active service. Wi-Fi and Ethernet can have different DNS settings; after switching networks, confirm the active service again.

First, turn off TUN and other Helper-dependent network takeover features in Clash Party, then quit the app completely. Disabling TUN only narrows the variables; it does not guarantee that the source code's system DNS path cannot run again. Check macOS Network settings after quitting.

If 223.5.5.5 is the only unintended addition to the active network service and you have saved the original settings, select and remove just that entry through Apple's documented DNS settings. Keep existing work DNS, search domains, and other services' settings intact. Then disconnect and reconnect the current network and check whether that service's DNS matches the expected values.

If DNS was configured manually, restore the original servers from your notes. If the network supplied servers automatically, remove only the unintended manual entry. Apple's networksetup documentation also supports clearing manual DNS for a named service, but mistakes in the service name or permissions raise the risk; most users should use the graphical settings instead.

If the system says a configuration profile or organization manages the setting, stop making manual changes and contact the administrator. Deleting Clash Party's data directory, Helper files, or system plist files for a DNS anomaly can erase configuration or make the failure worse; it is not part of this rollback.

First, confirm that the network service's DNS in System Settings matches the original values you recorded and that a real HTTPS request works. Restart the Mac or reconnect to the same network and check again. Seeing “system-default DNS” in Clash Party's core settings alone does not establish that the system setting has been restored.

If you need to keep using Clash Party, leave TUN off, launch the app, and watch whether the same service's DNS changes again. If the change recurs only after launch or Helper activity, stop using that mode and record the exact sequence. Do not repeatedly write DNS back and obscure the recurrence.

If DNS remains unchanged but websites still do not open, investigate the system proxy, active Profile, proxy node, and browser DoH instead. A network service's DNS and DNS routing inside a proxy client operate at different layers; one test site's reported address cannot establish whether recovery succeeded.

If DNS keeps changing after Clash Party has fully quit, do not continue attributing it directly to #2176. Check for other running VPNs, DNS filters, device-management profiles, or older clients, and note when the same network service changes. Do not uninstall multiple tools at once or you will lose the comparison.

Clash Party's official macOS troubleshooting guide identifies the Helper service as party.mihomo.helper and documents its log location. Only after confirming that it belongs to the current installation should an administrator stop it as documented and observe whether the DNS changes stop. Do not directly delete plist files, executables, or the entire data directory.

If reporting upstream, include the macOS version, full Clash Party version, active network service, DNS lists before and after launch, TUN state, and the first relevant log entry. Redact the subscription URL, node passwords, device identifiers, and personal network details before sharing screenshots or logs publicly.

If connectivity worsens after removing 223.5.5.5, first restore the network service's DNS, search domains, and proxy state from your pre-change notes, then reconnect. For work or school settings, restore the values provided by the administrator. A public DNS address is not a universal fix for every network.

Keep Clash Party's TUN off and avoid any mode suspected of rewriting DNS. If you need a temporary proxy, first confirm that system DNS and ordinary connectivity are restored, then consider a verified setup that does not depend on that Helper. Recheck system DNS after enabling each feature.

Do not roll back to an unverified installer just because an older version appeared to work, and do not copy the data-directory deletion steps from the official macOS installation troubleshooting guide into this case. Maintainers have not concluded a fix for #2176; reassess only against a later project issue, Release, or commit.