The short answer
Proxy groups separate selection policy from individual endpoints. Selector gives direct control; URL-Test automates measurement, but the test URL, interval and tolerance all influence the winner.
This guide approaches “Measure latency correctly and tune automatic selection” through decisions, a safe order of operations and checks you can reproduce. It avoids unverified feature claims and interface labels that may quickly move.
Prepare before changing anything
Confirm the operating system, processor architecture and source of the client first. Export the current configuration and treat subscription URLs like passwords: keep them out of screenshots, public logs and chat messages. System services, startup integration and TUN may require elevated privileges.
OS → CPU architecture → package format → source → backup
A reliable order of operations
Build the smallest working setup first: launch the client, verify the core is healthy, import an authorized configuration, select rule mode and test one known-good connection. Change one variable at a time, record the result, and only then consider TUN, automatic selection or sync.
- CLIENT / CORE
- CONFIG / RULE
- CONNECTION / DNS
- OPTIONAL TUN
Mistakes and diagnosis
A latency number measures one test target; a successful subscription refresh does not prove that every endpoint works. Restore direct connectivity first, then check time, base network, DNS, firewall, permissions and syntax in that order. Start with the first concrete error in the log.
Proxy groups separate selection policy from individual endpoints. Selector gives direct control; URL-Test automates measurement, but the test URL, interval and tolerance all influence the winner.
Security and maintenance
Use maintained stable releases, read the official release notes before updating and keep a rollback path. Remove expired subscriptions, stale profiles and unnecessary service privileges. Finish by testing direct traffic, proxied traffic, DNS and behavior after a restart.