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

An automatically updated remote rule file can change where a website’s requests go without you changing a setting. Check more than download success: who maintains it, which domains an update adds, and whether the previous file can be restored. If a sensitive account’s requests take an unexpected route, connection records and rule differences matter more than tidy-looking formatting.

Rule files cannot read passwords, but can change the exit for sensitive requests

Check the Rule Provider (rule-providers) content and the rule order in the configuration, especially DOMAIN-SUFFIX rules near the top. A rule set cannot read account passwords directly, but it helps determine whether connections are direct, proxied, or rejected. Overly broad matches may send banking, company administration, or internal login requests through an unfamiliar node. Check these changes when the source is unknown, updates are automatic, and no rollback is available.

If connection records show an unexpected policy, restore the previous trusted rule file if you have a backup; otherwise, temporarily remove this Provider’s rule reference. Reload the configuration and close old connections. Compare the incident time, Provider name, matched entry, and final exit with repository changes to distinguish an accidentally included domain, incorrect local order, or replaced remote content.

Which repository, maintainer and commit does the raw address belong to?

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
  • The download is the expected YAML text or MRS binary rule file, not a login 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.

How do you set the URL, format, and cache path for rule-providers?

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 to a location the core permits and can write to. Place the rule reference before MATCH, but after 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

In a separate review directory, prepare rules.last.yaml from the previous rule backup you have already checked and trust. rules.new.yaml is the new download awaiting review. Use the actual paths if your names or locations differ, and do not write the candidate directly into the active Provider cache.

Run the commands below one step at a time. Replace RULE_URL with the actual URL pinned to a commit in a trusted repository. Stop if the download fails rather than hashing or comparing a possibly stale file. Without a previous trusted backup, you can review the candidate’s contents, but the absence of a diff does not mean nothing 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.

Unexpected routing after an update: restore trusted rules and close old connections

Incident response

  1. Stop updates for this Provider

    Restore the previous trusted rule file if you have a backup; otherwise, 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