Connectivity Troubleshooting · Clash Technical Blog

Mihomo dialer-proxy config load fix

Mihomo stalls or memory spikes on config load? Check whether many inline proxies use dialer-proxy, keep a complete backup, confirm the v1.19.33 fix, then verify loading, real requests and rollback.

Read the articleBack to blog
  • Mihomo
  • v1.19.33
  • dialer-proxy
  • Config validation
  • Memory usage
On this page
Published
Estimated reading time
About 8 minutes

CPU and memory may spike when the core starts or reloads its configuration, leaving the interface waiting to become ready, even though normal proxy use does not always consume much memory. When this happens is more useful than simply saying the subscription is large: first check whether the delay occurs during configuration validation, before deleting nodes or changing DNS.

Distinguish slow config loading from memory growth during use

This article covers Mihomo configurations with many inline proxies that set dialer-proxy. In official #3315, a real user’s large node configuration led maintainers to identify the validation cost, and v1.19.33 includes the fix. This is not a common explanation for every large subscription, memory increase or unresponsive client.

Choose the next check by when the problem occurs

SymptomWhat to check first
Startup, reload or -t validation stalls, and many proxies set dialer-proxyCheck the effective configuration, the running core version and the validation result for the same complete copy.
Only opening the tray menu or log page causes a freezeInvestigate the client interface and log handling first; the core validation fix is not a universal remedy.
Memory keeps growing after the proxy has been running for a whileRecord connection counts, DNS activity and runtime logs separately. Distinguish sustained growth from a peak during configuration loading.
An error immediately reports not found or circular dialer-proxy dependencyFix the missing target or actual cycle first. An upgrade cannot make an invalid reference valid.

Record the client version, the version of Mihomo actually running and the startup logs. A desktop client’s version is separate from its core version. Even mihomo -v may invoke a different executable on PATH, so confirm that it matches the core the client is using.

Inspect the final configuration passed to the core, not just the original subscription. Check whether many entries under proxies set dialer-proxy and whether the outbound proxies or proxy groups they reference exist. A small number of such entries is usually not enough to explain this validation cost. proxy-providers were outside the scope of that older check, so do not apply this diagnosis based on the total node count alone.

Reference relationships only; this is not a working node configuration
proxies:
  - {name: relay, type: socks5, server: 127.0.0.1, port: 1080}
  - {name: node-a, type: socks5, server: 127.0.0.1, port: 1081, dialer-proxy: relay}
  - {name: node-b, type: socks5, server: 127.0.0.1, port: 1082, dialer-proxy: relay}

In the example, relay is the name of the referenced proxy. The local addresses and ports are placeholders; do not paste them over a real subscription. A referencing B while B references A, or an entry referencing itself, is still a genuine cycle. If a target was renamed or removed by an override, restore the correct reference rather than deleting dialer-proxy to bypass the check.

Validate a complete copy with a way back

Keep the comparison conditions consistent

  1. Back up the working configuration first

    Back up the current configuration, overrides, external resources and client settings in a separate directory. Record the original core version and system proxy/TUN states. Do not upgrade, change subscriptions and adjust DNS together in your only data directory.

  2. Confirm the executable and test directory

    For command-line testing, first confirm that the candidate file exists and contains the expected configuration, then replace the placeholder paths with those of the complete copy. -v reports the version. -t initializes the data directory and may create a default configuration if the file selected by -f is missing; it is not a read-only operation. -d selects the copied data directory. Preserve the original relative paths and required resources, and do not treat a successful test alone as proof that the candidate configuration was read.

  3. Run the test once and record the result

    Choose a time when the test can be interrupted, and record its duration, peak process memory and first error. Testing may consume resources or read external resources; zero network access is not guaranteed. If an app-managed core has no supported command-line entry point, use the project’s configuration validation and logs instead of forcibly replacing or extracting its internal executable.

Command line: replace the paths and use the same complete copy
mihomo -v
mihomo -t -d "/path/to/complete-copy" -f "/path/to/complete-copy/config.yaml"

Update the running core and retain cycle detection

The v1.19.33 release notes list the #3315 fix. At that fixed tag, the code reuses traversal state instead of repeatedly allocating large checking structures for every node with a reference. It still reports missing targets and circular references. The fix reduces validation cost; it does not repair the relationships in a configuration.

Use the update method supported by the project

  1. Confirm the update channel

    For a standalone core, choose a stable MetaCubeX/mihomo release that matches your operating system and architecture. For a graphical client, follow that project’s supported app or core update process; do not arbitrarily overwrite binaries in its service directory.

  2. Confirm that the update includes the fix

    v1.19.33 is the stable release verified for this fix. FlClash v0.9.2 explicitly lists Mihomo v1.19.33 in its changelog, making it a sourced example. Check other clients’ own records rather than assuming that a successful app update also replaced the core.

  3. Check the running version again

    Restart the relevant app or core normally as the project requires, then read the version from the actual process or startup logs. Keep the original configuration and resource backup. For the first verification, do not also switch nodes, refresh the subscription or change DNS.

After config validation, test real proxy requests

Verification checklist

  • The core actually running has been confirmed to include the v1.19.33 #3315 fix; only updating the client interface is not enough.
  • -t validation of the same complete copy, or the supported validation option for an app-managed core, finishes normally, and you have confirmed that the candidate configuration was actually read. Compare duration and peak memory on the same device under similar load; do not adopt someone else’s timing or memory limits.
  • After a normal startup and reload, proxy groups, node selections and dialer-proxy references still behave as intended.
  • Restore the required system proxy/TUN settings, send a real HTTPS request to the same destination and inspect the connection records. Passing configuration validation does not guarantee that a node works.
  • If missing-target or cycle errors remain, fix the configuration using the full error. If memory only keeps growing while handling traffic, investigate other causes instead of repeating configuration-loading stress tests.

This site has not run these commands on a real client or router and does not guarantee a particular speedup. The comparison helps you decide whether your configuration matches the verified fix; network issues, device memory and other configuration problems still need separate checks.

If the update still fails, restore a working setup

Save the current error and a configuration copy, then stop repeatedly reloading. Undo system proxy/TUN settings newly enabled during this attempt according to your earlier notes, and restore the previous working network setup. Do not erase all rules or disable security software to conceal the problem.

If the upgrade causes compatibility problems, use the project’s supported method to restore a known working version with its matching configuration and resources. Do not let old and new versions share your only data directory. The old version may still have this validation-cost problem, so rollback is not a fix. On devices with little memory, restore a previously working configuration first and defer loading the problematic large configuration.

When reporting the problem, provide the running core version, operating system and architecture, loading stage, approximate number of relevant entries, timing/memory trends and redacted errors. Remove subscription tokens, node passwords, private keys and real server details before sharing. Preserve only the minimal reference relationships needed to reproduce the issue; do not publish a complete subscription.

References