Security & Privacy · Clash Technical Blog

Are Remote Clash Rule Sets Safe? Checking rule-providers Sources, Updates, and Tampering Risks

Audit rule-providers by source, update history, rollback file, and diffs. They cannot read account passwords directly, but can change which egress a domain uses.

Read the articleBack to blog
  • rule-providers
  • Rule Sets
  • Supply Chain
  • Security
On this page
Published
Updated
Estimated reading time
About 8 minutes

To assess a remote rule set's safety, start with what it can change

rule-providers are only rule files and cannot directly read account passwords, but they can change whether a domain connects directly, uses a proxy, or is rejected. The risk of an unknown, automatically updated rule with no rollback is that sensitive requests may be silently sent through the wrong outbound route.

A Rule Provider helps decide whether a domain is proxied, connected directly, or rejected. One overly broad DOMAIN-SUFFIX rule placed early can suddenly send banking, corporate admin, or intranet sign-in traffic through an unfamiliar node. The risk comes from routing changes; the rule file does not need permission to read passwords.

When the connection log shows an unexpected policy, switch back to the previous cached copy and close old connections before comparing rule files. Put the incident time, Provider name, matched entry, and final outbound route together to distinguish an accidentally included domain, incorrect local order, or replaced remote content.

Trace it to the repository and commit before copying the raw address

Before adding it, you must be able to answer

  • Which public repository and maintainer own this raw file
  • Whether the repository's commit history matches the rule set's stated purpose
  • Whether the downloaded content is YAML/MRS text rather than a sign-in page, script, or shortened-link redirect
  • Whether the current configuration retains the previously downloaded local file
  • Whether you know how to disable only this Provider if something goes wrong

A branch address changes with every commit, making it appropriate for trusted rules that need updates. A commit-hash address is immutable, making it better for low-change, high-impact rules such as banking or corporate direct access. You can use both; not every source needs hourly updates.

Keep the URL, format, local path, and update time visible

Reviewable Rule Provider example
rule-providers:
  research:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml
    path: ./ruleset/research.yaml
    interval: 86400

rules:
  # REPLACE_WITH_POLICY 必须换成当前配置中已经存在的策略组
  - RULE-SET,research,REPLACE_WITH_POLICY
  - MATCH,DIRECT

OWNER, REPO, COMMIT, and REPLACE_WITH_POLICY are placeholders and cannot be enabled as copied. Replace them with a repository you verified, a fixed commit, and an existing policy group.

behavior and format must match the remote content; path must point somewhere the core can write. Place the rule reference before MATCH while keeping it behind higher-priority rules for corporate networks, the local network, and traffic that must connect directly.

After an update succeeds, check the rule count and modification time, then test matches for several familiar domains. An “update complete” message alone does not prove that the running configuration references the new file.

Before an important rule update, use a diff to review what changed

Compare in a terminal you control; replace RULE_URL first
RULE_URL='https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml'
curl -L --fail --show-error -o rules.new.yaml "$RULE_URL"
sha256sum rules.new.yaml
diff -u rules.last.yaml rules.new.yaml | less

On macOS, you can use shasum -a 256 instead of sha256sum. A hash can show only whether two files are identical; it cannot establish that their contents are trustworthy. You still need to review added and removed entries, repository commit notes, and whether the rules match their stated purpose.

If a file suddenly shrinks from thousands of lines to dozens, begins with <!doctype html>, or a video rule adds many account and banking domains at once, pause automatic updates.

If traffic is already taking the wrong policy, roll back the file before addressing accounts

If the problem begins immediately after a Provider update, restore the previous rules and close old connections first. After routing returns to normal, determine whether sensitive requests actually used the wrong outbound route.

Incident response

  1. Stop updates for this Provider

    Switch back to the previous cache or temporarily remove the RULE-SET reference.

  2. Reload the configuration and close connections

    New requests should return to the original policy; existing sessions do not change outbound routes automatically.

  3. Compare repository changes

    Determine whether this is an accidentally included entry, a moved address, a format change, or an unverifiable source.

  4. Inspect sensitive accounts

    If a sign-in request used an unexpected outbound route, review login history and rotate credentials according to the risk.

  5. Use a fixed commit or an alternative source

    Do not re-enable automatic updates for a remote file you cannot explain.

References