REJECT is an outbound like DIRECT or a proxy group: matched connections are refused. Point ad and tracker domains at REJECT and you get system-wide ad blocking - effective for every app that goes through Clash, not just the browser.

Wiring up a blocklist

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://cdn.example.com/reject-list.txt"   # your chosen source
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  # ... the rest of your rules

Popular sources include anti-AD and the Loyalsoldier reject list. Blocking rules must precede direct/proxy rules, or broad rules like "domestic direct" will wave the ad domains through first.

What network-layer blocking can and cannot do

  • Can block: ads served from dedicated domains, in-app ad SDK requests, tracking beacons.
  • Cannot block: ads delivered from the same domain and URL as the content (e.g. some pre-roll video ads) - indistinguishable at the network layer; element-level filtering needs a browser extension.
  • In practice the combination "Clash REJECT + browser extension" works best; they don't conflict.

Diagnosing false positives

When a site breaks or images vanish, suspect the blocklist:

  1. Filter the Connections page by the site's domains and look for chains showing REJECT.
  2. Confirmed? Insert an allow rule above the blocking rule: DOMAIN-SUFFIX,broken-domain.com,DIRECT.
  3. When unsure, temporarily comment out the RULE-SET line and compare.
Tip: the more aggressive the list, the more false positives. Start with a well-reviewed conservative list and escalate only after it proves stable.