On this page
Finding the file on disk does not mean the running core is reading the same location. A client may rewrite collection paths while generating configuration, so an empty node list calls for comparing the original file with the actual path being read. Work on a separate copy and preserve both external files and the main configuration, rather than lose the only original while trying to restore the list.
A local Provider file exists: why are the nodes still empty?
Check the Provider (node or rule collection) type: file setting and actual read path in the original configuration, and record whether nodes are empty or a rule file is missing. Remote type: http download failures, empty subscriptions, and YAML format errors require their own checks; they are not local file-path problems.
Issue #2448 in the official repository is a single Windows 10 / 11 user report filed on 2026/9/23. The reporter used v0.8.98 and said they could reproduce the issue starting with v0.8.97. Their reproduction uses a local proxy-provider referenced through a proxy group's use field. The title also mentions rule-providers, but no separate rule provider reproduction was provided.
At the time of this review, the issue is still Open, with no maintainer-confirmed general affected scope or fixed version. This guide therefore does not claim that every installation on v0.8.97 or later, or every macOS or Android installation, must have the same failure. On other platforms, use the checks below only if you find the same configuration and path evidence.
Why can the core miss a file even when the original path is correct?
Save the current main configuration, every external provider file, the client version, and the first error log entry. Do not assume that backing up the in-app Profile also includes external files. Confirm that those files have separate copies, then create a configuration copy for testing.
In the copy, check that the file referenced by the original path exists, is readable by the current user, contains a nonempty list, and has the correct format. If the client can display the actual runtime configuration, compare the path of the provider with the same name. Otherwise, use the actual file location in the logs and record that the runtime configuration was unavailable. Do not guess a fixed cache directory or manually insert files under MD5 filenames.
Mihomo's official documentation also describes HomeDir and safe path restrictions. A rejected path and a path rewritten by FlClash are different pieces of evidence. Do not try your luck by expanding SAFE_PATHS, changing permissions on an entire directory, or disabling safety restrictions. If the original file is missing, restore a trusted copy first. If its contents fail to parse, correct the format first.
In FlClash v0.8.98, lib/common/task.dart calls confineProviders while generating the runtime configuration, processing proxy-providers and rule-providers separately.
This function skips type: inline, whose content is embedded in the main configuration. For other collections it regenerates path from the Profile, collection category and name rather than retaining the original path.
This code enters the legacy cache migration branch only when url is nonempty. A local file provider without url still receives a new path, but that branch does not copy the file from the original path. Source analysis supports the possibility of a mismatch between the original file and the runtime path, consistent with the reporter's explanation. We have not independently reproduced the issue on a real Windows installation and do not present this inference as a maintainer-confirmed conclusion.
The original file exists, but the logs point to a missing file elsewhere
Save the original configuration and a comparison of the paths. For a small, trusted list, try inline in a copy.
The logs point to the original file but report YAML or field errors
Correct the contents and format first; do not immediately attribute the problem to #2448.
The provider has nodes, but the proxy group is empty
Check use, the provider name, filter, and exclude-filter to distinguish reference problems from filtering problems.
A type: http provider receives an error response during an update
Check the remote source and download logs; do not apply the local file recovery steps.
How do you convert a small local node list to inline?
Work only with a small number of YAML nodes from a trusted source that you can read and understand. Open the local proxy provider file, move each node object from its top-level proxies list into payload under the provider with the same name in the main configuration, change it to type: inline, and remove that provider's path, url, and file update interval.
Review any health-check, filtering, or override settings individually and retain them where needed instead of deleting them all.
Keep the original provider name and proxy group use reference. Preserve every node's name, protocol, server, port, password, and TLS fields in full. Do not nest the entire file, including its top-level proxies key, inside payload, and do not paste URI or Base64 text as if it were a node object. If you cannot reliably read or convert the contents, stop editing and use a complete Profile that you have already verified.
The example below shows the structure only. my-local-nodes and Local are example names; server and password are placeholders and cannot be used to connect. Use your own trusted node objects and preserve the provider and proxy group names from your original configuration. Merge the snippet into a configuration copy; do not replace the whole configuration with it.
proxy-providers:
my-local-nodes:
type: inline
payload:
- name: example-node
type: ss
server: example.com
port: 443
cipher: chacha20-ietf-poly1305
password: REPLACE_WITH_YOUR_PASSWORD
proxy-groups:
- name: Local
type: select
use:
- my-local-nodesAfter saving the configuration copy, run the client's configuration validation before selecting and starting it. If validation fails, stop immediately; do not enable TUN to work around the error. Check that payload is a list, indentation is correct, the current core supports the node fields, and use references a provider that still exists.
inline stores the current contents in the main configuration as a static snapshot. Editing the original external file later will not automatically update this payload. Review and maintain the copy whenever an update is needed. This approach suits small, manually maintained lists, not repeatedly copying a large subscription into the main configuration.
Local rule providers need a different conversion
A rule provider's payload contains rule strings, not node objects. First check whether the original behavior is domain, ipcidr, or classical and whether the file format is yaml, text, or mrs. Preserve the original behavior; do not switch between the three types just to make validation pass.
For a small YAML file, move the rule entries from its payload into the inline provider with the same name. For a readable text file, review the actual rules line by line before converting them to a YAML string list. MRS is a different format: do not place its raw bytes or Base64 representation directly into inline. Without a trusted, readable source, preserve the original and use an already verified setup; this guide does not convert large binary rule sets.
The following snippet shows a classical provider. DOMAIN-SUFFIX,example.com inside the provider has no policy target; the target remains specified by RULE-SET,local-rules,Local in the main rules list. Local must already be defined in the complete configuration. Preserve your own provider name, target, and main rule order, and do not add or replace the final MATCH rule.
rule-providers:
local-rules:
type: inline
behavior: classical
payload:
- DOMAIN-SUFFIX,example.com
rules:
- RULE-SET,local-rules,LocalEntries in a domain provider are supported domain expressions; entries in an ipcidr provider are CIDRs. Do not put the example's DOMAIN-SUFFIX line into either of those provider types. A classical provider also cannot contain RULE-SET or SUB-RULE entries. Validate the conversion first, test one small provider, and confirm it works before moving on to the next.
This rule conversion follows the Mihomo documentation and how FlClash handles inline. #2448 has no independent recovery result for rule collections. If behavior, the source or references cannot be confirmed, keep the originals and roll back.
How do you verify the nodes and rules, not just the interface?
Check that the active configuration is the copy just validated; a Profile still referencing old files cannot verify recovery. Node counts and names in the Provider and policy groups must match the original list. Ensure filter, exclude-filter and group references do not exclude every node.
Select a known working node and make a real HTTPS request using your usual system proxy or TUN setup. Check the outbound in the connection records. For a rule provider, use a request to a service you control or normally use that genuinely falls within the provider's scope, then inspect the matched rule and policy. A visible list or a numeric latency result alone does not complete verification.
After fully quitting and restarting the client, the same Profile, nodes and rules should remain valid, with no corresponding missing-file errors. If nodes appear but requests fail, check protocols, credentials and networking. If access works but rules match incorrectly, check the main rules order and behavior.
If conversion fails, return to a verified configuration without wiping data
If the copy fails validation, its node protocols are unsupported, or rule matching gets worse, stop using it and restore the main configuration and external files saved beforehand. If the original configuration already had a path problem, restoring it only preserves the original data; it does not mean connectivity will return. Temporarily use another complete Profile that has been verified to work.
If the configuration still does not work, disable this client's system proxy or TUN, confirm that the device has returned to its previous network state, and save the logs for an upstream report. Do not delete the entire app data directory, all provider caches, or your only local file. Do not upload private nodes to online conversion sites.
When reporting to #2448, include the full client version, operating system version, original provider type and relative path, actual path from the logs, and whether you tried inline in a configuration copy. Redact subscription tokens, passwords, servers, and personal directory names from public copies. Keep the original private evidence locally.
Use only official issue records, commits, and Release information to determine whether a fix has been published. Do not present a reporter’s version description in an Open issue, a workaround found in the source code, or “nodes reappeared” as a confirmed client fix. After upgrading, retest with the same configuration and verification method.
References
- FlClashFlClash local file provider loading failure report #2448
- FlClashRuntime configuration and provider path handling in FlClash v0.8.98
- Mihomo WikiMihomo proxy-providers fields: type, path, and payload
- Mihomo WikiYAML, URI, and Base64 formats for local Mihomo proxy providers
- Mihomo WikiMihomo rule-providers fields: behavior, format, and inline
- Mihomo WikiMihomo classical, domain, and ipcidr rule provider contents
