Connectivity Troubleshooting · Clash Technical Blog

OpenClash invalid tun stack: recovery

OpenClash reports invalid tun stack after an upgrade, then disables itself? Check the final mips value against your older core, back up, select a verified Mixed stack and re-enable the plugin. Verify requests and a restart; restore your configuration if it fails.

Read the articleBack to blog
  • OpenClash
  • invalid tun stack
  • mips
  • Mixed
  • Core startup
On this page
Published
Estimated reading time
About 8 minutes

After an OpenClash upgrade, the core may exit repeatedly before the plugin reports that it is disabled. Repeatedly pressing Start may not help. If invalid tun stack appears first, check whether the generated stack value is compatible with the actual core, then restore the plugin's enabled state.

Find the first core error after the upgrade

OpenClash #5361 describes this after an upgrade from v0.47.156 to v0.48.002 while retaining an older core. In Kwrt fake-ip-tun mode, the reporter found that the unsaved stack_type setting was empty, but the final configuration contained mips.

Their older alpha-fe22fdd core rejected that value. Changing it to mixed passed configuration validation and restored startup. The report remains open without an official fix conclusion. This conditional troubleshooting guide follows the tagged source; we have not reproduced it on a router.

Continue with these checks when this error pair appears
Parse config error: invalid tun stack
OpenClash Now Disabled, Need Start From Luci Page, Exit...

Check whether these symptoms match

What you observeNext check
invalid tun stack appears first, with mips in the generated tun.stackCheck whether the running core supports that value, then make a reversible comparison.
The plugin reports that it is disabled, without the earlier core errorLook further back in the startup log; another startup failure may have disabled it.
The core runs normally, but a web request or DNS failsInvestigate the actual connection error first. This alone does not establish a stack incompatibility.

Why does it still say Disabled after a stack change?

The v0.48.002 settings page defaults the TUN stack to mips. The generator first uses the supplied stack value, then another parameter if it is empty, and finally mips if both are empty. Check your own final configuration rather than assuming every subscription is always overwritten.

Here, mips names a TUN stack. It does not refer to the router's MIPS processor architecture or the ip-stack of a MASQUE outbound. Seeing this name is not a reason to change the core architecture or edit an outbound node.

The tagged Mihomo v1.19.30 parser lists only gvisor, system and mixed. v1.19.31 already includes mips, as does v1.19.32. Core builds can therefore accept different values, but the plugin version alone cannot identify the build you are using.

OpenClash writes enable to 0 when startup fails, and the startup entry exits immediately if the plugin is disabled. Changing only stack_type and running start may therefore leave the Disabled message unchanged. Recovery must also confirm that the plugin is enabled again.

Back up, then identify the core and original values

Keep a local connection that lets you manage the router, and pause transfers that cannot be interrupted. Save plugin settings, subscriptions and custom configurations to a separate readable location. Record the previously working mode, stack and plugin enabled state.

Check the Mihomo version actually loaded in the plugin's core information and startup log. Another command-line copy is not evidence of the core the plugin uses. Do not infer supported stacks from the application version or a filename alone.

If you already use the router terminal, read these settings
uci -q get openclash.config.stack_type
uci -q get openclash.config.enable

No output from the first command may mean that the setting is unset; it does not prove the final configuration is empty. Separately inspect tun.stack in the generated runtime configuration and record the first parse error. Do not publish full configurations, subscription URLs, node passwords or the controller secret.

For further validation, use the plugin's actual core and configuration. A successful configuration check proves parsing, not working forwarding, DNS or LAN traffic handling. This guide does not require downloading a test core or running the reporter's binaries.

Select a verified stack and re-enable the plugin

Make this single-setting comparison only when the error, final mips value and core compatibility agree. Mixed passed the reporter's check and is supported by the older tagged code described above. It is not universally the best option for every network.

Recover through your own LuCI page

  1. Record the original setting and select Mixed

    Open Plugin Settings → Operation Mode → Select Stack Type. Record the original value, then choose Mixed. Labels can vary by language. Do not change the processor architecture, subscription, DNS or operating mode at the same time.

  2. Apply the settings and confirm that the plugin is enabled

    Click Apply Settings, wait for the service to restart, and confirm that the plugin is enabled. In the tagged source, Commit Settings only commits changes; Apply Settings re-enables and restarts the service. If it still reports Disabled, explicitly enable it in LuCI before checking the logs.

  3. Check the regenerated configuration and logs

    Confirm that the final tun.stack is mixed, the actual core no longer reports invalid tun stack, and the service stays running. If the setting has not reached the runtime configuration, check the active configuration and saved settings rather than repeatedly editing temporary YAML.

  4. Verify using the same network and request

    Keep the node, subscription and other settings unchanged. Start a new web or application request, then check its actual outbound and logs. Existing connections or the switch colour cannot prove that the new stack is handling traffic.

Do not directly edit generated runtime YAML that may later be overwritten, or patch the default-value script to hide the problem. An official core upgrade can be evaluated separately with architecture, configuration compatibility and backups checked. We have not verified that complete core replacement procedure here.

Verify parsing, connectivity and a normal restart

Keep these verification results

  • The original stack_type and enable state, current core version and a separate configuration copy are recorded.
  • The final tun.stack matches the intended value. Startup logs no longer show invalid tun stack or repeated plugin-disabled messages.
  • The service stays running, the same domain resolves, and new requests to the same website or application complete.
  • Router management and the LAN devices that previously needed proxying work as expected. A successful node latency test cannot replace these checks.
  • After a planned normal service restart, recheck the actual core, final configuration, enabled state and new requests to confirm that the setting persists.

Save the network, time, stack values before and after, and request results together. If parsing passes but connectivity still fails, inspect actual routing, permission, DNS or node errors instead of attributing every symptom to this parse error.

How to roll back and report a remaining failure

Restore the recorded stack and enabled state, using a separately saved configuration or mode that previously worked. Before importing a backup, save the current state and check version compatibility. Do not clear data or let an older plugin overwrite your only configuration copy.

If the retained core still triggers the original parse error, stop using that failing combination and restore management through a previously verified connection method. Temporary connectivity and a completed TUN repair require separate checks. Disabling a switch is not a guaranteed fix for every router.

Report the plugin and actual core versions, firmware, device, original stack, final tun.stack, whether you re-enabled the plugin, the earliest parse error and minimal reproduction steps. Remove subscription Token values, node credentials and secret values rather than uploading a full sensitive configuration.

Check maintainers' conclusions and release notes for any later official fix, default change or revised scope. This guide reviews a user report and versioned upstream source. The reporter's Dev source comparison is not evidence of runtime testing across versions.

References