First, define what needs syncing: nodes, rules, or the complete runtime configuration
“Using one configuration across multiple devices” usually means one of three things: giving Windows, macOS, and mobile devices the same node list; using the same rules and proxy groups everywhere; or copying the complete config.yaml. These have different sync scopes. Node subscriptions are easiest to standardize, while rules and proxy groups work well under centralized maintenance. A complete runtime configuration is often affected by the operating system, client, and core version.
Clash and mihomo configurations contain more than proxy servers. Listening ports, the controller address, TUN, DNS hijacking, LAN access, GeoData mode, and local file paths may all live in the same YAML file. Copying a complete configuration from a running Windows setup directly onto macOS can cause interface-name mismatches, port conflicts, or broken rule-set paths.
Split the configuration into three stability layers
- Shared data layer: proxy nodes, remote rule sets, and proxy-group structure. This layer is suitable for standardization across devices.
- Platform parameters: TUN, DNS, listen addresses, ports, process matching, and interface selection. Maintain these separately for each operating system.
- Client state: window size, theme, tray behavior, log level, and the most recently selected configuration. Keep these on the local device rather than syncing them.
Option 1: Use the same subscription URL on every device
Keeping one subscription URL updated is the lowest-maintenance option. Each device stores its own subscription entry and fetches the configuration from the same address when needed. Clash Verge Rev on Windows and macOS, along with compatible Android clients using the mihomo core, can all import the same URL separately. Because local files are not transferred directly between devices, their runtime states do not overwrite one another.
Typical workflow
- Open the “Subscriptions” or “Profiles” page in the desktop client.
- Choose “New” or “Import,” then paste the HTTPS subscription URL.
- After the download finishes, select the profile and choose “Set as active.”
- Set an interval in the auto-update settings, such as 1,440 minutes for a daily refresh.
- Repeat the import on the other devices instead of copying cache files generated by the first device.
Menu labels may vary slightly between clients. In Clash Verge Rev 2.x, subscriptions are usually managed on the “Subscriptions” page, while the core, system proxy, and TUN controls are under “Settings.” When troubleshooting, distinguish between “the subscription was updated” and “the active profile was switched”: the former only downloads new content, while the latter determines which configuration the core actually loads.
How to choose an auto-update interval
When node details do not change frequently, updating every 12 to 24 hours is usually enough. A five-minute interval increases requests to the server and may repeatedly write the configuration during network changes. If nodes temporarily disappear, run one manual update and check whether the timestamp shown by the client changes.
| Item | Standardized? | How to handle it |
|---|---|---|
| Node list | Yes | Import the same subscription URL on every device |
| Proxy groups | Usually | Generated by the subscription content or conversion template |
| Currently selected node | Per device | Choose based on local network latency |
| System proxy and TUN | Per device | Enable separately on each client’s settings page |
| Auto-update interval | Can differ | Use 1,440 minutes on desktop; set mobile intervals based on usage |
Option 2: Sync YAML configurations through a cloud drive
Cloud-drive sync suits users who maintain custom rules, proxy groups, and DNS settings. A common approach is to place a manually maintained YAML file in OneDrive, iCloud Drive, or another synced folder, then import it into each client. The key is to treat the cloud file as the source file, rather than syncing the entire configuration directory that the client is actively reading and writing.
Why syncing the entire client directory is a bad idea
- Client directories may contain SQLite databases, window state, logs, caches, and lock files, all of which change frequently.
- When two devices are running at once, the cloud service may create a “conflicted copy” while the core continues reading the old file.
- Different operating systems use different path separators, and a Windows drive-letter path cannot be used directly on macOS or Linux.
- A client upgrade may migrate the directory structure, and syncing the old directory directly can write stale state back into the installation.
A safer workflow is to keep shared-base.yaml in the cloud drive, download or copy it locally on each device, and then use the client’s “Profiles” → “Import local file” command. Edit only the source file when changing rules. After confirming that the YAML loads correctly, let the other devices obtain the new version. If the client supports overrides, merges, or scripts, the shared file can contain only rules and proxy groups, while local overrides handle TUN and ports.
Use the client entry point to find the configuration directory
There is no single standard configuration directory across the Clash ecosystem. When mihomo is launched from the command line, the main configuration is commonly ~/.config/mihomo/config.yaml on Linux; older Clash installations commonly use ~/.config/clash/. GUI clients usually have their own application-data directory and subscription database, and the location changes with the app identifier and version.
When locating the directory, start with the button provided by the client, such as Clash Verge Rev 2.x’s “Settings” → “Configuration directory” → “Open directory.” If the interface has no such entry, check the working directory shown at the start of the log or inspect the launch arguments. Do not overwrite a file merely because the directory contains config.yaml; first confirm the actual load path in the log.
Safe operating order for cloud-drive sync
- Quit the client before modifying its configuration so it cannot write to the same file at the same time.
- Wait for the cloud drive to report that syncing is complete before opening the YAML file.
- After saving, check for a conflicted copy such as
shared-base-conflicted-copy.yaml. - Import and reload the configuration on one device, then confirm that proxy groups, rules, and DNS all parse correctly.
- Only then retrieve the version on the other devices, keeping the previous working copy.
Option 3: Self-hosted configuration hosting and remote rule sets
When you have many devices or rules that require ongoing maintenance, split the setup into a main configuration, proxy providers, and rule providers, then host them centrally over HTTPS. Each device stores only a short entry configuration, while mihomo fetches nodes and rules on a schedule. This is better suited than manually copying YAML across desktops, laptops, home servers, and mobile devices.
Centralize nodes with proxy-providers
proxy-providers:
shared:
type: http
url: "https://config.example.net/proxies.yaml"
path: ./providers/shared.yaml
interval: 86400
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600
proxy-groups:
- name: PROXY
type: select
use:
- shared
proxies:
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,PROXYinterval: 86400 means updating every 86,400 seconds, or once every 24 hours. The health check runs every 600 seconds and only determines whether a node can complete the specified test request; it does not represent actual download speed. After the remote file is downloaded, it is written to ./providers/shared.yaml. This relative path is based on the core’s working directory, so make sure the client has write access.
Standardize rules with rule-providers
rule-providers:
private:
type: http
behavior: domain
format: yaml
path: ./rules/private.yaml
url: "https://config.example.net/rules/private.yaml"
interval: 86400
rules:
- RULE-SET,private,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYbehavior: domain is suitable for domain-based rules. If the file contains CIDR ranges, use a behavior type that matches its contents. When mixing multiple Clash rule syntaxes, use classical where supported by mihomo. A mismatch between the behavior type and file contents causes rule loading to fail; the log usually shows the provider name and the location of the parsing error.
Details to handle when hosting files remotely
- The server should provide HTTPS and return valid YAML text.
- If a private URL requires an access token, restrict the token’s permissions and lifetime.
- Keep the previous version before updating the main configuration, so one syntax error does not affect every device.
- Use stable URLs for rule sets so the file address does not change with every commit.
- After a remote file is updated, the client may still require a “Reload” action before the new proxy-group structure takes effect.
Cross-platform field differences: what must stay local
Whether a shared configuration works across platforms depends on whether it contains system-specific fields. Rule syntax, proxy groups, and remote providers are generally easy to reuse; interfaces, processes, ports, and local paths require device-by-device review. Using the mihomo core does not mean every GUI client supports the same interface options; a client may generate the final configuration through override files.
TUN mode and interface settings
TUN creates a virtual network interface and takes over routing. Windows, macOS, Linux, and Android use different permission models, so GUI clients generally require authorization on each device. A shared file can keep the base structure, but environment-dependent fields such as interface-name, device, and route-address-set should not be hard-coded.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53auto-detect-interface: true reduces problems caused by fixed interface names, but you still need to check the default route when two network adapters, a virtual machine, or a corporate VPN are running together. If enabling TUN cuts off the network on one device, first disable it under “Settings” → “TUN mode,” then inspect routing and permission errors in the log. Do not immediately modify the shared rules.
Listen ports and LAN access
mixed-port: 7890
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9090mixed-port: 7890 accepts both HTTP and SOCKS proxy connections. If the port is occupied by another program on one device, change it locally to 7891. If external-controller is used only by the local client, bind it to 127.0.0.1:9090. For LAN sharing, enable allow-lan only when needed, and check the system firewall and Wi-Fi network profile.
Local paths and rule resources
A Windows path may look like C:\Users\Public\Clash\rules, while macOS and Linux use paths beginning with /. For cross-platform setups, use relative paths for rule providers whenever possible, such as ./rules/private.yaml. If the client’s working directory is protected, also confirm that the current user can create the rules and providers subdirectories.
System differences in process rules
PROCESS-NAME depends on the process name reported by the operating system. Windows may match example.exe, while the executable behind a macOS app may be named Example; Android may match by package name. For precise process routing, keep separate rule sets for each platform and reference them from the local configuration.
Recommended structure: shared base configuration with local overrides
For environments using Windows, macOS, and Linux together, maintain one shared base configuration and a short override for each platform. Put proxy providers, rule providers, proxy groups, and shared DNS logic in the base. Let the override files handle ports, TUN, process rules, and the controller address.
Example file layout
clash-config/
├── shared-base.yaml
├── overlays/
│ ├── windows.yaml
│ ├── macos.yaml
│ └── linux.yaml
├── rules/
│ ├── direct.yaml
│ └── reject.yaml
└── backups/
└── shared-base-2026-08-04.yamlWhether overrides can be merged directly depends on the client. Some clients provide Merge, Mixin, override, or script entry points; others can only import the final YAML. If automatic merging is unavailable, generate a final file on a computer, such as windows-final.yaml, and import it on the corresponding device. After merging, check the result for duplicate-key overrides, especially in lists or nested objects such as rules, dns, and proxy-groups.
Do not standardize the currently selected node
Home broadband, office networks, and mobile networks have different routing conditions. The same node might have 42 ms latency on a Windows desktop but 180 ms on a phone using cellular data. Each device should keep its own proxy-group selection, or use automatic strategies such as url-test and fallback. Share the candidate nodes and test rules, not necessarily the last selected node.
Backups, rollbacks, and conflict handling
Configuration sync is not a substitute for backups. Syncing also propagates deletions, bad indentation, and broken rules to other devices; backups preserve versions that can be restored. Keep at least the current working configuration, the version from before the latest change, and one stable version that has been validated over time.
Four checks to run before every change
- Copy the current file and name it with the date, for example
config-2026-08-04.yaml. - Confirm that the YAML uses spaces for indentation and contains no tab characters.
- Check that every provider, node name, and proxy group referenced by the proxy groups exists.
- After reloading, check the logs to confirm that rules, proxy-providers, and rule-providers all loaded successfully.
If every device starts having problems after an update, first pause cloud syncing or remote publishing so the bad version cannot spread further. Restore the previous stable file, disable automatic updates once, and reload the core. After basic connectivity returns, add the changes back section by section to determine whether DNS, rules, proxy groups, or a remote resource caused the failure.
Order for resolving common conflicts
- Two copies with the same name appear: Compare modification times and contents instead of judging which is newer from the filename alone.
- The client reports a YAML error: Starting at the line number shown in the log, check indentation and quotation marks above it.
- Rules updated but behavior did not change: Confirm that the active configuration was reloaded and check the rule-matching order.
- One device loses network access: Disable TUN and the system proxy on that device first, then verify the shared configuration itself.
- A remote provider fails to download: Check the HTTPS URL, access permissions, DNS, and local cache path.
How to choose among the three options
| Use case | Recommended option | Main maintenance concern |
|---|---|---|
| Two or three personal devices that only need the same nodes | One shared subscription URL | Update and select nodes independently on each device |
| Custom rules with infrequent changes | Cloud-synced source YAML | Avoid syncing client databases and caches |
| Many devices with rules maintained over time | Self-hosted HTTPS hosting | Version control, permissions, and rollbacks |
| Windows, macOS, and Linux together | Shared base configuration with platform overrides | TUN, ports, paths, and process rules |
For most personal setups, start with one subscription URL. Introduce a cloud-based source file only when you need to maintain your own rules, DNS, or proxy groups. As the number of devices grows, split nodes and rules into providers that update on a schedule over HTTPS. Whichever option you choose, keep system-specific settings local and retain a stable configuration that can be rolled back directly.
After syncing, check four results on each device: the subscription timestamp is correct, the active configuration has switched, rule matches behave as expected, and TUN or the system proxy can be disabled and restored normally. Verifying these separately makes configuration differences easier to find than simply checking whether a webpage opens.