On this page
If an old configuration stops loading after a core upgrade, do not rush to change nodes. The new version may reject an asterisk in a domain list. Replacing it with a broader suffix can pass validation while changing what actually matches. Identify the intended hosts or subdomains, correct the source that generates the list, then check both configuration validity and real resolution against the original purpose.
invalid domain after updating to v1.19.30
Check the version actually running and the first error. If the same configuration starts on Mihomo v1.19.29 or earlier but exits on v1.19.30 with Parse config error: invalid domain, inspect the domain patterns described in the next paragraph.
Official issue #3116 recorded the change in a Linux Docker environment and traced it to domain patterns in sniffer.skip-domain and dns.fake-ip-filter. v1.19.30 includes stricter validation of Clash-style domain wildcards. This is not a failed node and cannot be bypassed by switching the proxy mode to Direct.
Invalid YAML, unsupported field, proxy not found, or a core that starts but cannot open webpages indicates another stage of failure. Investigate the reported error rather than applying the wildcard forms below to every configuration failure.
Where to investigate different errors
| Log or symptom | More likely stage | Action to take |
|---|---|---|
| Parse config error: invalid domain | Domain-pattern validation | Applies when it appears after upgrading to v1.19.30 |
| Invalid YAML or indentation error | YAML structure | Does not apply; fix the syntax first |
| proxy / group not found | Policy-group or rule reference | Does not apply; restore the missing reference first |
| The core starts, but only one domain fails | DNS, rules, or network | Does not apply; inspect connection records first |
Keep the configuration, overrides, and conversion templates
If the old core is still forwarding traffic, do not restart the service or refresh the subscription repeatedly. Preserve the working state first, then copy the error log, client version, and actual Mihomo version. Remove the subscription token, node passwords, controller secret, and private domains from screenshots and configuration copies.
Keep the configuration and old core needed for recovery
Record the actual core version
Confirm on the client's About page, in the startup log, or with mihomo -v that v1.19.30 is running; do not substitute “latest” for the version number.
Export the final configuration
Save the final configuration, Profile, Merge or overrides, and subscription conversion templates. Keeping only config.yaml from the runtime directory is not enough: a subscription update may write the invalid pattern back.
Keep the previous core release
Keep only the v1.19.29 file from the official Release that has already been verified on this machine as a temporary fallback.
Hold other variables constant
Do not change the subscription, node, DNS mode, or TUN setting at the same time during troubleshooting; avoid introducing a second failure.
Locate the first invalid domain pattern
Test the final configuration first with the v1.19.30 build you intend to run. The command used in the official issue is mihomo -t -f. A successful test only means the current core can parse and initialize the configuration; it does not start the proxy or prove that nodes work.
The stable v1.19.30 release may report only the generic invalid domain error. Search the final YAML and any referenced local files for asterisks, starting with sniffer.skip-domain and dns.fake-ip-filter, which the issue confirmed as problematic. Retest after each correction so the core can point to the next error.
mihomo -v
mihomo -t -f /path/to/config.yamlgrep -R -n '\*' /path/to/config.yaml /path/to/rules 2>/dev/nullrrn-sw-*, a*.example.com, or *a.example.com
The asterisk is mixed into the same label, a pattern that v1.19.30 explicitly rejects.
*.example.com or time.*.com
The asterisk occupies an entire label, so the form itself is valid; continue to the next item.
example.com., a..example.com, or leading or trailing spaces
Strict validation also rejects a trailing dot, an empty label, and leading or trailing whitespace.
No asterisk can be found
Check for plus signs, trailing dots, empty labels, and the final configuration generated by the client; do not search only the original subscription.
What do asterisks, plus signs, and dot prefixes match?
Mihomo documentation calls this Clash-style domain wildcard syntax and explicitly notes that it differs from DOMAIN-WILDCARD in routing rules. Do not copy a seemingly similar asterisk expression from a routing tutorial directly into fake-ip-filter or skip-domain.
The key is not whether the asterisk comes first or last; it must occupy an entire dot-delimited label. time.*.com is valid because the middle label contains only the asterisk. rrn-sw-* is invalid because the asterisk and rrn-sw- share the same label.
Choose syntax based on the intended match scope
| Valid syntax | Match scope | Does not match |
|---|---|---|
| *.example.com | Exactly one subdomain level, such as a.example.com | example.com、b.a.example.com |
| +.example.com | The root domain and subdomains at any depth | Other suffixes |
| .example.com | Subdomains at any depth | The example.com root domain |
| time.*.com | Exactly one complete label in the middle | time.com、time.a.b.com |
| * | A single-label hostname with no dot | A fully qualified domain name containing dots |
rrn-sw-*
a*.example.com
*a.example.com
a*b.example.comMatch subdomains or a list of hostnames? Choose valid syntax for the task
If the intent is to match one or more subdomain levels under a fixed root domain, choose among the asterisk, plus sign, and dot-prefix forms. If the original intent is to match a group of LAN hosts beginning with rrn-sw-, Clash-style domain lists have no partial-label wildcard equivalent to rrn-sw-*; explicitly list the real hostnames instead.
Do not mechanically change rrn-sw-* to *.rrn-sw, rrn-sw.*, or +.rrn-sw. They describe different label structures and may pass validation without matching the intended hosts. List the actual queried names first, then make every configuration entry explainable in terms of its coverage.
sniffer:
skip-domain:
- "rrn-sw-01"
- "rrn-sw-02"
dns:
fake-ip-filter:
- "+.example.com"
- "time.*.com"Invalid patterns and actionable remedies
| Original intent | Do not change it this way | Actionable remedy |
|---|---|---|
| Match short hostnames beginning with rrn-sw- | Keep using rrn-sw-* | List the actual hostnames, such as rrn-sw-01 and rrn-sw-02 |
| Match one subdomain level under example.com | a*.example.com | Use *.example.com |
| Match the root domain and all subdomains | *example.com | Use +.example.com |
| Match all subdomains but not the root domain | Use *.example.com and assume it includes multiple levels | Use .example.com |
Validate the fix with the same v1.19.30
After the configuration passes its test, check actual matching. Visit a domain that should match fake-ip-filter, one sniffer should skip, and an ordinary public domain, then inspect DNS results and connection records. Passing validation with the wrong matching scope does not complete the fix.
Keep a backup, then test and activate the corrected configuration
Test the candidate copy
Run mihomo -t -f until v1.19.30 explicitly reports that the configuration test passed.
Save the original before replacing it
Keep the previous working YAML; do not overwrite the only original while the client is running.
Reload or restart the core
Confirm that the log shows v1.19.30 has started and is not still reading an old process or configuration.
Retest real matching behavior
Use known domain requests to check DNS, sniffing, rule matches, and final page access.
Completion criteria
- One-level, any-depth, and root-domain matching scopes agree with the selected syntax
- Ordinary public domains and node connections are not harmed by the broadened rules
- The original configuration, generation source, and old-core fallback file remain available
invalid domain returns: check the subscription, conversion template, and overrides
If a manual correction lets the core start, but the same error returns after updating the subscription, switching Profile, or restarting the client, the invalid pattern comes from a conversion template, remote configuration, Merge, or an override. Do not repeatedly edit the temporary runtime configuration file. Compare the final YAML before and after the fix to find which template or setting writes the old value back.
If you control the subscription or converter, fix the template and regenerate it. If you control only the client, replace the complete list in a managed Merge or override, then confirm that the final configuration remains valid after an update. Do not upload a subscription containing a token to an unfamiliar converter site, and do not use one overly broad suffix to cover every unknown case.
The error returns after every subscription update
Revise the subscription conversion template or upstream configuration, then generate a new candidate.
The error returns after switching Profile
Check the Merge, Script, and local overrides for each Profile separately.
The file on disk is changed, but the core still reports the old value
Confirm the path actually loaded, the running process, and the final configuration generated by the client.
The configuration starts only with a broad suffix
List the required hosts and record any gaps first; do not treat expanded scope as a long-term solution.
Temporarily restore the configuration and old core
If an uncontrollable source keeps generating the configuration and cannot be corrected promptly, disable TUN or the system proxy to restore direct system connectivity, then restore the backed-up configuration. If a workload truly depends on it, temporarily return to the locally verified v1.19.29 and retest v1.19.30 after the generation source is fixed.
A rollback restores service; it does not prove the old syntax is correct. The strict-validation commit in v1.19.30 is already in the current stable release, while the commit that adds a more detailed error path came later. Do not turn “the old version did not report an error” and “a newer Alpha is easier to diagnose” into a permanent version strategy.
Restore a known working state
Stop the failing core retries
Disable client interception first so system traffic does not keep pointing to a local port with no running service.
Restore the configuration backup
Restore the Profile, final YAML, and required overrides; do not import an entire directory from an unknown source.
Temporarily roll back the core if necessary
Use only the official v1.19.29 for the architecture verified on this machine, and record the reason and date of the rollback.
Schedule a retest on the same version
After fixing the generation source, return to v1.19.30 and repeat the configuration test, startup, and real-domain validation.