macOS Clash Client Permissions: Network Extensions and Keychain Prompts

What rule providers do—and what they don’t

A Mihomo rule provider is a reusable source of routing rules. Instead of copying a long list of domains into the main rules section, you define a provider once, then reference it with a RULE-SET rule. This is useful when you want to route AI services such as ChatGPT and Claude separately from developer services such as GitHub and npm, or when you need to update a domain list without editing the rest of your configuration.

A provider supplies match conditions; it does not supply proxy nodes, choose a node by itself, or create a policy group. The final route still depends on the policy named in the matching RULE-SET rule. That policy must exist in your configuration, and its selected node or outbound determines where the connection goes.

These layers matter when troubleshooting. A correctly loaded provider cannot route a browser request that never reaches Mihomo, and a matching rule can still send traffic to an unexpected destination if its policy group is set to a different node or to DIRECT.

Choose a provider behavior that fits the list

The behavior field tells Mihomo how to interpret the provider’s contents. Choose it to match the entries in the file; a file containing domain names is not interchangeable with a classical rule list just because both are YAML.

For AI and developer websites, domain is usually the simplest starting point. It keeps the list readable and avoids adding IP ranges that may change or be shared by unrelated services. Use classical when a provider needs different rule types, such as both a domain match and an IP-CIDR match. For IP-based rules, make sure the provider’s entries and the relevant DNS behavior suit your configuration; a domain provider does not magically identify every IP address used by a service.

Create local AI and developer domain lists

A local provider is a practical first version: it avoids relying on an external rules URL while you check the syntax and policy flow. Create a directory such as ruleset beside the active YAML configuration, then save the following files there. These are examples to review and adapt, not an exhaustive list of every endpoint used by each service.

AI service provider file

# ruleset/ai.yaml
payload:
  - "+.openai.com"
  - "+.chatgpt.com"
  - "+.oaistatic.com"
  - "+.oaiusercontent.com"
  - "+.anthropic.com"
  - "+.claude.ai"
  - "+.claudeusercontent.com"

The +.example.com form is a domain suffix pattern for the named domain and its subdomains. Keep domains that you have confirmed your applications use. A company may operate several hostnames, and product endpoints can change; a successful match on the main website does not prove that every API, login, or file-download request uses the same hostname.

Developer tools provider file

# ruleset/dev.yaml
payload:
  - "+.github.com"
  - "+.githubusercontent.com"
  - "+.githubassets.com"
  - "+.npmjs.com"
  - "+.npmjs.org"
  - "+.yarnpkg.com"

Package managers and command-line tools may contact registry, authentication, or content-delivery hosts in addition to the website opened in a browser. If a particular install or API request still uses the wrong route, inspect its destination in the client’s connection list or logs, then add only the missing domain after confirming that it belongs to the service. Avoid placing a broad domain such as +.cloudfront.net in a provider simply because one request used it; that suffix can cover many unrelated sites.

For entries that need rule types beyond domain matching, use a classical provider instead. For example, a classical list can contain DOMAIN-SUFFIX,example.com entries and other supported rule types. Its file format and the provider’s declared behavior must agree. Do not paste a classical rule line into a domain provider and expect Mihomo to interpret it as a domain name.

Declare providers and connect them to policy groups

Add provider declarations and routing rules to the active configuration. The following is an insertion example, not a complete subscription: preserve your existing top-level settings and merge these keys into them. YAML does not allow a second copy of a top-level key such as rule-providers or rules to safely replace the first one.

rule-providers:
  ai-sites:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/ai.yaml
  dev-sites:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/dev.yaml

rules:
  - RULE-SET,ai-sites,AI
  - RULE-SET,dev-sites,Dev
  # Keep your existing specific rules above the final fallback.
  - MATCH,Proxy

The paths are relative to the configuration file in this example. If your client stores or generates the active configuration in another directory, check where that file is loaded from and adjust the paths accordingly. A provider path that works in a local test may fail after moving the configuration or importing it into another client.

The names AI, Dev, and Proxy must match policies that already exist in the configuration. If your groups are named AI Services or Developer, use those exact names in the RULE-SET entries. If you want separate choices, add corresponding groups to the existing proxy-groups list, using proxies or groups that are actually defined in your configuration. Do not paste a second proxy-groups: block over a subscription’s existing one.

In rule mode, Mihomo checks rules in order and uses the policy of the first matching rule. Put the provider rules before broad rules that would already match the same traffic, especially a final MATCH. More specific exceptions can go above the provider rules. For example, if a particular internal developer host should stay direct, place its direct rule before RULE-SET,dev-sites,Dev. Later rules will not override a match that has already routed the connection.

Use remote providers and set a sensible update interval

A remote provider is useful when you maintain a list at a stable HTTPS URL or receive a maintained rules file from a source you trust. Replace the local provider declaration with an HTTP provider declaration; keep its behavior aligned with the hosted file. The URL below is deliberately a placeholder, not a working rules service.

rule-providers:
  ai-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://rules.example.invalid/ai.yaml"
    path: ./ruleset/ai.yaml
    interval: 86400

Here, interval: 86400 requests an update every 86,400 seconds, or 24 hours. Choose an interval based on how often the list changes and how reliably the host serves it. Very short intervals can create unnecessary requests or trigger rate limits; a long interval means updates may take longer to reach the client. The path identifies the local copy used by Mihomo, while url identifies the remote source.

Use a direct, stable file URL that returns the rules file itself, not a web page, sign-in screen, or temporary download page. Confirm that the response format matches the declared behavior and format. A remote provider is also a routing input: a bad or compromised list can send traffic through an unintended policy. Review the source, use HTTPS, and do not assume that a successful HTTP response means the returned content is valid or trustworthy.

In a GUI client, updating a subscription and updating a rule provider may be separate operations. After changing provider settings, reload or apply the active configuration using the client’s controls, then check its core logs for provider download, parse, and update errors. Menu labels differ between clients and versions, so look for the active profile’s configuration reload and the core’s log or provider status rather than assuming a subscription refresh always updates every provider.

Verify matches and troubleshoot misrouted traffic

Test one request at a time. First confirm that the configuration reloads without YAML or provider errors. Then open a known AI or developer destination while the client is running and inspect the connection list or logs. Check the destination domain, the matched rule or rule provider, and the selected policy. If the client shows only a final policy, use the core log level and available connection details to distinguish a provider match from a later fallback.

1. Check the active profile: Confirm that you edited the configuration currently selected by the client, not an exported copy or an inactive profile.
2. Validate YAML structure: Check indentation, colons, quotes, and list markers. YAML indentation uses spaces; tabs can cause parsing errors.
3. Check provider loading: Confirm the local file exists at the configured path, or inspect the remote request status and response. A file that returns HTML is not a valid YAML rules list.
4. Check behavior and content: A domain provider needs domain entries; a classical provider needs rule entries. Ensure the provider declaration matches the file.
5. Check ordering and policy names: Move the provider rule above any broad rule that would match first, and verify the target group’s exact name and current selection.
6. Check traffic capture: Make sure the application uses the system proxy or that TUN captures its traffic. Some command-line tools have their own proxy settings and may bypass the system proxy.

A browser may open a homepage successfully while a package install still fails. The browser and package manager can use different proxy settings, DNS behavior, or destination hosts. For npm, test the actual registry request used by your project rather than assuming that a browser visit to the npm website exercises the same connection. For Git operations, distinguish an HTTPS connection from SSH: an SSH remote may use a different hostname and port than the website.

When only one service is misrouted, add the observed destination domain to the appropriate provider and reload the configuration. When many unrelated sites are affected, look for an overly broad domain, a policy group selecting the wrong outbound, or an earlier rule that captures traffic. If the expected provider does not appear in logs, verify that the active core supports the configuration fields you used and that the provider loaded successfully before changing DNS or adding speculative IP ranges.

Maintain custom lists without breaking subscriptions

Keep a backup of the working configuration before changing rules, and make one change at a time. If a client regenerates configuration from a subscription, direct edits to that generated file may be overwritten during an update. Use the client’s supported override or merge mechanism when available, or keep your custom provider files in a stable location and confirm that the active configuration still references them after a subscription refresh.

Review the list periodically. Remove domains that are no longer needed, check that newly added entries belong to the intended service, and avoid adding complete CDN or cloud-provider suffixes to fix one endpoint. A small, explainable provider is easier to audit than a large list assembled from unverified examples. Record which applications need each policy and test both a normal site and a destination expected to match after every update.

Rule providers make routing lists reusable, but they do not remove the need to understand rule order, policy groups, or traffic capture. Start with local domain providers for AI and developer destinations, connect each to an existing policy, place the rules before broad fallbacks, and verify the matched route in the active client. Once that works reliably, consider remote updates only when you have a trustworthy source and a clear maintenance reason.