ai-proxy-rules: daily-updated routing rules for AI services in Clash, sing-box and Surge

The rule sets are grouped four ways, and the names tell you how

The subscription table is the clearest way to understand what this project publishes. There are four selection axes. By scope, there is all for everything, global for overseas services, and cn for Chinese services. By purpose, there is coding for programming tools, model for models and APIs, and media for image, video and audio generation, each of which includes both Chinese and overseas services. By region and purpose combined, the purpose name is prefixed with global- or cn-, so global-coding means overseas programming tools and cn-coding means Chinese programming tools. By individual service, each provider has its own name, such as openai or anthropic, with the full list in the supported services section. The suffix of the file also changes with the client, so the same rule set exists as a Clash yaml, a sing-box json, and a list format for Surge, Shadowrocket, Loon, Stash and Quantumult X, plus an Egern yaml. The set of clients covered is broad enough that the project is not tied to one proxy application, which matters because the rule file format is otherwise a per-client incompatibility.

Subscription URLs are static, so you can point a client at them once

The subscription addresses for the global rule set are given as plain text, one per client, all served from a CDN with the branch pinned in the path:

https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/clash/global.yaml
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/sing-box/global.json
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/surge/global.list
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/shadowrocket/global.list
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/loon/global.list
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/stash/global.list
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/quantumult-x/global.list
https://cdn.jsdelivr.net/gh/VPSDance/ai-proxy-rules@main/rules/egern/global.yaml

Getting a different rule set means replacing global in the address with the name from the table and keeping the file suffix. The Anthropic and Claude Clash address is given as the worked example, with the path rules/clash/anthropic.yaml. You add the address to your client's rule subscription, rule-set or rule-provider list, and when you reference it from a rule-provider in Clash or Mihomo the documentation asks you to set behavior: classical. One practical note is worth keeping: the README suggests substituting cdn.jsdelivr.net with testingcf.jsdelivr.net, fastly.jsdelivr.net or cdn.jsdmirror.com when the default CDN is unstable inside mainland China, which is a real failure mode for a daily-updated subscription.

Rule order decides the winner, and a specific provider must come first

The routing behaviour is not in the rule set, it is in your own configuration, and the README explains the rule order that the clients apply. Rules are matched from top to bottom and stop at the first hit, so to give OpenAI its own policy the openai rule set must be written before the global or all set that contains it. The documented example sets OpenAI to a United States node, sends Chinese AI services direct, and sends the remaining overseas AI services to a general proxy. The comment on each line of that example names the policy, and the README notes that the rule-provider entries referenced must already be present in your configuration, and that the policy names in the example are placeholders to be replaced with your real ones. The practical consequence is that subscribing to the global rule set alone gives you a single undifferentiated treatment of every AI domain. Getting separate policies for OpenAI, for Chinese services and for everything else requires three subscriptions and a deliberate ordering in your config file.

The provider list is curated and split by region, with a wide tail of services

The supported services list is long and it is the substance of what the project maintains. The overseas set starts with the large model providers, each tagged with the purposes it belongs to, including OpenAI and ChatGPT, Anthropic and Claude, Google AI with Gemini, AI Studio, NotebookLM and Antigravity, xAI and Grok, Meta AI and Llama, Mistral AI and Le Chat, Cohere, LMArena, Hugging Face, Groq, OpenRouter, Together AI, Fireworks AI, Novita AI, Replicate, DeepInfra, Cerebras, Chutes, Cloudflare AI, H2O.ai, Ollama and LM Studio. The coding set is dominated by editors and coding agents, including GitHub Copilot, Cursor, Zed, Windsurf and Codeium, JetBrains AI with Grazie, Augment Code, Command Code, OpenCode, Cline, Kilo, Qoder, Factory, Sourcegraph with Amp and Cody, Tabnine, Replit, Amazon Q Developer, Kiro, Devin, v0, Bolt.new, Lovable, Continue, CodeRabbit, Manus, Dify, LangChain and CrewAI, plus ByteDance tools such as Trae, Coze, MarsCode and Cici. The media set covers image and video generators such as Midjourney, Stability AI, Black Forest Labs with FLUX, Ideogram, Adobe Firefly, Leonardo AI, Recraft, Lovart, OpenArt, ClipDrop, ComfyUI, Civitai, Suno, Udio, Runway, Pika, Luma AI, HeyGen, Synthesia and Descript. The Chinese set is smaller and includes DeepSeek, MiniMax, Moonshot AI with Kimi, StepFun, Zhipu AI with GLM, SiliconFlow, PPIO, Alibaba Cloud Model Studio with Qwen, ModelScope, Baidu Qianfan with ERNIE, Tencent Hunyuan with Yuanbao and Yuanqi, Volcengine Ark with Doubao, the China variant of ByteDance tools, and Xiaomi AI with MiMo.

A source list, generated provider data and a cache fallback make up the pipeline

The repository layout describes the data flow. The data/sources directory holds manually maintained source configuration, data/providers holds the provider data generated from those sources, data/cache holds upstream response caches used as a fallback when an upstream fails, scripts holds the sync and generation scripts, and rules holds the automatically generated rule files. The distinction between data/sources and data/providers is the important one for anyone thinking of contributing. Sources are curated by hand, providers are derived, so a new upstream feed becomes a source entry rather than a new hand-written provider. The cache is the resilience piece, since an upstream outage degrades to a cached response rather than an empty or broken rule set. The scripts are TypeScript, and the root also holds a custom/ directory, tests/, a STATUS.md file, a CONTRIBUTING.md file and a tsconfig.json.

The scripts are a small TypeScript CLI with a guard and a status command

The package.json shows the tooling, and it is a pnpm project with the package manager pinned to [email protected] and the package marked private. The runtime dependencies are small and specific: cheerio for parsing upstream HTML, commander for the command line, yaml for writing rule files, and zod for validating data. Everything runs through tsx, so the scripts are TypeScript executed directly. The commands map onto the pipeline. sync runs scripts/sync.ts to pull the upstreams, and generate runs scripts/cli.ts generate to write the rule files. To work on the rules yourself, install the dependencies first:

pnpm install

Then refresh the upstream data and write the rule files:

pnpm sync
pnpm generate

And verify the result with the type check and the test suite:

pnpm check
pnpm test

Two commands exist purely for verification. check runs tsc with no emit, and test runs vitest. There are also check:metadata, which runs scripts/check-metadata.ts, and check:readme, which runs scripts/check-readme.ts, and the latter is a good clue about how the project stays consistent, since the provider list in the README is marked with a provider-list start and end pair that a script can verify against the generated data. A guard target runs scripts/guard.ts, and status runs scripts/status.ts. The diff-summary script produces a diff summary between runs, which is how a change in an upstream list becomes visible.

Daily automation runs in GitHub Actions, with the cache covering upstream outages

Freshness is the promise, and the badges and workflows carry it. The README has a daily sync badge pointing at the generate workflow on the main branch, a providers badge counting the yaml files in data/sources, and a last update badge. The maintenance section documents the local workflow, which is short enough to read in one go. Installing dependencies is pnpm install, generating the rules is pnpm sync followed by pnpm generate, and verification is pnpm check followed by pnpm test. The last line of the README states that GitHub Actions runs the sync, check and generation automatically when the files affecting rule generation change, and the workflow name in the badge is generate.yml. The repository publishes no GitHub releases, so the artefact to consume is the rules directory on the main branch, served through the CDN, not a tagged version. That is the right shape for a rules feed that changes daily, but it also means a change in the upstream lists reaches your client without a version marker or a changelog, so the cache directory and the check scripts are what stand between you and a bad upstream day.

Editorial conclusion

ai-proxy-rules suits anyone whose proxy client needs to route a growing list of AI services to different exits, and who would rather subscribe to a maintained domain list than hand-maintain one. It is the wrong choice if you route by IP or by process, and it is the wrong choice if you expect a single subscription to decide policy, because the rule sets only classify domains and the ordering in your own configuration decides which policy applies. Verify first that the provider names you need exist in the supported services list, that the ruleset you reference is placed above the broader global or all set in your config, and that the cache fallback covers you when an upstream source is down.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. VPSDance/ai-proxy-rules on GitHub