Clash Nyanpasu FAQ

Clash Nyanpasu is a graphical client for managing configurations and proxy settings. mihomo is the core that handles protocol connections, DNS resolution, and rule processing. Subscription services provide server details and configuration data. Installing the client does not give you working servers; you also need a trusted, active subscription or a configuration for your own server. When troubleshooting, first determine whether the interface settings were applied, the core is running, or the subscribed servers are unavailable, then check the relevant component.

Rule mode evaluates connections against the configured rules in order, sending each connection direct or through a proxy group. It’s a good starting point for everyday use. Global mode sends connections that reach the core through the outlet selected by the global policy, but it doesn’t mean every app on your computer is being routed through it. Direct mode generally sends connections handled by the core straight to their destinations. Changing modes doesn’t replace system proxy or TUN settings. If an app’s traffic never reaches the core, switching between these modes won’t change its route.

No. An installer must match both the operating system and processor architecture. A Windows executable won’t run directly on macOS, Linux, or mobile devices. The download page lists available clients by platform; it doesn’t mean every client supports every platform. Check your device’s system information before choosing a download. On mobile, also make sure the client supports the protocols and fields used by your subscription. Desktop configurations can be a useful reference when migrating, but local paths, listening addresses, permissions, and TUN options often need to be adjusted.

A subscription link is an address for retrieving configuration data; YAML is a common configuration file format. They aren’t the same thing. Some links return a complete configuration with proxies, proxy groups, rules, and DNS settings. Others return only server details and require a client or subscription service that supports conversion. Check the service’s documentation for supported formats before importing; the link’s appearance alone tells you little. Subscription URLs may contain access credentials, so don’t share the full URL when troubleshooting or submit it to unfamiliar online converters.

For everyday use, choose the stable build offered by your client that is compatible with your configuration. Alpha builds are generally for testing new features or fixes, and their behavior may change; don’t switch just because the name sounds newer. If you need a specific new field or protocol feature, check the core’s release notes, back up your configuration, and test it. If the core fails to start after switching, read the first configuration error and revert to the previous core. Different cores don’t support exactly the same fields, and switching cores won’t convert your configuration automatically.

A successful import only means the content was saved; it doesn’t mean the configuration is active. Select the newly imported profile in the configuration list and confirm that the core starts successfully. Then, on the proxy page, choose an available outlet in the group you’ll actually use. For everyday browsing, start with Rule mode and enable the system proxy. Consider TUN for apps that don’t follow system proxy settings. Finally, visit a site you know is available and check the connection log. If there are no entries, check how traffic is being routed instead of repeatedly changing subscriptions or servers.

First check whether the subscription expired, was reset, or was copied incompletely. Then use the logs to distinguish a request failure from a parsing failure. For request failures, check your local network, certificates, and the server’s response. For parsing failures, make sure the response isn’t a login page, error page, or format unsupported by your client. If the provider requires a specific User-Agent, set it as instructed. If you edited the YAML manually, check indentation and field types. Keep the old configuration while troubleshooting so you don’t lose servers that may still work.

Turn off TUN first and confirm that the regular proxy mode works. Then follow the instructions for your client version to install or enable service mode, and grant the requested permissions when prompted by your operating system. On Windows, check that the service is running and that security software isn’t blocking the network adapter component. On other systems, check the helper service and network extension permissions. Don’t run multiple proxy clients at once if they might compete for the virtual adapter. If it still fails, save the first error in the log, close conflicting apps, and try again. Avoid deleting unknown adapters or changing system routes.

Not necessarily. The system proxy directs apps that honor the operating system’s proxy settings to a local proxy port, making it a good first option for testing browser access. TUN uses a virtual network interface to capture traffic that matches its routing rules. It’s often used for apps that ignore system proxy settings, and requires additional permissions and correct DNS settings. Some configurations allow both modes to work together, but when troubleshooting, enable just one at a time. Once you’ve confirmed it works on its own, combine them if needed to avoid mixing up routing, port, and DNS issues.

Back up your subscription sources, configurations you maintain manually, overrides or merge rules, and custom DNS, port, and core settings. Use the client’s export or backup feature and confirm how to restore the data. If you copy the configuration directory, quit the client first to avoid copying files before they’ve been written. Automatic subscription updates may overwrite direct edits, so use a supported override mechanism for changes you want to keep. Backups may contain subscription credentials and server passwords; store them securely and don’t attach them to public support requests.

Use the override or rule editor supported by your configuration to add a Direct rule for the target domain before broader rules that might match it, and keep Rule mode enabled. A domain-suffix rule also applies to matching subdomains, so check that its scope is what you intend. Save and reload the configuration, close existing connections or restart the relevant app, then check the connection log for the matched rule and actual outlet. Don’t rely only on whether the site opens in your browser: caching, connection reuse, and the app’s own proxy settings can all affect the result.

First confirm that the connection actually matches the proxy group you changed. Configurations may contain nested groups: selecting an automatic test group in the outer group doesn’t necessarily determine the final server, which may be chosen by an inner group. Existing connections usually won’t move immediately when you change a selection, so disconnect them or restart the app before testing again. For an automatic selection group, check its test URL, interval, and timeout. Those results reflect reachability under the test conditions and don’t guarantee the same performance for every service.

A latency test usually measures response time to a particular test URL. It doesn’t measure available bandwidth or directly indicate speeds from video sites or download servers. Congestion, server-side limits, destination location, packet loss, and protocol overhead all affect real-world performance. Compare servers using the same network and service at similar times, and check the connection log to confirm the expected outlet is being used. Don’t draw conclusions from a single lowest-latency result; sustained transfer performance is often more useful than a few test readings.

If you edit a file downloaded from a subscription directly, the next update may replace your changes. For rules you want to keep, use an override, merge, or script mechanism supported by your current client version, and confirm the order in which changes are applied. After editing, test both a manual reload and a subscription update, then check that the final active configuration still contains the rule. If a proxy group’s name changes in the subscription, references to it may stop working too. When a policy can’t be found, check the rule references as well as the old file.

Fake-IP returns a virtual address to the app to map a domain name. The core uses that mapping to handle the connection, helping preserve domain information when traffic is captured. It isn’t a switch that fixes every DNS issue on its own; the DNS listener, traffic capture, and upstream resolution settings must also be configured correctly. Some local network services and apps that rely on real IP addresses may need exceptions. After making changes, clear relevant caches and establish new connections. Verify the result using logs and the actual resolution path; a location shown on a test page alone doesn’t prove the configuration is correct or that DNS is leaking.

Turn off the proxy to test your underlying connection, confirm that your system clock is correct, then check that the configuration is active, the subscription is still valid, and the core log shows no errors. If every server times out, focus on shared dependencies such as DNS, an unreachable test URL, network restrictions, or a core that isn’t running. If only some servers fail, check those servers first. Compare results on another trusted network and try accessing a real service instead of relying only on the speed test button. When reporting the issue, include the time it occurred and a redacted log; never share the full subscription URL.

First check the client’s connection log for requests from the app. If none appear, confirm that the system proxy address and port match the core’s actual listening address, and check whether a browser extension, app-specific proxy, or another VPN is overriding the settings. Some apps don’t use the system proxy and need to be configured separately; you can also consider TUN if it suits your needs. If the connection reaches the core but goes direct, check the matching rule and proxy group. An enabled system proxy doesn’t mean every app is being proxied.

Some UWP apps isolated in an AppContainer are restricted from connecting to loopback addresses, which can prevent them from reaching a local proxy port. First confirm that a desktop browser works, then check whether the affected app is subject to this restriction. If your client provides a UWP loopback exemption tool, add an exception only for the apps that need it and grant administrator permission when prompted. You can also use Windows’ CheckNetIsolation tool to manage exceptions. Don’t enable access for every app indiscriminately. If the problem persists, check whether the app follows the system proxy or consider routing its traffic with TUN.

First check whether your system is still pointing to a local proxy address that’s no longer listening, and turn off any leftover manual proxy settings. Then check whether TUN, service mode, or another VPN is still running; stop it normally and reconnect to the network. If you changed DNS settings manually, restore settings suitable for your current network and clear the cache. Don’t start by resetting all network adapters or deleting routes, as this could affect work networks and other software. Once basic connectivity is restored, restart the client and enable features one at a time to find the setting that caused the issue.

Turn off TUN to compare and confirm whether traffic capture is causing the issue. Then check how the current configuration routes and resolves LAN addresses, private subnets, and internal domain names. Destinations that should connect directly need to match the right rule, and internal domains need to use a DNS server that can resolve them; changing proxy rules alone may not fix incorrect DNS resolution. A work VPN running alongside TUN can also cause route conflicts. Set exceptions for the network ranges you actually need, and avoid excluding overly broad address ranges that could change the expected route for other connections.