8. Providers and Policy Groups#

Providers are responsible for “obtaining nodes or rules in batches”; policy groups are responsible for “selecting one or more exits from multiple nodes”.

Outbound Node Sources#

Source	Configuration	Suitable Scenarios
Static nodes	`proxies`	A small number of fixed nodes, manual configuration
Proxy provider	`proxy-providers`	Subscriptions, files, inline nodes, WARP dynamic nodes
Built-in nodes	`DIRECT`, `REJECT`	Direct connection and rejection

proxy-providers#

HTTP Subscription#

proxy-providers:
  airport:
    type: http
    format: auto
    url: https://example.com/sub.yaml
    path: ./providers/airport.yaml
    interval: 3600
    proxy: DIRECT
    header:
      User-Agent:
        - Link1
    filter: '香港|日本|新加坡'
    exclude-filter: '倍率:10|过期'
    exclude-type: direct
    size-limit: 10485760
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      expected-status: 204

Local File#

proxy-providers:
  local:
    type: file
    path: ./providers/local.yaml
    format: mihomo

Inline Payload#

proxy-providers:
  inline-nodes:
    type: inline
    payload:
      - name: local-socks
        type: socks5
        server: 127.0.0.1
        port: 1080

WARP provider#

proxy-providers:
  warp:
    type: warp
    mode: auto
    transports:
      - wireguard
      - masque

The warp provider materializes WARP exit nodes. Do not write type: warp under proxies.

Why WARP is a provider: the same WARP state may generate two types of outbound nodes, wireguard and masque, and auto mode needs to persist the account, keys, endpoint, and transport state. By placing it in a provider, policy groups can use these materialized results just like subscription nodes, for example use: [warp]. For detailed fields and mechanisms, see Outbound Protocol Configuration: WARP provider.

proxy-provider Fields#

Field	Meaning	Actual Effect
`type`	`http`, `file`, `inline`, `warp`	Determines provider behavior
`format`	`auto`, `mihomo`, `uri`, `base64`, `sip008`, `surge`, `quanx`, `sing-box`	Determines how subscription content is parsed
`path`	Local path	HTTP cache or file read
`url`	Subscription URL	Used by `type=http`
`interval`	Refresh interval, in seconds	Controls automatic refresh
`dialer-proxy` / `proxy`	Exit used to fetch the subscription	Used when the subscription is blocked or is on an intranet
`filter`	Regex for node names to keep	Filters nodes
`exclude-filter`	Regex for node names to exclude	Removes invalid, high-multiplier, or expired nodes
`exclude-type`	Protocol types to exclude	For example, exclude `ssr` or `direct`
`header`	HTTP request headers	Subscription authentication or UA
`size-limit`	Response size limit	Prevents abnormally large subscriptions
`health-check`	Provider-level health check	Establishes probe state for provider nodes
`override`	Batch override node fields	Uniformly sets UDP, certificate verification, prefixes, etc.
`payload`	Inline node list	Used by `type=inline`

provider override#

proxy-providers:
  airport:
    type: http
    url: https://example.com/sub.yaml
    path: ./providers/airport.yaml
    override:
      skip-cert-verify: true
      udp: true
      down: 200 Mbps
      up: 50 Mbps
      dialer-proxy: DIRECT
      interface-name: eth0
      routing-mark: 100
      ip-version: ipv4-prefer
      additional-prefix: '机场 - '
      additional-suffix: ' - 自动'
      proxy-name:
        - pattern: 'United States'
          target: 'US'

Actual effects:

skip-cert-verify: disables TLS certificate verification in bulk. Not recommended to enable by default.

udp: uniformly enables/disables UDP capability.

down / up: overrides protocol bandwidth hints.

dialer-proxy: makes nodes in the provider dial through a specified upstream proxy.

interface-name / routing-mark: binds a network interface or Linux mark.

additional-prefix / additional-suffix: changes node display names in bulk.

proxy-name: replaces node names by regex.

Policy Group Types#

A policy group is not a new outbound protocol. It only answers two questions:

Which member is ultimately selected for this traffic? For example, select, url-test, smart, fallback, load-balance.

Should this traffic pass through multiple members in order? For example, relay.

Policy group members can come from three types of sources:

proxies: explicitly specified nodes or other policy group names.

use: references one or more proxy-providers and adds the nodes produced by the providers to the group.

include-all*: automatically collects all static nodes or provider nodes within a scope.

When loading the configuration, Link1 first resolves members, then deduplicates, filters, and checks for circular references. A group can reference another group, but it cannot form a cycle such as A -> B -> A. Health-checking policy groups expand nested groups to leaf nodes for probing, avoiding probes that only reach the “group” wrapper.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    use:
      - airport
    url: http://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000

Type	Behavior	Suitable Scenarios	Key Notes
`select`	User manually selects one member	Primary exit that needs controllable switching	The selection is a member name; the member can be either a node or a group.
`url-test`	Selects a better member based on probe latency	Automatically choosing the best among multiple nodes in the same region	Mainly relies on health check results.
`smart`	Dynamically ranks members using both health probes and real dialing feedback	Automated primary exit, long-running routers	Does not only look at speed tests; it also learns failure rate, jitter, and real connection behavior.
`fallback`	Selects the first available member in order	Primary/backup links	Member order is priority.
`load-balance`	Distributes connections across multiple members	Balanced use of multiple nodes	`strategy` determines round-robin, hashing, or sticky sessions.
`relay`	Builds a multi-hop chain in order	Upstream proxy, jump chains, chained exits	Member order is the chain order, and compatibility requirements are stricter than normal groups.

If you only want “Link1 to automatically select a good node”, start with smart or url-test; use relay only when you explicitly need “go through A first, connect from A to B, and finally exit from B”.

`select`: Manual Selection#

select is the easiest policy group to understand: it presents multiple members to the user, and the user or App selects the current member. It does not actively run speed tests and will not switch automatically, making it suitable as a top-level entry point.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - SMART
      - JP
      - US
      - DIRECT

Actual effect: when a rule uses PROXY, traffic goes through the member currently selected in PROXY. If the selected member is another group, such as SMART, Link1 continues to apply SMART’s selection logic.

`url-test`: Automatic Selection by Probe Latency#

url-test periodically makes each candidate node access url, records latency and availability, and then selects the item with the lowest latency.

proxy-groups:
  - name: JP-AUTO
    type: url-test
    use: [airport]
    filter: '日本`JP`Tokyo'
    url: http://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50

Field effects:

url should be a lightweight and stable address that represents your real access path.

interval is the probe interval, in seconds. Setting it too short increases node and network load.

timeout is the timeout for a single probe, in milliseconds.

tolerance is the latency tolerance, in milliseconds. It prevents frequent switching caused by 1–2 ms jitter.

lazy: true means probing is deferred until needed as much as possible, which is suitable for subscriptions with many nodes.

`smart`: Health Probes + Real Dialing Feedback#

smart can be understood as an enhanced url-test. It also uses url, interval, timeout, and tolerance to build a basic health ranking, but it does not rely only on speed tests. After real service connections occur, it also records each candidate’s success rate, real dialing time, and jitter, and uses this feedback to fine-tune the ranking.

proxy-groups:
  - name: SMART
    type: smart
    use: [airport]
    filter: '香港`日本`新加坡'
    exclude-filter: '过期`倍率:10'
    url: http://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 80
    lazy: true

How smart works:

Check health status first: healthy nodes rank before unknown nodes; nodes known to be unavailable are not tried first.

Then consider real feedback: successful real connections record latency; failures record failure signals and may trigger a health probe for that node.

Limited concurrent attempts: when dialing, candidates are tried according to the current ranking. Later candidates are only tried in a staggered manner if the previous candidate takes too long to produce a result, avoiding hitting all nodes at once.

Failure gating: if a candidate has recently had an excessive failure rate, it is moved further back.

Limited exploration: during long-term operation, suboptimal candidates are periodically given a chance, preventing recovered nodes from being permanently suppressed by old data.

Manual selection can override: if the App temporarily pins a member, smart uses it first. When it is determined to be unhealthy or dialing fails, the pinned selection is cleared and automatic ranking resumes.

Differences between smart and url-test:

Comparison	`url-test`	`smart`
Decision basis	Mainly the latency and status of the probe URL	Probe results + real dialing success rate/latency/jitter
Failure awareness	Waits for the next probe cycle to discover failures	Service dialing failures immediately become feedback and can trigger a single-node probe
Suitable scenarios	Selecting the lowest latency among homogeneous nodes	Long-running setups, fluctuating node quality, unattended routers
Explainability	Simple and easy to predict	Smarter, but short-term ranking changes with real connection feedback

Tuning suggestions:

Home router or desktop primary exit: type: smart + lazy: true + interval: 300 is usually enough.

Office exit that requires very high stability: first use filter to narrow candidates to trusted regions/providers, then hand them to smart.

Some websites require a fixed exit IP: do not send these rules directly to smart. Use select to pin a node, or use a sticky strategy with load-balance.

`fallback`: Ordered Primary/Backup#

fallback is suitable for scenarios where “the primary node is preferred, and the backup is used only if the primary fails.” It looks for an available item in member order and does not try to minimize latency.

proxy-groups:
  - name: BACKUP
    type: fallback
    proxies:
      - hk-primary
      - jp-backup
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

Note: putting DIRECT at the end means “fall back to direct connection when all proxies are unavailable.” This may be useful for normal browsing, but may be unsuitable for traffic that requires privacy or a fixed exit.

`load-balance`: Distribute Connections#

load-balance distributes connections across multiple candidates and supports three strategy values:

`strategy`	Behavior	Suitable Scenarios
`round-robin`	Polls candidates in order	You want to use multiple nodes evenly.
`consistent-hashing`	Hashes based on the target domain/IP, tending to use the same exit for the same target	Reduces frequent exit changes for the same website.
`sticky-sessions`	Maintains stickiness for a period based on process name + target	Login-sensitive applications, or client sessions that require a stable exit.

proxy-groups:
  - name: BALANCE
    type: load-balance
    use: [airport]
    filter: '香港`HK'
    strategy: consistent-hashing

`relay`: Chain Multiple Hops in Order#

relay does not “automatically select one node”; instead, it “chains multiple outbounds in order.” For example: first connect to a transit node through a local upstream proxy, then let the transit node connect to the final exit.

proxies:
  - name: front-node
    type: socks5
    server: 127.0.0.1
    port: 1080

  - name: exit-node
    type: ss
    server: exit.example.com
    port: 8388
    cipher: aes-128-gcm
    password: secret

proxy-groups:
  - name: RELAY
    type: relay
    proxies:
      - front-node
      - exit-node

This chain can be read as:

Client traffic -> Link1 -> front-node -> exit-node -> target website

Key rules for relay:

The order of proxies is the chain order and cannot be swapped arbitrarily.

The first member that can serve as the root transport handles the lowest-level dialing; subsequent members are stacked as transport layers.

If a member is a logical group such as select, smart, url-test, fallback, or load-balance, relay uses the leaf node currently selected by that group in the chain.

If a member is another relay, it is expanded into its sub-chain; circular references are rejected.

relay itself does not actively run health checks. It relies on the health state and dialing results of its members. If any hop in the chain fails, the entire connection fails.

TCP is the most common scenario. UDP is available only when every layer in the entire chain can provide UDP capability and disable-udp is not enabled; otherwise UDP fails.

The longer the chain, the higher the latency, number of failure points, and troubleshooting difficulty. Unless you explicitly need multiple hops, do not express normal automatic selection as relay.

Common patterns:

Goal	Recommended Configuration	Description
Connect to a remote node through a local proxy first	`relay: [local-socks, remote-node]`	A local proxy already exists on the machine, or there is an enterprise intranet jump host.
Select a transit first, then use a fixed exit	`relay: [SMART-FRONT, exit-node]`	`SMART-FRONT` automatically selects the transit, while the exit remains fixed.
Both segments automatic	`relay: [SMART-FRONT, SMART-EXIT]`	This can work, but troubleshooting is complex; verify the two groups separately first.

Policy Group Fields#

Field	Meaning	Actual Effect
`name`	Group name	Can be referenced by rules or other groups, and must be unique.
`type`	Group type	Determines selection logic or chaining logic.
`proxies`	Static member list	Can reference nodes or other groups; order has real effects for `fallback`, `relay`, and `round-robin`.
`use`	Referenced providers	Adds nodes produced by providers to the group.
`url`	Health check URL	Used by `url-test`/`fallback`/`smart`/`load-balance`.
`interval`	Probe interval, in seconds	Default is 300 seconds; shorter intervals are more responsive but consume more resources.
`timeout`	Probe timeout, in milliseconds	Default is 5000 ms; setting it too short on slow networks can cause false failures.
`lazy`	Lazy probing	Probes only when needed, suitable for large subscriptions.
`max-failed-times`	Compatibility field	Not recommended to rely on; actual availability is mainly determined by health probes and quality feedback.
`disable-udp`	Disable group UDP	Even if members support UDP, the group hides or rejects UDP capability externally.
`interface-name`	Compatibility field	Not recommended to rely on for normal groups; preferably set the outbound interface on specific outbound nodes or globally. A `relay` chain respects socket options on the root node.
`routing-mark`	Compatibility field	Not recommended to rely on for normal groups; preferably set Linux mark on specific outbound nodes or globally.
`include-all`	Include all static and provider nodes	Quickly creates a group.
`include-all-proxies`	Include all static nodes	Excludes providers.
`include-all-providers`	Include all provider nodes	Excludes static nodes.
`filter`	Member name filter	Multiple patterns can be separated by backticks; matching items are kept first.
`exclude-filter`	Member name exclusion	Excludes matching items after members are collected.
`exclude-type`	Protocol type exclusion	For example, exclude `direct`, `ssr`.
`expected-status`	Expected probe status code	Used together with `url` to determine whether a probe succeeds.
`health-check`	Nested health check configuration	Can override `url/interval/timeout/lazy/expected-status`.
`hidden`	App hiding hint	Affects App display, but does not change forwarding logic.
`icon`	App icon	Affects App display, but does not change forwarding logic.
`tolerance`	Latency tolerance, in milliseconds	Used by `url-test`/`smart` to reduce switching caused by small latency jitter.
`strategy`	`load-balance` strategy	`round-robin`, `consistent-hashing`, `sticky-sessions`.

Member Sources and Filtering#

proxy-groups:
  - name: JP
    type: url-test
    include-all: true
    filter: '日本`JP`Tokyo'
    exclude-filter: '过期`倍率:10'
    exclude-type: ssr

Actual effects:

include-all first collects all nodes.

filter keeps matching nodes.

exclude-filter then excludes matching nodes.

exclude-type excludes the specified protocol type.

Health Checks#

Health check configuration can be written at the group top level or under health-check:

proxy-groups:
  - name: AUTO
    type: url-test
    use: [airport]
    health-check:
      url: http://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: false
      expected-status: 204

Groups that support active health checks: url-test, smart, fallback, load-balance.

Groups that do not actively run health checks: select, relay.

Default values:

| Item | Default | | -- | ---- | | URL | http://www.gstatic.com/generate_204 | | interval | 300 seconds | | timeout | 5000 milliseconds |

Common Policy Group Templates#

Manual Primary Exit + Automatic Speed Test#

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    use: [airport]
    interval: 300

Primary/Backup fallback#

proxy-groups:
  - name: BACKUP
    type: fallback
    proxies:
      - node-primary
      - node-backup
      - DIRECT

Multi-hop relay#

proxy-groups:
  - name: RELAY
    type: relay
    proxies:
      - front-node
      - exit-node

Note: relay increases latency and failure points. Use it only when you explicitly need chained proxies.