On this page
If a subscription update fails validation while existing connections still work, restarting immediately may lose the last working runtime state. Preserve the original data and error, test the new content separately as a candidate, then restore a working configuration. Upgrading the app can protect later updates, but it will not automatically recover files already overwritten.
The subscription downloads, but Mihomo rejects the new configuration
Record the previously working Profile in Clash Party 2.0, the final configuration after the update, and the complete validation error. In official issue #2047, the new file was downloaded and YAML could be parsed, but Mihomo rejected it, preventing hot reload or restart. Do not treat this as a download timeout.
If the subscription address returns 401, 403, an HTML page, empty content, or Invalid YAML, the failure occurs earlier. Start with the subscription response and YAML syntax. Inspect the updated final configuration only when the download succeeds, the Profile is overwritten, and Mihomo then refuses to load it.
Keep the running configuration while the network still works
After a configuration hot reload fails, the running Mihomo may temporarily continue using the previous working configuration. Do not rush to restart the core, quit the app, or refresh the subscription again. Those actions can discard the old working runtime state without fixing the new file already written to disk.
Preserve the opportunity to recover
Hold the current runtime state
Do not switch Profile, restart the core, or relaunch Clash Party. First confirm whether a webpage still works through the original node.
Save the error and version information
Copy the validation error and record Clash Party, Mihomo, Profile, and the update time. Do not export a complete log containing secrets.
Copy the working backup
Copy the most recently verified Profile into a separate directory and leave the original untouched. If no backup exists, first ask the provider for a corrected configuration.
Stop overwriting
Pause manual refreshes and automatic updates, and note the previous update interval. Do not paste downloaded content back into the current Profile until the candidate passes full validation by the selected core. Do not experiment with your only backup.
A file that opens as YAML is not necessarily runnable by Mihomo
A YAML parser verifies indentation, lists, and key-value structure; it does not prove that every policy-group reference exists. The example below is syntactically valid, but “手动选择” references an undefined policy group, so Mihomo still rejects it during loading.
Clash Party also combines the remote subscription with global overrides, per-Profile overrides, rules, and managed settings to produce the final runtime configuration. A remote file that looks valid alone can develop duplicate names, missing references, or unsupported fields after merging. Validate the final candidate instead of merely opening the YAML.
proxies:
- name: 节点 A
type: socks5
server: 127.0.0.1
port: 1080
proxy-groups:
- name: 手动选择
type: select
proxies:
- 不存在的策略组
rules:
- MATCH,手动选择The error says a proxy group does not exist
Check whether that exact name appears in proxies or proxy-groups, including spaces, capitalization, and full-width characters.
Validation passes after one override is disabled
The issue is in the merged result. Correct the stale group name or field in the override; do not change unrelated nodes.
The original subscription still fails when combined with every override
Give the provider the exact redacted error and ask them to fix the upstream generated configuration.
The same file passes with another core version
Keep both versions and the complete errors, then decide based on the Mihomo version you actually intend to run. A different core cannot substitute for acceptance testing.
Choose the next action from the last meaningful error
| Observed result | Failure stage | Where to start |
|---|---|---|
| 401, 403, timeout, or a returned webpage | The subscription request did not retrieve a configuration | Check the link, authorization, network, and provider status |
| Invalid YAML, indentation, or quote errors | The file has not passed YAML parsing | Fix the format without continuing to overwrite the current Profile |
| YAML is readable, but an error such as proxy group not found appears | Mihomo semantic validation fails | Check references among nodes, policy groups, rules, and overrides |
| The update succeeds, but only one node fails to connect | The configuration loaded; the problem is the node or protocol | Troubleshoot the node, TLS, UDP, or network |
Validate the new subscription separately as a candidate file
Save the candidate configuration in a separate temporary location without overwriting the current Profile. Do not submit links containing a token to online conversion sites.
Command-line users can run Mihomo test mode against the temporary copy. A successful exit means only that this core can parse and initialize the candidate; it does not prove that nodes connect or replace the real-request test that follows. Never rewrite the only original configuration in place.
The mihomo command must use the executable actually selected by the app, not another program with the same name. candidate.yaml must point to a temporary copy that includes the real overrides. Do not run the test until you can confirm both the core and the candidate file locations.
From candidate file to importable configuration
Keep the original remote response
Place this download in a temporary directory and save a separate redacted copy for comparison. Do not put the subscription URL in shell history or a support ticket.
Verify references
Start with the group named in the validation error. Inspect proxies, proxy-groups, rules, and rule-providers, then fix any target that is missing or renamed.
Apply the actual overrides
Include global overrides and this Profile's overrides in the check. If only the merged result fails, fix the override instead of repeatedly downloading the same subscription.
Test with the selected core
Run test mode on the temporary final configuration and save the exit code and error. Proceed to import only after a successful exit.
mihomo -t -f candidate.yaml- Remote subscription candidateWrite only to a temporary file; do not overwrite the current Profile
- Merge rules and overridesGenerate the final configuration Clash Party will actually run
- Selected Mihomo -tCheck group references, fields, and core compatibility
- Save only after successOn failure, clean up the temporary file and preserve the previous working configuration
PR #2048 moves saving until after Mihomo validation. v2.0.0 does not include this protection; v2.0.1 officially does. Upgrading does not automatically restore a Profile that was previously overwritten.
If the core cannot start, restore the previous working Profile
If the core has stopped, disable the system proxy and TUN first and confirm that the operating system can connect directly, so downloads do not keep pointing to an inactive local port. Then import the backed-up working configuration as a new Profile. Keep the damaged Profile only for offline comparison and do not make it current again.
If you have no backup, do not gamble by deleting the entire Clash Party data directory. Ask the subscription provider to correct the configuration, perform semantic validation in a temporary location, and import it under a new name. This preserves the existing overrides, error evidence, and rollback clues.
Recover in rollback-safe order
Restore direct system connectivity
Disable the system proxy and TUN, and confirm that the browser no longer connects to an inactive local proxy port. Record the original settings so you can restore them one at a time.
Import the previous working copy
Create a Profile under a new name. Do not delete the failed configuration or enable automatic updates yet.
Start the core and test one node
Select a known working node, open an ordinary webpage, and confirm in connection records that the request actually entered the new Profile.
Restore automatic updates after verification
Restore the original update interval only after a manual update, reload, and application restart all succeed. Save a new working backup before re-enabling it.
How does validation before saving protect configurations, and why upgrade to v2.0.3 or a later stable release?
Clash Party v2.0.1 was released on 8/11/2026. Its official release notes explicitly list a fix for remote subscription updates that could overwrite a working subscription before validating the new configuration. v2.0.0 does not have that protection.
As of 9/23/2026, the latest official stable release is v2.0.3; it also fixes a problem in which malicious rule-providers configuration could execute arbitrary commands. If you still use an older version, back up your working Profile first, then update from the official Release.
v2.0.1 treats the remote subscription as a candidate, applies managed settings, rules, and overrides, then validates the temporary file with -t mode from the selected Mihomo. If validation fails, it neither replaces the saved Profile nor reloads the core, and then removes the temporary file. This protection applies only to future updates; it cannot recover an old configuration overwritten before the upgrade.
Available options
| Option | Who it suits | Constraints |
|---|---|---|
| Update to v2.0.3 or a later stable release | Users who want validation before updates | Back up the Profile, then use an invalid candidate to confirm a failed update does not overwrite the old configuration; v2.0.3 also fixes the rule-providers security issue |
| You cannot update yet | You need to save your existing Profile first | Pause automatic updates and validate the candidate manually. The older version may still overwrite a working Profile and lacks the security fix in v2.0.3, so update as soon as you can. |
| Downgrade the app | Methods to avoid when restoring a configuration | It cannot restore a Profile that has already been overwritten and would also lose the security fix in v2.0.3 |
Can an invalid subscription overwrite the old configuration, and can a valid one update successfully?
After upgrading to official v2.0.3 or a later stable release, run two updates in a backed-up environment. First use a redacted invalid candidate and confirm Clash Party returns a validation error while the old Profile content, running core, and node connection remain unchanged. Then use a verified valid candidate and confirm saving, reloading, and a real connection all succeed.
An “update complete” message is not enough. An invalid update should preserve the last working configuration, while a valid update should take effect. After quitting and restarting Clash Party, you should still be able to choose policy groups and generate new connection records, and you should also be able to disable and restore the system proxy or TUN normally. The recorded rules and outbound routes should match your expectations.
References
- Clash PartyReport of a remote subscription overwriting a working configuration before semantic validation
- Clash PartyFix validating a candidate with the selected Mihomo core before saving
- Clash PartyHistorical Clash Party v2.0.2 release notes
- Clash PartyClash Party v2.0.3 release notes and rule-providers security fix