Clash

Clients, YAML rules, and platform guides

English documentation for Clash across Windows, macOS, Android, iOS, and Linux. Client references, YAML structure, routing behavior, setup notes, version information, and common issues are organized by task and platform.

Download Desktop

Core sections

Client references

Build names, release references, platform coverage, and installation paths are separated by operating system. Version details and platform notes are kept distinct to reduce confusion between different clients.

Configuration structure

YAML examples, provider layout, groups, rules, DNS, and TUN behavior are explained as configuration elements rather than copy-and-run templates. The focus stays on structure, field roles, and adjustment logic.

Platform differences

Windows, macOS, Android, iOS, and Linux differ in permissions, system proxy behavior, TUN support, certificates, DNS handling, and troubleshooting paths. Those differences are documented separately where they matter.

Client references

Clash for Windows

Windows client reference

Version: v0.20.39
Updated: 2025-12-18
Clash Verge

Desktop client reference

Version: v1.7.5
Updated: 2025-12-18
FlClash

Android client reference

Version: v2.1.5
Updated: 2025-12-18
Clash Meta for iOS

iOS client reference

Version: v2.1.8
Updated: 2025-12-18

Service evaluation factors

Provider choices vary by region, workload, traffic limits, and maintenance quality. The points below are intended as evaluation criteria rather than endorsements.

Evaluation notes

Pricing

Plan pricing should be read together with limits, reset policy, and device count.

Check limits
  • Monthly plans are easier to validate first
  • Long billing cycles need clearer trust signals
  • Traffic caps matter as much as price
Coverage

Region count matters less than actual availability and route stability.

Check stability
  • Core regions should remain usable at peak time
  • Route variety affects fallback options
  • Update cadence affects continuity
Validation

Short-term validation is more useful than assumptions based on labels alone.

Test first
  • Trials help validate access and stability
  • Peak hours reveal more than off-peak tests
  • Real tasks matter more than synthetic numbers
Experience

Latency, bandwidth, and stability affect different workloads in different ways.

Judge by workload
  • Browsing is more sensitive to latency
  • Streaming depends more on steady bandwidth
  • Consistency matters more than isolated peaks

Guides and references

Windows setup

Installation, first launch, subscription import, TUN, system proxy, and common Windows-specific issues.

Reference guide
  • Installation and first run
  • Proxy and TUN behavior
  • Common platform-specific issues
Android setup

Import flow, permission handling, background behavior, per-app routing, and compatibility notes for Android.

Reference guide
  • Permissions and battery rules
  • Import and route behavior
  • Compatibility notes
iOS setup

Profiles, certificates, import behavior, system settings, and platform constraints for iPhone and iPad.

Reference guide
  • Profiles and certificates
  • Import and system settings
  • Platform-specific limits
Rule structure

Matching order, rule logic, group behavior, and how routing decisions are organized in YAML.

Reference guide
  • Rule order and matching
  • Group design and routing
  • Maintenance and debugging
Subscription handling

Provider links, YAML conversion behavior, update flow, compatibility notes, and common formatting issues.

Reference guide
  • Provider links and updates
  • YAML compatibility notes
  • Common conversion issues
Common issues

Component issues, system proxy residue, WebView2 behavior, service state, permission errors, and update problems.

Reference guide
  • Proxy and component issues
  • Permissions and services
  • Update and startup problems

FAQ

For browsing, messaging, and routine tasks, moderate bandwidth is usually enough. Stable behavior during busy periods is often more useful than a single peak result from a speed test.

Video playback depends more on sustained bandwidth and stability than on latency alone. Higher resolutions require more steady throughput, especially at peak hours.

Acceptable latency depends on workload and route quality. Browsing and interactive tasks benefit more from lower latency, while large transfers and streaming depend more on stable bandwidth.

A Clash node is a proxy endpoint used by the client. Nodes are usually imported through a provider or subscription source and then selected through groups and rules.

No. Lower latency helps interactive tasks, but overall performance also depends on bandwidth, route quality, congestion, and how stable the connection remains over time.

A subscription usually provides multiple nodes and related metadata. Rules decide how requests are matched and which group, route, or policy is applied to different destinations.