Project History and Configuration Formats
Clash began as a rule-based proxy core with YAML configuration, followed by different forks and graphical clients. The original project's maintenance status differs from that of later projects, so instructions for an older client may not apply to every current client. mihomo continues the technical direction of the Clash Meta project; check the current project documentation and the client's actual integration for specific behavior. When reading older articles, verify what the fields mean and which core they apply to instead of relying only on interface screenshots.
Indentation, lists, and references in configuration files all affect parsing. Save a working copy before editing and change one section at a time. If parsing fails, check the field and surrounding context reported in the logs, then confirm that the field is supported by your core. Loading a file only means it passed the relevant structural checks; it doesn't prove that nodes connect, rules match correctly, or system traffic is being captured. Verify each of these separately.
Graphical Interfaces and Proxy Cores
A graphical client displays configurations, manages processes, and integrates with system features; the core parses rules, establishes connections, and handles DNS. They may be updated separately, so changing the interface doesn't necessarily change core behavior, and updating the core doesn't necessarily change how subscriptions are imported. When choosing a client, check its platform and installation method as well as its service mode, override support, log access, and configuration export options. These make it easier to troubleshoot issues and migrate settings later.
Check each project's open-source scope and license terms separately. Using the same core doesn't mean the entire app has the same license. The mihomo repository publishes source code and license information for reviewing specific implementations, issue discussions, and releases. This site brings download links together with Chinese usage guides; each project maintainer remains responsible for releases, app store distribution, and subscription services.
Keep three kinds of updates distinct
Client updates change the app itself, core updates affect protocols and networking behavior, and subscription updates refresh nodes or configurations provided by a service. If a node stops working, first check whether the subscription has expired and whether the updated configuration is active, rather than immediately reinstalling the client. For an unknown protocol or field, check the core's supported features. Read release notes and keep a working copy of your configuration before updating. Afterwards, recheck listening ports, traffic capture settings, and proxy group selection in case defaults have changed.
Subscriptions may include provider-defined DNS settings, rules, and proxy groups. Local edits can be replaced by the next update. Use your client's override or merge feature for rules you want to keep, and check the merge order. Don't upload a complete subscription file to a public forum. When reporting an issue, include only the relevant configuration section, system details, and error lines needed to reproduce it.
Verify Connections and Review Logs
First confirm that the core is listening, then check that app requests appear in the connection list, and finally review the matched rule and actual outbound. This makes it easier to find where a connection fails than repeatedly switching nodes. Latency tests only check a specific address; passing one doesn't replace testing real services. Similarly, a page loading doesn't prove that every app uses the same route. For command-line tests, check whether the current shell has proxy environment variables set and confirm that its traffic capture method matches your browser's.
Debug logs may contain visited domains, destination addresses, and local paths. Remove anything unrelated to the issue before sharing them. After troubleshooting, restore a suitable everyday log level to avoid recording excessive requests. The controller port and mixed proxy port serve different purposes: the former provides the management interface, while the latter accepts proxy requests. Don't enter a management address in your browser's proxy settings. Default ports are common values; use the listening details currently shown by your client.