9. 出站协议配置#

出站协议决定 Link1 最终如何连接目标或上游服务。所有静态出站节点写在 proxies 中；订阅、文件、内联或 WARP 动态节点写在 proxy-providers 中。

本章把每个协议当成“用户要配置的一种出口”来讲，不只列字段。读每个协议时请同时看四件事：

1. 它解决什么问题：普通代理、加密代理、L3 VPN、企业 VPN、还是特殊出口。

1. 一条连接如何走：Link1 到上游之间使用 TCP、UDP、QUIC、TLS、WireGuard、OpenVPN 还是企业专有协议。

1. 字段改变什么行为：认证、证书、传输层、DNS、UDP、路由、性能参数分别会影响哪一段。

1. 常见误区：哪些字段不是这个协议的字段，哪些字段看起来相似但含义不同。

如果你是第一次配置某个协议，建议先复制本章示例，只改服务商给你的账号、地址、端口、密码/密钥；跑通后再调整高级字段。

出站节点通用结构#

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

通用字段：

不是每个协议都支持所有通用字段。Link1 会在配置编译期拒绝协议不支持的字段。

通用字段怎样影响数据流#

这些字段不属于某个单独协议，而是影响“Link1 到上游”这一段如何拨号：

dialer-proxy 是最容易误解的字段。它不是“这个节点的备用节点”，而是“连接这个节点的服务器时，先通过另一个出站”。例如 trojan 节点使用 dialer-proxy: PROXY，表示 Trojan 在连接自己的 server:port 时先通过 PROXY 组建立底层连接；协议握手完成后，这个 Trojan 节点仍按自己的协议处理最终业务流量。

协议总览#

协议配置可以从上游资料反推：

• 给你的是“代理地址 + 端口 + 用户名密码”，通常是 http、socks5、naive 或企业 VPN。

• 给你的是“UUID + TLS/REALITY/WS/gRPC”，通常是 vmess/vless。

• 给你的是“password + TLS 443”，可能是 trojan、hysteria2、tuic、anytls。

• 给你的是“private key/public key/allowed ips”，通常是 wireguard 或 WARP manual。

• 给你的是 .ovpn、ca.crt、client.crt、tls-auth，通常是 openvpn。

我该选哪种出站#

如果你不是在“自己设计服务端协议”，而是在把别人给你的账号填进 Link1，先按服务商给的材料选协议，不要凭感觉改类型。下面的表是从用户场景出发的选择建议：

一个简单决策树：

你拿到的是现成节点/订阅吗？
  是 -> 按节点 type 填，不要换协议
  否 -> 是企业 VPN/内网账号吗？
         是 -> openvpn / atrust / feilian / easyconnect / tailscale
         否 -> 是 WARP 吗？
                是 -> proxy-providers.type=warp
                否 -> 只是上游代理端口吗？
                       是 -> http / socks5 / naive
                       否 -> 自建服务端按服务端协议选择

TLS、传输和扩展字段#

很多协议共享 TLS 字段：

tls: true
skip-cert-verify: false
servername: example.com
sni: example.com
alpn: [h2]
client-fingerprint: chrome

实际影响：

• tls=true 开启 TLS 包装或协议 TLS 模式。

• skip-cert-verify=true 会跳过证书校验，降低安全性。

• servername / sni 改变 TLS 握手域名。

• alpn 影响 HTTP/2、HTTP/3 或协议协商。

• client-fingerprint 改变 ClientHello 指纹，需协议支持。

VMess/VLESS/Trojan 常见传输：

network: ws
ws-opts:
  path: /ws
  headers:
    Host: example.com

REALITY：

reality-opts:
  public-key: xxxxx
  short-id: abcd
  fingerprint: chrome

ECH：

ech-opts:
  enable: true
  mode: grease
  query-server-name: example.com

SMUX：

smux:
  enabled: true
  protocol: smux
  max-connections: 4
  min-streams: 4
  max-streams: 32

传输子配置字段怎么读#

TLS/REALITY/ECH 字段怎么读#

如果你不知道是否需要这些字段，先不要写。服务商给了才写，且字段值要逐字匹配。

特殊出口#

direct#

直连目标服务器。

proxies:
  - name: local-direct
    type: direct
    interface-name: eth0

字段影响：

• 可用 interface-name / routing-mark 控制直连出口。

• 内置 DIRECT 已存在，普通配置无需显式声明。

reject#

拒绝连接。

proxies:
  - name: block
    type: reject

用于广告/恶意流量/不允许访问的规则。内置 REJECT 已存在。

dns#

交给 Link1 内置 DNS resolver 的特殊出口。

proxies:
  - name: dns-out
    type: dns

普通用户通常不需要显式配置。

显式代理协议#

http#

HTTP 上游代理的工作方式是：Link1 先连接上游 HTTP proxy；如果客户端访问 HTTPS，Link1 会向上游发送 CONNECT target:443，由上游建立到目标的 TCP 隧道；如果访问明文 HTTP，则上游可以转发完整 HTTP 请求。

适合：公司代理、云服务器上的 HTTP 代理、需要 Basic 认证的上游。它不是 HTTP Engine，也不会自动解密 HTTPS 内容。

proxies:
  - name: http-upstream
    type: http
    server: proxy.example.com
    port: 8080
    username: alice
    password: secret
    tls: false

关键字段：

socks / socks5#

SOCKS5 上游代理的工作方式是：Link1 把目标地址交给 SOCKS5 服务器，由 SOCKS5 服务器去连接目标。目标可以是域名，也可以是 IP。

DNS 影响：如果 Link1 把域名交给 SOCKS5，上游负责解析；如果 Link1 先解析成 IP，再交给 SOCKS5，则域名信息可能丢失。透明代理/TUN 场景下仍建议先让 Link1 DNS/Fake-IP 提供域名上下文。

UDP 影响：udp: true 表示尝试使用 SOCKS5 UDP associate。上游不支持时，UDP 流量会失败，但 TCP 仍可能正常。

proxies:
  - name: socks-upstream
    type: socks5
    server: 127.0.0.1
    port: 1080
    username: alice
    password: secret
    udp: true

关键字段：

ssh#

SSH 出站的工作方式是：Link1 先登录 SSH 服务器，然后通过 SSH channel 转发 TCP 流量。它更像“把 SSH 服务器当跳板机”，不是传统加密代理协议。

认证可以用密码，也可以用私钥。生产环境强烈建议配置 host-key 校验服务端主机密钥；skip-host-key-verify 只适合临时测试。UDP 不是 SSH 原生能力，Link1 通过 udpgw 模式桥接，因此需要对应网关支持。

proxies:
  - name: ssh-node
    type: ssh
    server: ssh.example.com
    port: 22
    username: root
    private-key: ./id_ed25519
    private-key-passphrase: secret
    host-key:
      - SHA256:xxxxxxxx
    udp: true
    udp-relay-mode: udpgw
    udp-gateway: 127.0.0.1:7300

关键字段：

限制：SSH 不支持 TLS、VMess/VLESS 传输字段、Reality、ECH、SMUX 等代理协议扩展。

VMess / VLESS / Trojan#

这三类协议都常见于“节点订阅”。它们的配置由三层组成：身份字段（uuid/password）、安全层（TLS/REALITY/证书/SNI）、传输层（TCP/WS/H2/gRPC/KCP）。排障时不要只看端口通不通，很多失败发生在 TLS、REALITY 或传输层路径不匹配。

vmess#

proxies:
  - name: vmess-ws
    type: vmess
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: example.com

关键字段：

vless#

proxies:
  - name: vless-reality
    type: vless
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    flow: xtls-rprx-vision
    encryption: none
    tls: true
    network: tcp
    reality-opts:
      public-key: xxxxx
      short-id: abcd
      fingerprint: chrome

关键字段：

trojan#

proxies:
  - name: trojan-grpc
    type: trojan
    server: example.com
    port: 443
    password: secret
    tls: true
    network: grpc
    grpc-opts:
      grpc-service-name: trojan

关键字段：

Shadowsocks 生态#

Shadowsocks 生态的核心是“加密方法 + 密码”。SS 本身较轻量，插件、UDP-over-TCP、XUDP、packet-addr 等字段是为兼容不同服务端和传输场景而存在。SSR 和 ShadowTLS 是不同的兼容/包装协议，字段不能混用。

ss / shadowsocks#

proxies:
  - name: ss-node
    type: ss
    server: example.com
    port: 8388
    cipher: 2022-blake3-aes-128-gcm
    password: secret
    udp: true
    plugin: obfs
    plugin-opts:
      mode: tls
      host: www.example.com

关键字段：

Shadowsocks cipher 与 plugin 组合#

Shadowsocks 是本章最典型的“加密套件 + 插件”协议。你可以把它理解成两层：

1. cipher 和 password 负责加密 SS 数据流。

1. plugin 和 plugin-opts 负责把“到 SS 服务端的这条 TCP 连接”伪装或封装成另一种形态。

Link1 的处理顺序是：先连到 server:port，如果配置了插件先让插件包装这条上游连接，然后再在插件连接上运行 Shadowsocks 加密协议。因此，服务端的 cipher、密码和插件参数必须逐项一致。

支持的 cipher：

配置中也兼容部分大小写、下划线或 ss-2022-* 别名；用户文档只列推荐写法。

支持的 plugin：

使用组合时按下面顺序排查：

• 先关闭插件，只验证 cipher/password/server/port 是否能通。

• 再打开插件，只改 plugin 与 plugin-opts。如果 TCP 能通但 UDP 不通，优先看上表的 UDP 行为。

• plugin-opts.host、WebSocket path、Cloak serverName、ShadowTLS/Restls 版本是服务端约定，不是随意可换的“伪装域名”。

ssr / shadowsocksr#

proxies:
  - name: ssr-node
    type: ssr
    server: example.com
    port: 8388
    cipher: aes-256-cfb
    password: secret
    obfs: tls1.2_ticket_auth
    obfs-param: example.com
    protocol: auth_sha1_v4
    protocol-param: ''

关键字段：

ShadowsocksR cipher / obfs / protocol 组合#

SSR 的配置由三件事同时决定：cipher 负责加密，obfs 负责流量外观，protocol 负责 SSR 认证/分片格式。Link1 支持下表组合：

这些维度在配置层可以组合，但真实是否可用取决于 SSR 服务端是否也使用同一组合。SSR 排障不要只看 cipher，obfs 或 protocol 任意一个不匹配都会表现为连接建立后无数据、很快断开或 UDP 异常。

shadowtls#

proxies:
  - name: shadowtls-node
    type: shadowtls
    server: example.com
    port: 443
    password: secret
    version: 3
    sni: www.example.com

关键字段：

QUIC / 高性能代理协议#

这一组协议主要跑在 QUIC/UDP 上。它们通常对移动网络、丢包和 UDP 业务更友好，但前提是本地网络、运营商、路由器和上游都允许 UDP。遇到“TCP 网站能打开，视频/游戏/QUIC 不通”，优先检查 udp、防火墙和上游 UDP 支持。

带宽字段 up/down 是协议调度和拥塞控制的重要输入，不是简单展示文字；写得过高可能导致丢包，写得过低可能限制吞吐。

tuic#

proxies:
  - name: tuic-node
    type: tuic
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: secret
    udp: true
    udp-relay-mode: native
    congestion-controller: bbr
    reduce-rtt: true

关键字段：

hysteria#

proxies:
  - name: hy1-node
    type: hysteria
    server: example.com
    port: 443
    auth-str: secret
    protocol: udp
    up: 50 Mbps
    down: 200 Mbps
    sni: example.com

关键字段：

faketcp 属于 Linux raw-socket 相关能力，Spark 不提供该非全平台协议特性。

hysteria2 / hy2#

proxies:
  - name: hy2-node
    type: hysteria2
    server: example.com
    port: 443
    password: secret
    obfs: salamander
    obfs-password: obfs-pass
    sni: example.com
    skip-cert-verify: false
    up: 50 Mbps
    down: 200 Mbps

关键字段：

Hysteria2 的可选混淆组合很少，支持下面两种写法：

realm-opts 适合服务端不直接暴露常规端口、需要通过 realm server/STUN 协调转发的场景。配置后必须提供 server-url、token、realm-id 和至少一个 stun-servers；不能和 ports 端口跳跃同时使用。realm-opts.proxy 表示访问 realm 控制面时使用的出口，不等同于节点自己的 dialer-proxy。

realm-opts:
  enable: true
  server-url: https://realm.example
  token: xxxxx
  realm-id: hy2-realm
  stun-servers:
    - stun.example:3478
  sni: realm.example
  proxy: PROXY

cipher、protocol、network、plugin 等旧协议字段不属于 Hysteria2；如果从别的订阅格式转换过来看到这些字段，通常会被忽略或校验拒绝。

juicity#

proxies:
  - name: juicity-node
    type: juicity
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: secret
    sni: example.com
    congestion-controller: bbr

关键字段：uuid、password、sni、skip-cert-verify、congestion-controller、udp。

naive#

proxies:
  - name: naive-node
    type: naive
    server: example.com
    port: 443
    username: alice
    password: secret
    tls: true

NaiveProxy 使用 HTTP/2/HTTP/3 风格的上游代理。关键字段：username、password、tls、skip-cert-verify、servername、alpn。

其他代理协议#

这一组协议各自有独立服务端生态。它们不像 VMess/VLESS 那样共享大量传输字段，因此最重要的是按服务端文档逐项对应：版本、密码/密钥、混淆、mask、padding、UDP 策略都必须匹配。

snell#

proxies:
  - name: snell-node
    type: snell
    server: example.com
    port: 443
    psk: secret
    version: 3
    udp: true
    obfs-opts:
      mode: tls
      host: www.example.com

关键字段：

Snell 支持的版本/混淆组合：

network 按 TCP 行为处理；Snell 不是通用 WebSocket/TLS 传输协议，不支持 ws-opts、grpc-opts 等传输子配置。

gost-relay#

proxies:
  - name: relay-node
    type: gost-relay
    server: relay.example.com
    port: 8420
    username: user
    password: pass
    dialer-proxy: DIRECT

gost-relay 是 GOST relay v1 的轻量 TCP 出站实现。Link1 先连接 server:port，发送 relay CONNECT 请求，再把后续 TCP 流量转发给目标地址。它适合把 GOST relay 服务端作为链式跳板，或者作为其他出站的 dialer-proxy 使用。

关键字段：

首版限制：只支持 TCP CONNECT；udp: true、tls: true、network: udp 会在配置编译期报错。GOST relay 的 TLS/mTLS、mux、UDP forward/associate 不在本阶段实现范围内。

anytls#

proxies:
  - name: anytls-node
    type: anytls
    server: example.com
    port: 443
    password: secret
    sni: example.com

关键字段：password、sni/servername、skip-cert-verify、udp、alpn、client-fingerprint。

brook#

proxies:
  - name: brook-node
    type: brook
    server: example.com
    port: 443
    password: secret
    network: ws
    ws-opts:
      path: /ws
    tls: true

关键字段：

mieru#

proxies:
  - name: mieru-node
    type: mieru
    server: example.com
    port: 443
    username: alice
    password: secret
    transport: TCP

关键字段：username、password、server、port、transport、multiplexing、handshake-mode。

trusttunnel#

proxies:
  - name: trust-node
    type: trusttunnel
    server: example.com
    port: 443
    username: alice
    password: secret
    alpn: [h2]
    udp: true
    udp-over-stream: true

关键字段：

sudoku#

proxies:
  - name: sudoku-node
    type: sudoku
    server: example.com
    port: 443
    password: secret
    aead-method: chacha20-poly1305
    udp: true
    sudoku-udp-policy: uot
    padding-min: 1
    padding-max: 8

关键字段：

Sudoku 支持的安全/混淆组合：

Sudoku 目前只实现 TCP 出站网络；如果配置 network，只能是 tcp 或留空。

L3 隧道与组网协议#

L3 隧道与普通代理最大的区别是：它们得到的是一条“虚拟网络链路”，而不只是一个 CONNECT/SOCKS 转发。DNS、路由、MTU、隧道地址、allowed routes 都会影响能访问哪些地址。

用户要特别区分两层路由：

• Link1 顶层 rules：决定某条连接是否选择这个 VPN 出站。

• VPN 协议内部路由：决定进入 VPN 后，哪些目标 IP 会在隧道内可达。

wireguard / wg#

proxies:
  - name: wg-node
    type: wireguard
    private-key: xxxxx
    ip: 172.16.0.2/32
    ipv6: 2606:4700::1/128
    mtu: 1280
    peers:
      - server: engage.cloudflareclient.com
        port: 2408
        public-key: xxxxx
        pre-shared-key: optional
        allowed-ips:
          - 0.0.0.0/0
          - ::/0

关键字段：

WireGuard DNS 与 allowed-ips#

allowed-ips 是 WireGuard peer 的隧道路由前缀，不是 Link1 顶层规则。通常服务商给 0.0.0.0/0 和 ::/0，表示进入这个出站后的目标都允许走该 peer；如果只给企业内网前缀，则只有这些内网 IP 在隧道内可达。

dns 和 remote-dns-resolve 用于解决“这个域名应该在哪里解析”。VPN 类型默认 remote-dns-resolve: true：当目标仍是域名时，Link1 会优先让该 VPN runtime 使用隧道 DNS 解析。dns 可手动指定隧道 DNS；如果 runtime 没有服务端下发或配置的 DNS，开启远端解析会直接报错，不会静默回退到本地 DNS。需要复用本地/全局 DNS 时，可以显式写 remote-dns-resolve: false。

masque#

proxies:
  - name: masque-node
    type: masque
    server: example.com
    port: 443
    uri: https://example.com/.well-known/masque/udp/1.1.1.1/443/
    sni: example.com
    handshake-mode: strict
    congestion-controller: bbr
    mtu: 1280

关键字段：

MASQUE DNS 与 URI#

MASQUE 的 uri 不只是普通网址，它描述了 HTTP/3 MASQUE 服务端接受 CONNECT-UDP/IP 的位置。server/port 决定连接哪个 endpoint，sni/servername 决定 TLS 握手域名，uri 决定 MASQUE 请求目标。三者可能相同，也可能由服务商分别给出。

dns 与 remote-dns-resolve 的含义和 WireGuard 类似：它们用于控制进入 MASQUE 隧道后的域名解析。VPN MASQUE 默认 remote-dns-resolve: true，可显式设为 false 退回本地/全局 DNS。对 WARP MASQUE 来说，provider 会把 WARP 状态中的 DNS 和 remote resolve 参数物化到生成的 MASQUE 节点。

tailscale#

proxies:
  - name: tailnet
    type: tailscale
    auth-key: tskey-xxxxx
    hostname: link1-router
    control-url: https://headscale.example.com
    exit-node: 100.64.0.10
    auto-route: true
    route-rule-set: tailnet-routes

关键字段：

route-rule-set 默认直接使用代理名加 $ 前缀。若代理名或显式规则集名包含逗号，自动注入的 RULE-SET 会按通用规则语法使用双引号包裹并转义。

Tailscale MagicDNS#

Tailscale 出站默认 remote-dns-resolve: true。当规则把一个域名目标交给该出站时，Link1 会先通过内嵌 Tailscale runtime 的 DNS manager 查询 MagicDNS / tailnet DNS，再用解析出的 tailnet IP 建立连接；如果 Tailscale DNS 没有返回地址，会报错，不会静默回退到本地 DNS。确实想复用本地或全局 DNS 时，可以显式写 remote-dns-resolve: false。

全局 DNS 也可以直接引用某个 Tailscale 出站：

dns:
  nameserver-policy:
    '+.tailnet.ts.net':
      - ts://tailnet

tailscale://tailnet 和 ts://tailnet 等价，都表示“使用名为 tailnet 的 Tailscale 出站提供的 MagicDNS / tailnet DNS”。

dialer-proxy 会作用到 Tailscale 自身的系统拨号路径：控制面、DERP/relay、peer 直连建连都会优先通过指定出口。当前实现使用 Link1 裁剪后的 Tailscale fork，并把底层 WireGuard 路径接到 Link1 内部 WireGuard；目标是只保留出站所需子集，同时保留后续扩展 WireGuard 变体能力的空间。

openvpn#

OpenVPN 出站不是普通“远程代理端口”，而是完整 VPN 客户端。Link1 会先和 OpenVPN 服务端建立控制通道，完成 TLS/证书/用户名密码认证，然后创建 userspace 隧道网络，把被规则选中的连接放进这个隧道。配置 dialer-proxy 时，OpenVPN 连接 remote 的 TCP/UDP 底层通道会先通过指定出站；UDP remote 要求前置出站具备 UDP 能力。

它的数据流可以理解为：

应用连接
  -> Link1 rules 选中 ovpn-node
  -> OpenVPN userspace netstack
  -> OpenVPN 控制/数据通道
  -> VPN 服务端
  -> 企业内网或公网目标

最小示例：

proxies:
  - name: ovpn-node
    type: openvpn
    server: vpn.example.com
    port: 1194
    network: udp
    username: alice
    password: secret
    ca: ./certs/ca.crt
    certificate: ./certs/client.crt
    private-key: ./certs/client.key
    private-key-passphrase: optional-passphrase
    route-rule-set: ovpn-node-routes

多 remote 示例：

proxies:
  - name: ovpn-node
    type: openvpn
    ca: ./certs/ca.crt
    username: alice
    password: secret
    remotes:
      - server: vpn1.example.com
        port: 1194
        protocol: udp
        sni: vpn.example.com
      - server: vpn2.example.com
        port: 443
        protocol: tcp
        servername: vpn.example.com

OpenVPN 字段说明#

route-rule-set 默认直接使用代理名加 $ 前缀。若代理名或显式规则集名包含逗号，自动注入的 RULE-SET 会按通用规则语法使用双引号包裹并转义。

不支持的常见字段：

• tls、alpn、client-fingerprint、reality-opts、ech-opts、ws-opts、grpc-opts：这些是普通代理/TLS 传输字段，不是 OpenVPN 配置。

• auto-setup-routes：这是企业 VPN 风格字段，不是 OpenVPN 出站字段。OpenVPN 使用 route-rule-set 和 auto-route。

OpenVPN DNS 是怎么工作的#

OpenVPN DNS 有三层来源，优先级从高到低：

1. 服务端 push 的 DNS：OpenVPN 服务端可能在 PUSH_REPLY 中下发 dhcp-option DNS 10.8.0.1。Link1 会记录到 OpenVPN runtime snapshot 中。

1. 节点里的 dns 字段：如果服务端不 push DNS，你可以手动写 dns: [10.8.0.1]。

1. 全局 Link1 DNS：当 remote-dns-resolve: false，或某次 DNS 查询不是某个出站拨号目标的一部分时，普通 DNS 仍按 dns.nameserver、nameserver-policy 等全局配置执行。

OpenVPN 默认 remote-dns-resolve: true。被规则选中并进入 OpenVPN 出站的域名目标，会由 OpenVPN runtime 使用 pushed/configured DNS 解析；如果没有可用 VPN DNS，会报错而不是回退本地 DNS。

如果需要让全局 DNS 策略中的某些企业域名也显式调用 OpenVPN 内部 DNS，可以在 dns.nameserver-policy 写 openvpn://<节点名>：

dns:
  enable: true
  nameserver:
    - https://223.5.5.5/dns-query
  nameserver-policy:
    '+.corp.example.com':
      - openvpn://ovpn-node
    '+.internal.example.com':
      - openvpn://ovpn-node

含义：

• 普通域名仍走默认 nameserver。

• corp.example.com 这类企业域名会调用 ovpn-node 的远端 DNS 能力。

• ovpn-node 必须已经能建立 OpenVPN runtime，并且 snapshot 中有 DNS 服务器；否则会报“没有 remote dns servers”或远端解析失败。

openvpn://ovpn-node 和 remote-dns-resolve 使用同一类远端 DNS 能力，但入口不同：前者是全局 DNS policy 的 nameserver，后者是 OpenVPN 出站拨目标域名时的解析策略。

OpenVPN 路由是怎么工作的#

OpenVPN 服务端可能 push 路由，例如 route 10.0.0.0 255.0.0.0 或 IPv6 route。Link1 会把这些前缀记录到该节点的 runtime snapshot。

route-rule-set 会把这些前缀暴露成一个动态规则集：

proxies:
  - name: ovpn-node
    type: openvpn
    server: vpn.example.com
    port: 1194
    ca: ./certs/ca.crt
    route-rule-set: corp-vpn-routes
    auto-route: true

rules:
  - DOMAIN-SUFFIX,corp.example.com,ovpn-node
  - MATCH,PROXY

当 auto-route: true 时，Link1 会自动把类似下面的规则插入到 MATCH 前：

rules:
  - RULE-SET,corp-vpn-routes,ovpn-node
  - MATCH,PROXY

注意：OpenVPN 动态 route rule-set 主要匹配服务端 push 的 IP 前缀；企业域名仍建议通过 dns.nameserver-policy 指到 openvpn://ovpn-node，解析出企业内网 IP 后再让路由规则命中。

常见 OpenVPN 问题#

WARP provider#

WARP 是 Cloudflare 的动态出口能力。Link1 不把它设计成 proxies[].type=warp，而是设计成 proxy-providers.type=warp。原因是：WARP 不是一个固定 leaf 节点，而是一个会生成节点的“节点来源”。

为什么必须是 provider：

1. 一个 WARP 配置可能生成多个出口：同一个 WARP 状态可以物化出 wireguard 和 masque 两类节点。

1. auto 模式需要持久状态：账号、密钥、endpoint、reserved bytes、MASQUE 参数等需要被管理和复用。

1. 它天然适合策略组选择：provider 生成的节点可以进入 select、url-test、fallback 等策略组，由用户或健康检查选择。

1. 它不是订阅下载：WARP provider 不使用 url、path、format、proxy 这些订阅字段；它从 WARP 状态构建本地节点。

1. 避免配置歧义：如果允许 proxies[].type=warp，用户会误以为它像普通协议一样只有一个固定 server/port；实际 WARP 需要先决定 transport 和状态来源。

最常见写法：

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

proxy-groups:
  - name: WARP
    type: select
    use: [warp]
    proxies:
      - DIRECT

rules:
  - MATCH,WARP

这份配置的含义：

• warp provider 负责生成 WARP 节点。

• transports 指定希望生成哪些类型，支持 masque 和 wireguard。

• 如果两个 transport 都有可用状态，组里会出现类似 warp MASQUE、warp WIREGUARD 的节点。

• WARP 策略组负责让用户选择具体 WARP transport，或配合自动组做健康选择。

WARP auto 模式字段#

不再支持的 discovery 字段：probe-timeout、count、wg-candidates、masque-candidates。这些字段属于旧的 discovery 设计，写入配置会被拒绝。

WARP manual 模式字段#

manual 模式适合你已经有完整 WARP 参数，不希望 Link1 自动生成状态。

proxy-providers:
  warp-manual:
    type: warp
    mode: manual
    transports: [wireguard, masque]
    wireguard:
      private-key: xxxxx
      public-key: xxxxx
      ip: 172.16.0.2
      ipv6: 2606:4700::1
      reserved:
        bytes: [0, 0, 0]
      server: engage.cloudflareclient.com
      port: 2408
      allowed-ips:
        - 0.0.0.0/0
        - ::/0
      mtu: 1280
      persistent-keepalive: 25
    masque:
      private-key: xxxxx
      public-key: xxxxx
      ip: 172.16.0.2
      ipv6: 2606:4700::1
      server: masque.cloudflareclient.com
      port: 443
      uri: https://masque.cloudflareclient.com/
      sni: masque.cloudflareclient.com
      dns:
        - 1.1.1.1
      remote-dns-resolve: true
      mtu: 1280
      congestion-controller: bbr

manual 模式规则：

• transports 包含 wireguard 时必须提供 wireguard 子块。

• transports 包含 masque 时必须提供 masque 子块。

• license-key 只能用于 auto 模式。

• 顶层 handshake-mode 不支持；WARP MASQUE 内部会使用固定兼容握手语义。

provider 生成的节点是什么#

WARP provider 最终会生成普通 Link1 出站节点：

因此后续策略组、规则、健康检查都面对这些生成后的节点，而不是直接面对 warp。这也是 warp 必须放在 provider 的根本原因。

WARP 常见问题#

企业 VPN 协议#

企业 VPN 协议依赖目标服务端版本、登录策略、验证码、设备绑定和企业安全策略。它们更像“把企业 VPN 作为 Link1 出口”，不是普通机场订阅节点。

企业 VPN 通常会返回两类动态信息：

• 企业 DNS：用于解析只在公司内网存在的域名。

• 企业路由：用于判断哪些内网 IP 应该走 VPN。

因此这类协议经常和 dns.nameserver-policy、route-rule-set、策略组一起使用，而不是把所有流量无脑交给企业 VPN。

atrust#

proxies:
  - name: atrust-node
    type: atrust
    server: vpn.example.com
    username: alice
    password: secret
    auth-type: auth/psw
    remote-dns-resolve: true
    route-rule-set: corp-routes

关键字段：

限制：不支持普通代理的 TLS/QUIC/network 等字段；dialer-proxy 会同时作用于登录控制面和企业隧道底层连接。

feilian#

proxies:
  - name: feilian-node
    type: feilian
    server: vpn.example.com
    company-name: example
    username: alice
    password: secret
    vpn-select-strategy: default
    remote-dns-resolve: true

关键字段：

easyconnect#

proxies:
  - name: easyconnect-node
    type: easyconnect
    server: vpn.example.com
    port: 443
    username: alice
    password: secret
    remote-dns-resolve: true

关键字段：

企业 VPN 动态 route-rule-set 的自动注入同样遵循通用规则语法；代理名或规则集名包含逗号时，会自动 quote 对应字段。

限制：不支持普通代理的 TLS、QUIC、network 等字段；dialer-proxy 会同时作用于登录控制面和隧道数据连接。

入站协议监听器#

虽然本章主要讲出站，但 Link1 也能作为部分协议服务端。

VLESS listener#

listeners:
  - name: vless-in
    type: vless
    listen: 0.0.0.0
    port: 443
    certificate: ./certs/server.crt
    private-key: ./certs/server.key
    users:
      - username: alice
        uuid: 00000000-0000-0000-0000-000000000000
        flow: xtls-rprx-vision
    ws-path: /ws
    proxy: PROXY

关键字段：users、uuid、certificate、private-key、ws-path、grpc-service-name、decryption、reality-config、proxy。

Hysteria2 listener#

listeners:
  - name: hy2-in
    type: hysteria2
    listen: 0.0.0.0
    port: 443
    certificate: ./certs/server.crt
    private-key: ./certs/server.key
    users:
      alice: password1
      bob: password2
    up: 100 Mbps
    down: 500 Mbps
    obfs: salamander
    obfs-password: secret
    alpn: [h3]
    masquerade: https://www.example.com
    proxy: PROXY

关键字段：users、certificate、private-key、up、down、obfs、obfs-password、max-idle-time、alpn、ignore-client-bandwidth、masquerade、proxy。

协议选择建议#

兼容边界#

• 字段出现在统一 ProxyConfig 中，不代表每个协议都支持。

• Link1 会尽量在编译期指出“不支持的字段”。

• 企业 VPN 协议受服务端策略影响，不能保证所有企业版本都可用。

• skip-cert-verify 只建议测试或自签证书场景使用。

• dialer-proxy 会改变拨号链路，部分协议设置后会禁用 ip-version、interface-name、routing-mark 等直拨字段。