FlClash local provider nodes missing?

If the proxy groups remain after importing a configuration into FlClash but a local provider has no nodes, or startup or refresh logs report a missing rule file, first check whether that provider uses type: file. A failed remote type: http download, an empty subscription from your provider, and a YAML parsing error should not automatically be treated as the same problem.

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.

This guide covers cases where the original file exists and its contents are trusted, but the runtime configuration generated by FlClash may point to a different file. inline is a temporary recovery option for small, readable lists. It is not proof of a client fix and does not guarantee a solution to filtering, proxy protocol, or network problems.

In FlClash v0.8.98, lib/common/task.dart calls confineProviders while generating the runtime configuration, processing proxy-providers and rule-providers separately.

The function skips type: inline and resets path for the other mappings. The generated path uses the Profile, provider category, name, and related information rather than simply passing through 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.

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.

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.

After 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.

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.

Entries 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.

These steps are based on Mihomo's provider formats and the FlClash code that skips inline, not on a verified rule recovery result in #2448. If you cannot confirm the rule type, conversion source, or references, preserve the evidence and roll back rather than assuming that switching to inline will always work.

First confirm that the selected configuration is the copy you just validated, not a Profile that still references the old file. Inspect the provider and proxy group, compare node counts and names, and rule out filter, exclude-filter, or proxy group references excluding 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.

Finally, fully exit and restart the client. Confirm that the same Profile, nodes, and rules still work and that the corresponding missing-file errors no longer appear in the logs. If nodes appear but requests fail, check protocols, credentials, and the network. If access returns but the wrong rules match, check the main rules order and behavior instead of continuing to blame every problem on the file path.

If the copy fails validation, a node protocol is unsupported, or rule matching gets worse, stop using that copy and restore the main configuration and external files saved beforehand. If the original configuration already had the path problem, restoring it preserves the evidence but does not mean connectivity will return. Temporarily use another complete Profile that you have verified works.

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 issues, commits, and Releases to determine whether a fix has been published. The reporter's version description in an Open issue, a workaround inferred from source code, or nodes reappearing is not a confirmed client fix. After upgrading, test again with the same configuration and verification checklist.