9. Outbound Protocol Configuration#

Outbound protocols determine how Link1 ultimately connects to a target or upstream service. All static outbound nodes are defined in proxies; dynamic nodes from subscriptions, files, inline definitions, or WARP are defined in proxy-providers.

This chapter explains each protocol as “an egress type the user needs to configure,” instead of only listing fields. When reading about each protocol, consider four things:

1. What problem it solves: a regular proxy, encrypted proxy, L3 VPN, enterprise VPN, or special egress.

1. How a connection flows: whether Link1 uses TCP, UDP, QUIC, TLS, WireGuard, OpenVPN, or an enterprise proprietary protocol to reach the upstream.

1. What behavior each field changes: how authentication, certificates, transport layer, DNS, UDP, routing, and performance parameters affect each part of the connection.

1. Common pitfalls: which fields do not belong to this protocol, and which fields look similar but mean different things.

If you are configuring a protocol for the first time, we recommend copying the example in this chapter first and changing only the account, address, port, password/key provided by your service provider. After it works, adjust advanced fields as needed.

Common Outbound Node Structure#

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

Common fields:

Not every protocol supports all common fields. Link1 rejects unsupported fields during configuration compilation.

How Common Fields Affect Data Flow#

These fields do not belong to a single protocol. They affect how the “Link1 to upstream” segment is dialed:

dialer-proxy is the easiest field to misunderstand. It is not a “backup node for this node.” It means “when connecting to this node’s server, go through another outbound first.” For example, if a trojan node uses dialer-proxy: PROXY, Trojan first establishes the underlying connection to its own server:port through the PROXY group. After the protocol handshake completes, this Trojan node still handles final application traffic using its own protocol.

Protocol Overview#

Protocol configuration can often be inferred from upstream materials:

• If you receive “proxy address + port + username/password,” it is usually http, socks5, naive, or an enterprise VPN.

• If you receive “UUID + TLS/REALITY/WS/gRPC,” it is usually vmess/vless.

• If you receive “password + TLS 443,” it may be trojan, hysteria2, tuic, or anytls.

• If you receive “private key/public key/allowed ips,” it is usually wireguard or WARP manual.

• If you receive .ovpn, ca.crt, client.crt, or tls-auth, it is usually openvpn.

Which Outbound Should I Choose?#

If you are not “designing your own server protocol” but entering an account someone gave you into Link1, choose the protocol based on the provider’s materials first. Do not change the type based on guesswork. The table below gives selection suggestions from user scenarios:

A simple decision tree:

Did you receive a ready-made node/subscription?
  Yes -> Fill fields according to the node type; do not change the protocol
  No -> Is it an enterprise VPN/intranet account?
         Yes -> openvpn / atrust / feilian / easyconnect / tailscale
         No -> Is it WARP?
                Yes -> proxy-providers.type=warp
                No -> Is it only an upstream proxy port?
                       Yes -> http / socks5 / naive
                       No -> choose based on the self-hosted server protocol

TLS, Transport, and Extension Fields#

Many protocols share TLS fields:

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

Practical effects:

• tls=true enables TLS wrapping or the protocol's TLS mode.

• skip-cert-verify=true skips certificate verification and reduces security.

• servername / sni changes the domain name used in the TLS handshake.

• alpn affects HTTP/2, HTTP/3, or protocol negotiation.

• client-fingerprint changes the ClientHello fingerprint and requires protocol support.

Common transports for 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

How to read transport sub-configuration fields#

How to read TLS/REALITY/ECH fields#

If you do not know whether these fields are needed, do not set them at first. Set them only when provided by your service provider, and match the field values exactly.

Special Outbounds#

direct#

Connect directly to the target server.

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

Field effects:

• You can use interface-name / routing-mark to control the direct outbound interface.

• The built-in DIRECT already exists; normal configurations do not need to declare it explicitly.

reject#

Reject connections.

proxies:
  - name: block
    type: reject

Used for rules that block ads, malicious traffic, or disallowed access. The built-in REJECT already exists.

dns#

A special outbound that hands traffic to Link1's built-in DNS resolver.

proxies:
  - name: dns-out
    type: dns

Regular users usually do not need to configure it explicitly.

Explicit Proxy Protocols#

http#

An HTTP upstream proxy works as follows: Link1 first connects to the upstream HTTP proxy. If the client accesses HTTPS, Link1 sends CONNECT target:443 to the upstream, and the upstream establishes a TCP tunnel to the target. If the client accesses plaintext HTTP, the upstream can forward the full HTTP request.

Suitable for: corporate proxies, HTTP proxies on cloud servers, and upstreams that require Basic authentication. It is not HTTP Engine and does not automatically decrypt HTTPS content.

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

Key fields:

socks / socks5#

A SOCKS5 upstream proxy works as follows: Link1 passes the target address to the SOCKS5 server, and the SOCKS5 server connects to the target. The target can be a domain name or an IP address.

DNS impact: If Link1 passes the domain name to SOCKS5, the upstream is responsible for resolution. If Link1 resolves it to an IP first and then passes it to SOCKS5, domain information may be lost. In transparent proxy/TUN scenarios, it is still recommended to let Link1 DNS/Fake-IP provide domain context first.

UDP impact: udp: true means Link1 will try to use SOCKS5 UDP associate. If the upstream does not support it, UDP traffic will fail, but TCP may still work normally.

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

Key fields:

ssh#

An SSH outbound works as follows: Link1 first logs in to the SSH server, then forwards TCP traffic through an SSH channel. It is more like "using the SSH server as a jump host" than a traditional encrypted proxy protocol.

Authentication can use either a password or a private key. In production, it is strongly recommended to configure host-key to verify the server host key. skip-host-key-verify is only suitable for temporary testing. UDP is not a native SSH capability; Link1 bridges it through udpgw mode, so a corresponding gateway is required.

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

Key fields:

Limitations: SSH does not support TLS, VMess/VLESS transport fields, Reality, ECH, SMUX, or other proxy protocol extensions.

VMess / VLESS / Trojan#

These three protocol types are common in "node subscriptions". Their configuration consists of three layers: identity fields (uuid/password), security layer (TLS/REALITY/certificates/SNI), and transport layer (TCP/WS/H2/gRPC/KCP). When troubleshooting, do not only check whether the port is reachable. Many failures happen because TLS, REALITY, or the transport-layer path does not match.

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

Key fields:

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

Key fields:

trojan#

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

Key fields:

Shadowsocks Ecosystem#

The core of the Shadowsocks ecosystem is "encryption method + password". SS itself is lightweight. Fields such as plugins, UDP-over-TCP, XUDP, and packet-addr exist to support different servers and transport scenarios. SSR and ShadowTLS are different compatibility/wrapping protocols, and their fields cannot be mixed.

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

Key fields:

Shadowsocks cipher and plugin combinations#

Shadowsocks is the most typical "cipher suite + plugin" protocol in this chapter. You can think of it as two layers:

1. cipher and password encrypt the SS data stream.

1. plugin and plugin-opts disguise or wrap the TCP connection to the SS server into another form.

Link1 processes them in this order: first connect to server:port; if a plugin is configured, let the plugin wrap this upstream connection first; then run the Shadowsocks encryption protocol over the plugin connection. Therefore, the server-side cipher, password, and plugin parameters must match field by field.

Supported ciphers:

The configuration is also compatible with some aliases that use different letter cases, underscores, or ss-2022-*; the user documentation only lists the recommended forms.

Supported plugins:

When using combinations, troubleshoot in this order:

• Disable the plugin first and verify only whether cipher/password/server/port works.

• Then enable the plugin and change only plugin and plugin-opts. If TCP works but UDP does not, first check the UDP behavior in the table above.

• plugin-opts.host, WebSocket path, Cloak serverName, and ShadowTLS/Restls versions are server-side agreements, not arbitrary "disguise domains" that can be changed freely.

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: ''

Key fields:

ShadowsocksR cipher / obfs / protocol combinations#

SSR configuration is determined by three things at the same time: cipher handles encryption, obfs controls traffic appearance, and protocol handles SSR authentication/fragmentation format. Link1 supports the following combinations:

These dimensions can be combined at the configuration layer, but whether they actually work depends on whether the SSR server uses the same combination. When troubleshooting SSR, do not look only at cipher. Any mismatch in obfs or protocol can result in no data after the connection is established, quick disconnections, or UDP issues.

shadowtls#

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

Key fields:

QUIC / High-Performance Proxy Protocols#

This group of protocols mainly runs over QUIC/UDP. They are usually friendlier to mobile networks, packet loss, and UDP traffic, but only if the local network, ISP, router, and upstream all allow UDP. If “TCP websites open, but video/games/QUIC do not work,” check udp, firewall rules, and upstream UDP support first.

The bandwidth fields up/down are important inputs for protocol scheduling and congestion control, not just display text. Setting them too high may cause packet loss; setting them too low may limit throughput.

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

Key fields:

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

Key fields:

faketcp depends on Linux raw-socket behavior, so Spark does not expose this non-cross-platform protocol feature.

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

Key fields:

Hysteria2 has very few optional obfuscation combinations. The following two forms are supported:

realm-opts is suitable when the server does not directly expose regular ports and forwarding must be coordinated through a realm server/STUN. After it is configured, server-url, token, realm-id, and at least one stun-servers entry must be provided. It cannot be used together with ports port hopping. realm-opts.proxy indicates the outbound used to access the realm control plane, and is not the same as the node’s own 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

Legacy protocol fields such as cipher, protocol, network, and plugin do not belong to Hysteria2. If these fields appear after conversion from another subscription format, they are usually ignored or rejected during validation.

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

Key fields: 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 uses an HTTP/2/HTTP/3-style upstream proxy. Key fields: username, password, tls, skip-cert-verify, servername, alpn.

Other Proxy Protocols#

Each protocol in this group has its own server ecosystem. Unlike VMess/VLESS, they do not share many transport fields, so the most important rule is to match the server documentation field by field: version, password/key, obfuscation, mask, padding, and UDP policy must all match.

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

Key fields:

Supported Snell version/obfuscation combinations:

network is handled as TCP behavior. Snell is not a generic WebSocket/TLS transport protocol and does not support transport sub-configurations such as ws-opts or 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 is a lightweight TCP outbound implementation for GOST relay v1. Link1 first connects to server:port, sends a relay CONNECT request, and then forwards subsequent TCP traffic to the target address. It is useful when a GOST relay server acts as a chained hop, or when it is used as the dialer-proxy for another outbound.

Key fields:

First-version limitations: TCP CONNECT only. udp: true, tls: true, and network: udp fail during configuration compilation. GOST relay TLS/mTLS, mux, and UDP forward/associate are intentionally out of scope for this phase.

anytls#

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

Key fields: 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

Key fields:

mieru#

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

Key fields: 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

Key fields:

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

Key fields:

Supported Sudoku security/obfuscation combinations:

Sudoku currently implements only TCP outbound networking. If network is configured, it can only be tcp or left empty.

L3 Tunneling and Networking Protocols#

The biggest difference between L3 tunnels and regular proxies is that they provide a “virtual network link”, not just CONNECT/SOCKS forwarding. DNS, routing, MTU, tunnel addresses, and allowed routes all affect which addresses can be reached.

Users should clearly distinguish between two routing layers:

• Link1 top-level rules: decides whether a connection selects this VPN outbound.

• Internal VPN protocol routing: decides which destination IPs are reachable inside the tunnel after entering the VPN.

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

Key fields:

WireGuard DNS and allowed-ips#

allowed-ips are the tunnel route prefixes for the WireGuard peer, not Link1 top-level rules. Providers usually supply 0.0.0.0/0 and ::/0, meaning all destinations after entering this outbound are allowed to go through this peer. If only enterprise intranet prefixes are provided, only those intranet IPs are reachable inside the tunnel.

dns and remote-dns-resolve are used to decide “where this domain name should be resolved”. VPN types default to remote-dns-resolve: true: when the destination is still a domain name, Link1 preferentially lets the VPN runtime resolve it using tunnel DNS. dns can manually specify tunnel DNS. If the runtime has no DNS provided by the server or configuration, enabling remote resolution will directly return an error and will not silently fall back to local DNS. To reuse local/global DNS, explicitly set 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

Key fields:

MASQUE DNS and URI#

The MASQUE uri is not just a normal URL. It describes where the HTTP/3 MASQUE server accepts CONNECT-UDP/IP. server/port decides which endpoint to connect to, sni/servername decides the TLS handshake domain name, and uri decides the MASQUE request target. These three may be the same, or they may be provided separately by the provider.

dns and remote-dns-resolve have meanings similar to WireGuard: they control domain resolution after entering the MASQUE tunnel. VPN MASQUE defaults to remote-dns-resolve: true; it can be explicitly set to false to fall back to local/global DNS. For WARP MASQUE, the provider materializes the DNS and remote resolve parameters from the WARP state into the generated MASQUE node.

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

Key fields:

By default, route-rule-set directly uses the proxy name with a $ prefix. If the proxy name or explicit rule set name contains a comma, the automatically injected RULE-SET is wrapped in double quotes and escaped according to the common rule syntax.

Tailscale MagicDNS#

Tailscale outbound defaults to remote-dns-resolve: true. When a rule sends a domain destination to this outbound, Link1 first queries MagicDNS / tailnet DNS through the embedded Tailscale runtime DNS manager, then uses the resolved tailnet IP to establish the connection. If Tailscale DNS does not return an address, an error is returned and it will not silently fall back to local DNS. To reuse local or global DNS, explicitly set remote-dns-resolve: false.

Global DNS can also directly reference a Tailscale outbound:

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

tailscale://tailnet and ts://tailnet are equivalent. Both mean “use the MagicDNS / tailnet DNS provided by the Tailscale outbound named tailnet”.

dialer-proxy applies to Tailscale’s own system dialing path: control-plane, DERP/relay, and peer direct connections all prefer the specified outbound. The current implementation uses a trimmed Tailscale fork in Link1 and connects the underlying WireGuard path to Link1’s internal WireGuard. The goal is to keep only the subset required for outbound use while preserving room for future WireGuard variant extensions.

openvpn#

OpenVPN outbound is not a regular “remote proxy port”; it is a full VPN client. Link1 first establishes a control channel with the OpenVPN server, completes TLS/certificate/username-password authentication, then creates a userspace tunnel network and places connections selected by rules into this tunnel. When dialer-proxy is configured, the underlying TCP/UDP channel used by OpenVPN to connect to the remote first goes through the specified outbound. UDP remotes require the upstream outbound to support UDP.

Its data flow can be understood as:

App connection
  -> Link1 rules select ovpn-node
  -> OpenVPN userspace netstack
  -> OpenVPN control/data channel
  -> VPN server
  -> Enterprise intranet or public target

Minimal example:

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

Multiple remote example:

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 Field Reference#

By default, route-rule-set directly uses the proxy name with a $ prefix. If the proxy name or explicit rule set name contains a comma, the automatically injected RULE-SET is wrapped in double quotes and escaped according to the common rule syntax.

Common unsupported fields:

• tls, alpn, client-fingerprint, reality-opts, ech-opts, ws-opts, grpc-opts: these are regular proxy/TLS transport fields, not OpenVPN configuration.

• auto-setup-routes: this is an enterprise VPN-style field, not an OpenVPN outbound field. OpenVPN uses route-rule-set and auto-route.

How OpenVPN DNS Works#

OpenVPN DNS has three source layers, in descending priority:

1. DNS pushed by the server: the OpenVPN server may send dhcp-option DNS 10.8.0.1 in PUSH_REPLY. Link1 records it in the OpenVPN runtime snapshot.

1. The dns field in the node: if the server does not push DNS, you can manually set dns: [10.8.0.1].

1. Global Link1 DNS: when remote-dns-resolve: false, or when a DNS query is not part of an outbound dialing target, normal DNS still follows global configuration such as dns.nameserver and nameserver-policy.

OpenVPN defaults to remote-dns-resolve: true. Domain destinations selected by rules and entering the OpenVPN outbound are resolved by the OpenVPN runtime using pushed/configured DNS. If no VPN DNS is available, an error is returned instead of falling back to local DNS.

If you need certain enterprise domains in the global DNS policy to explicitly call the internal OpenVPN DNS, write openvpn://<node-name> in dns.nameserver-policy:

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

Meaning:

• Normal domains still use the default nameserver.

• Enterprise domains such as corp.example.com call the remote DNS capability of ovpn-node.

• ovpn-node must already be able to establish an OpenVPN runtime and have DNS servers in its snapshot; otherwise, it reports “no remote dns servers” or remote resolution failure.

openvpn://ovpn-node and remote-dns-resolve use the same type of remote DNS capability, but have different entry points: the former is a nameserver in the global DNS policy, while the latter is the resolution policy used when the OpenVPN outbound dials a target domain.

How OpenVPN Routing Works#

The OpenVPN server may push routes, such as route 10.0.0.0 255.0.0.0 or IPv6 routes. Link1 records these prefixes in the runtime snapshot of that node.

route-rule-set exposes these prefixes as a dynamic 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

When auto-route: true, Link1 automatically inserts a rule like the following before MATCH:

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

Note: OpenVPN dynamic route rule-sets mainly match IP prefixes pushed by the server. For enterprise domains, it is still recommended to point them to openvpn://ovpn-node through dns.nameserver-policy. After they resolve to enterprise intranet IPs, the routing rules can then match them.

Common OpenVPN Issues#

WARP provider#

WARP is Cloudflare's dynamic egress capability. Link1 does not design it as proxies[].type=warp, but as proxy-providers.type=warp. The reason is that WARP is not a fixed leaf node, but a "node source" that generates nodes.

Why it must be a provider:

1. One WARP configuration may generate multiple egresses: the same WARP state can materialize both wireguard and masque node types.

1. auto mode requires persistent state: accounts, keys, endpoints, reserved bytes, MASQUE parameters, and other data need to be managed and reused.

1. It naturally fits policy group selection: nodes generated by the provider can enter policy groups such as select, url-test, and fallback, where users or health checks choose them.

1. It is not a subscription download: the WARP provider does not use subscription fields such as url, path, format, and proxy; it builds local nodes from WARP state.

1. Avoid configuration ambiguity: if proxies[].type=warp were allowed, users would assume it behaves like a normal protocol with only one fixed server/port. In reality, WARP must first determine the transport and state source.

Most common example:

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

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

rules:
  - MATCH,WARP

Meaning of this configuration:

• The warp provider generates WARP nodes.

• transports specifies which types to generate. It supports masque and wireguard.

• If both transports have available state, nodes similar to warp MASQUE and warp WIREGUARD will appear in the group.

• The WARP policy group lets users choose a specific WARP transport, or work with an automatic group for health-based selection.

WARP auto Mode Fields#

Discovery fields that are no longer supported: probe-timeout, count, wg-candidates, masque-candidates. These fields belong to the old discovery design and will be rejected if written in the configuration.

WARP manual Mode Fields#

manual mode is suitable when you already have complete WARP parameters and do not want Link1 to automatically generate state.

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 mode rules:

• When transports includes wireguard, the wireguard sub-block must be provided.

• When transports includes masque, the masque sub-block must be provided.

• license-key can only be used in auto mode.

• Top-level handshake-mode is not supported. WARP MASQUE internally uses fixed compatible handshake semantics.

What Nodes the provider Generates#

The WARP provider eventually generates normal Link1 outbound nodes:

Therefore, subsequent policy groups, rules, and health checks operate on these generated nodes, not directly on warp. This is also the fundamental reason why warp must be placed under a provider.

Common WARP Issues#

Enterprise VPN Protocols#

Enterprise VPN protocols depend on the target server version, login policy, CAPTCHA, device binding, and enterprise security policy. They are more like “using an enterprise VPN as a Link1 outbound” than ordinary subscription nodes.

Enterprise VPNs usually return two types of dynamic information:

• Enterprise DNS: used to resolve domain names that exist only on the corporate intranet.

• Enterprise routes: used to determine which intranet IPs should go through the VPN.

Therefore, these protocols are often used together with dns.nameserver-policy, route-rule-set, and policy groups, instead of blindly sending all traffic to the enterprise 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

Key fields:

Limitations: does not support fields for ordinary proxies such as TLS/QUIC/network. dialer-proxy applies to both the login control plane and the underlying enterprise tunnel connection.

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

Key fields:

easyconnect#

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

Key fields:

Automatic injection of dynamic enterprise VPN route-rule-set follows the general rule syntax as well. If the proxy name or rule set name contains a comma, the corresponding field is automatically quoted.

Limitations: does not support fields for ordinary proxies such as TLS, QUIC, and network. dialer-proxy applies to both the login control plane and tunnel data connection.

Inbound Protocol Listeners#

Although this chapter mainly covers outbounds, Link1 can also act as a server for some protocols.

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

Key fields: 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

Key fields: users, certificate, private-key, up, down, obfs, obfs-password, max-idle-time, alpn, ignore-client-bandwidth, masquerade, proxy.

Protocol Selection Recommendations#

Compatibility Boundaries#

• A field appearing in the unified ProxyConfig does not mean every protocol supports it.

• Link1 will try to report “unsupported fields” at compile time.

• Enterprise VPN protocols are affected by server-side policies, so availability across all enterprise versions cannot be guaranteed.

• skip-cert-verify is recommended only for testing or self-signed certificate scenarios.

• dialer-proxy changes the dial chain. After it is configured for some protocols, direct-dial fields such as ip-version, interface-name, and routing-mark are disabled.