Connectivity Troubleshooting · Clash Technical Blog

Clash Party TUN After Sleep: v2.0.4 Fix

Clash Party shows TUN as enabled after sleep but cannot connect, or saved changes have no effect? Back up first, check the v2.0.4 app fixes and core restart, then repeat the same request and keep a recovery path.

Read the articleBack to blog
  • Clash Party
  • v2.0.4
  • TUN
  • Sleep and wake
  • Core restart
On this page
Published
Estimated reading time
About 8 minutes

After waking your computer, Clash Party may pass node latency tests while TUN cannot carry traffic. Or you may change TUN settings but see the old behavior. Check the app version and what triggered the failure before reloading the core; neither symptom alone proves the node has failed.

Why can latency tests pass when traffic fails after wake?

The Clash Party v2.0.4 release confirms two fixes: incomplete configuration when rebuilding TUN after wake, and a missing core restart after saving TUN settings. This guide covers those paths. The update is not a universal fix for every TUN connectivity problem on every platform.

In project issue #2235, a macOS user running v2.0.3 reported unexpected runtime stack, dns-hijack and auto-route values after enabling TUN in the UI, even though work/config.yaml was complete. Use the report to recognize a symptom; it does not establish that every user loses the same fields.

Identify the triggering action first

SymptomFirst check
TUN worked before sleep but cannot forward traffic after wakeRecord the wake time and check whether the running app includes this fix.
Saving parameters on the virtual adapter page does not change connection behaviorCheck that saving and the core restart completed instead of repeatedly changing the subscription.
Direct access also fails with TUN disabled, or the node cannot establish a connectionInvestigate the network, node and actual error first; this TUN fix cannot explain every failure.

How does a full reload differ from toggling TUN?

In the fixed v2.0.4 source, if the core responds after wake and TUN should be enabled but its interface is gone, recovery disables TUN and then generates and loads the full configuration. The older branch only switched it on again, which could rebuild the interface with incomplete parameters.

When saving on the virtual adapter page, the new version preserves the current enable state, saves the parameters and calls restartCore. This is different from a configuration hot reload alone. Expect a brief connection interruption and avoid testing during an important transfer.

UI settings, the generated file on disk and the running core are different observation points. A complete tun section proves what is in the file; core logs and actual requests are still needed to confirm that loading and restarting finished.

Make a recoverable backup before updating

Check these items before and after the update

  1. Export a local backup

    Under App Settings → Backup and Restore, choose Export Backup. Save the file separately and confirm it is readable. Also record your subscriptions, overrides and current TUN parameters; keep sensitive contents private.

  2. Record the app and core versions separately

    Note both the Clash Party app version and the version of the running Mihomo core. v2.0.4 is an app release. Replacing only the core does not guarantee that you receive the app's wake recovery and settings-save fixes.

  3. Use the project's v2.0.4 release

    Choose the release for your operating system and architecture from the project Release page. Keep your backup and working configuration, fully exit the old instance and follow the platform's update procedure. Do not clear data, replace subscriptions and change all DNS settings together.

  4. Confirm the running app and configuration

    Make sure the app you opened is v2.0.4 rather than another older copy. Recheck the selected profile, node, proxy mode and original TUN parameters.

Do not copy the reporter's interface name, stack, MTU or DNS addresses. Those values belong to that environment, not to new defaults required by this fix. Keep your previously working settings and correct only an item you have confirmed is wrong.

After saving TUN settings, confirm the core restarts

Open the app's Virtual Adapter page and compare the interface name, network stack, automatic routing, DNS hijacking and excluded addresses with your notes. Menu language and platform can differ; follow your app's interface rather than instructions for a different client.

If a parameter genuinely needs correcting, change only the verified item and choose Save. v2.0.4 preserves the current TUN toggle state and restarts the core. Wait for completion before making a new request. If updating fails, record the error and keep the configuration rather than repeatedly saving or toggling it.

If no parameters need changing, do not alter MTU or the network stack just to trigger Save. Pause requests that cannot tolerate interruption, fully quit and reopen the app, then check TUN and actual requests again.

Do not treat a direct PATCH /configs request as the routine fix. The app still manages its toggle and configuration, so partial writes can conflict with its state. This guide uses in-app saving and restarting; it does not require opening a controller port or editing a temporary generated file.

Verify recovery with a sleep-and-wake cycle

With the same network and node, first test an ordinary page or request you are authorized to access and record the result. Put the computer to sleep, wake it, wait for the network to return and make a new request to the same destination. Existing connections or latency numbers alone are insufficient.

Recovery verification checklist

  • The app is v2.0.4, and the selected profile, node and original TUN parameters are recorded and recoverable.
  • Saved parameters remain correct, the core restart has completed, and there are no persistent update failures or TUN startup errors.
  • After wake, the same domain resolves, the same page or app request completes, and connection records show the expected rule and outbound.
  • After fully quitting and reopening the app, check the current TUN state and real requests again; a toggle's color does not prove traffic forwarding works.
  • Keep the test network, time, trigger steps and results. One successful test applies to that environment, not to every network condition.

If it still fails, preserve connectivity and data

If connectivity still fails after updating or saving, disable TUN in the app and check whether direct system access returns. Use a system proxy temporarily only if you already know that setup works. Its coverage differs and does not prove TUN is repaired.

Undo additional changes from this test and restore the recorded parameters and working subscription. Before importing a backup, save the current state separately. Import Backup overwrites the current configuration, so confirm the file and version are suitable; do not repeatedly overwrite your only copy.

If you must return to an older version, keep a copy of the newer data and use a separate backup made before updating. Cross-version data compatibility has not been tested here. Do not let the old app overwrite your only data directory, and do not assume it contains this fix.

For a report, provide the app and core versions, operating system, shortest sleep/wake or settings-save reproduction, relevant TUN section and error logs. Remove subscription Token values, node passwords and the controller secret; do not upload a complete sensitive configuration.

This guide was checked against the release record and fixed v2.0.4 source, not reproduced on every platform. Other permission, routing or DNS failures still need their actual logs. Follow later project releases and maintainer findings for subsequent changes.

References