Frequently Asked Mihomo Questions

Mihomo is the core that handles proxy connections, DNS, and rule matching. A graphical client provides an interface for importing configurations, choosing proxy groups, and managing the system proxy. Even when clients use the same core, their menus, permission prompts, and configuration-merging behavior can differ. Before following a guide, check which client it covers, then verify the core details in its settings or logs. If a configuration option is not recognized, consult the documentation for the core version you actually use; the app’s appearance alone does not confirm feature support. Most desktop users will want a graphical client. Core-only packages are mainly for command-line, server, and router deployments.

The client applies a configuration; it does not provide a remote proxy service. A subscription link, usually issued by your service provider, supplies nodes, proxy groups, rules, and other settings. You can also use a local YAML file. Before importing, make sure the configuration supports Mihomo. A provider’s website or account login page is not a subscription URL. Treat subscription links like account credentials: don’t share them in public screenshots, group chats, or code repositories. If a link is exposed, reset it in your provider’s dashboard and update it on all your devices.

Rule mode routes requests according to the order of rules in your configuration, sending them direct, through a proxy group, or to another policy. It’s suited to everyday traffic routing. Global mode applies the selected global policy to requests handled by the core, making it useful for briefly checking whether rules are affecting access. Direct mode connects those requests straight to their destinations. These modes determine how the core handles requests it receives; they don’t ensure that every app’s traffic reaches the core. System proxy and TUN control how traffic gets there. To troubleshoot, you can temporarily switch to Global mode and select a working node. Switch back to Rule mode when you’re done so the temporary setting isn’t left in place.

UDP forwarding depends on the entire connection path: whether app traffic reaches the core, whether UDP is enabled for the node, whether the proxy protocol and server support it, and whether the network allows the packets through. A node marked available or a website that loads only confirms that some connections work; it doesn’t replace an actual UDP test. Games and calls may also depend on DNS, direct-routing policies, and the NAT environment. First check how the app’s traffic enters the client, then inspect the matched proxy group and node, and finally test in the app itself. Enabling a UDP option cannot make up for missing server-side support.

Start by checking the HTTP status and error details in the update log. A 401 usually indicates missing or expired credentials. A 403 may point to an access restriction, subscription status, or server-side policy; check your provider’s guidance. Copy the full subscription URL again from your dashboard and make sure no query parameters are missing, no spaces were added, and you haven’t copied a webpage link instead. If the URL opens but importing reports a YAML error, check that the response isn’t a login page or an error message. Determine whether the download failed or the configuration could not be parsed before taking action. Don’t repeatedly delete a working configuration; keep the old one as a temporary fallback.

TUN creates a virtual network interface and adjusts routes, so it usually needs more permissions than the system proxy. On Windows, check that the client’s service mode is installed and running, then grant administrator access as prompted. Don’t run multiple proxy tools that take over routing at the same time. On macOS, follow your client’s instructions to check system permissions or its helper service; not every prompt is for the same kind of network extension. After granting access, enable TUN again and check the first error in the log. If the interface still can’t be created, turn off TUN and test the system proxy, then troubleshoot permissions, drivers, and routes separately.

Check your operating system’s hardware information instead of guessing based on the device’s age. On Windows, find the system type in Settings > System. Most Intel and AMD PCs use x64; for ARM devices, check whether the client offers a compatible build. On macOS, use About This Mac to identify an Apple silicon or Intel processor and choose the matching architecture. An incompatible build may not start or may require system translation support. Back up your configuration and quit any running instance before updating. If the installer says your OS version is unsupported, check the client’s release notes rather than running the installer again.

Android clients often use VpnService to route device traffic, so you must approve the system VPN prompt the first time you connect. This allows a local VPN interface to be created; it doesn’t mean the remote node is working. Usually, only one VPN can be active in a user profile, so starting another VPN app may interrupt the current connection. If the client disconnects in the background, check whether Android restricts battery use, background activity, or auto-start, then allow the client using the settings available on your device. Also distinguish between the app being killed and the node losing its connection: a missing notification often indicates the former, while the latter calls for checking logs and subscription status.

The system proxy provides a proxy address to apps that follow system settings; it doesn’t force all network traffic through the proxy. First, check that the address and port in system settings match the client’s actual listening address. Then check whether the app uses its own proxy, a browser extension, environment variables, or separate network settings. While testing, open the client’s connection list and see whether new requests appear. If they don’t, fix how traffic enters the client before changing routing rules. For apps that ignore the system proxy, configure an in-app proxy or use TUN as needed. Before switching methods, turn off conflicting settings so you can tell which route traffic is taking.

Some Windows apps isolated by AppContainer can’t access a loopback proxy on the local machine directly, so a working browser doesn’t prove those apps can connect. First confirm that the app is affected by this restriction. Then use the client’s loopback exemption tool or Windows CheckNetIsolation to inspect and manage exemptions for specific apps. Grant access only to the apps that need it rather than exempting everything. Restart the affected app and check its connection log. A loopback exemption only addresses local proxy access; it won’t fix an expired subscription, DNS errors, or remote node timeouts. Not every Store app needs one.

A typical latency test measures how long it takes to reach a test address; it doesn’t measure sustained download bandwidth. Results depend on the test target, timeout threshold, caching, and the route from the node to the destination. Compare nodes using the same test address at roughly the same time, then try the services you actually use. Download speeds can also be affected by server-side limits, congested egress, Wi-Fi quality, and restrictions at the destination. Don’t switch nodes repeatedly based on a single latency ranking. Existing connections may keep using the old node while new connections use the newly selected one, so check them separately.

Fake-IP mode maps domain names to synthetic addresses so the client can associate them with later connections and apply domain-based rules. These addresses aren’t the destination’s real public IPs, so you can’t judge their reachability like ordinary direct-connection addresses. If LAN device discovery, a specific login app, or software that relies on real DNS results stops working, first check whether Mihomo is handling DNS requests. Then inspect fake-ip-filter and related DNS policies for the affected domains. Don’t add every domain to the filter. You may need to flush DNS caches in the OS and apps and reconnect after making changes. Keep a copy of the original configuration for comparison.

Turn off the proxy first to verify that the underlying network works. Then check the device clock, whether the subscription updated successfully, and whether your plan and nodes are still active. If only one node times out, compare it with other nodes from the same subscription. If all nodes time out, check your network’s egress, configuration errors, and your provider’s status first. In the logs, distinguish DNS resolution failures, refused connections, authentication errors, and handshake timeouts; each calls for a different fix. The test address itself may be unreachable, so try the actual service you need as well. Don’t change the port, DNS, and rules all at once. Change one thing at a time and record the result.

Connected may only mean that the core or local VPN interface has started; it doesn’t guarantee that requests can reach their destinations. First, check whether browser requests appear in the connection list. If not, check system proxy, app proxy, or TUN routing. If they do, inspect the matched rule, proxy group, and node. Use the logs to distinguish DNS failures from remote connection failures, then briefly test Global mode with another working node. If switching nodes fixes the issue, focus on the original node. If only certain domains fail, check the rules and DNS resolution. Start a new connection for each test so the browser doesn’t reuse an old one.

First, make sure Rule mode is active and check the configuration that’s actually in use, not just the file saved in your editor. Some clients merge subscriptions, overrides, and local rules, and later updates may change the final configuration. Mihomo matches rules in order, so an earlier broad rule or MATCH may prevent later entries from being reached. Make a new request to a specific domain, then check the matched rule and policy in the connection details. Existing long-lived connections usually don’t move to a different route when rules change; close the relevant connection and try again. Put custom rules in a client-supported override or merge entry so they persist.

Reopen the client, turn off the system proxy and TUN, then exit normally so it doesn’t leave traffic interception enabled. In your system network settings, check whether the proxy still points to a local port; it won’t respond once the core has stopped. If you changed DNS manually, note the current values and restore the settings required by your network. Make sure no other proxy or VPN is running at the same time. Test after each change instead of immediately resetting all network settings. If the issue happens only after waking from sleep or switching networks, note when it occurs, the interface state, and relevant logs, then check the client’s release notes.