5. Inbounds and Traffic Capture#

Inbounds determine how traffic enters Link1. This chapter introduces them from basic to advanced.

Inbound Overview#

Explicit Proxy Entrances#

mixed-port#

mixed-port: 7890

Meaning: accepts both HTTP proxy and SOCKS5 requests on the same port.

Practical impact:

• Best for beginners and desktop users.

• Works with browsers, system proxy settings, and curl.

• SOCKS5 clients can also connect to this port.

port#

port: 7891

Meaning: enables only an HTTP proxy entrance.

Practical impact:

• Clients must use the HTTP proxy protocol.

• HTTPS sites are tunneled through HTTP CONNECT.

socks-port#

socks-port: 7892

Meaning: enables only a SOCKS5 entrance.

Practical impact:

• Clients can either resolve DNS locally or pass domain names to SOCKS5.

• If the client passes IP addresses to Link1, domain-based rules may not match.

Listen Address and LAN Access#

allow-lan: true
bind-address: '*'
authentication:
  - alice:password
skip-auth-prefixes:
  - 127.0.0.1/32
lan-allowed-ips:
  - 192.168.0.0/16
lan-disallowed-ips:
  - 192.168.9.99/32

Field impact:

Transparent Proxy Entrances#

Transparent proxying sends traffic into Link1 through system routes or firewall rules, without requiring clients to configure a proxy manually.

redir-port#

redir-port: 7893

Meaning: Linux REDIRECT TCP transparent proxy entrance.

Practical impact:

• Commonly used for TCP transparent proxying on OpenWrt/routers.

• Requires iptables/nftables rules to redirect TCP traffic to this port.

• Mainly handles TCP and is not the preferred choice for UDP.

tproxy-port#

tproxy-port: 7894

Meaning: Linux TPROXY transparent proxy entrance.

Practical impact:

• Better suited for TCP + UDP transparent proxying.

• Requires Linux policy routing together with iptables/nftables.

• Non-Linux platforms reject it at compile time.

Conflict with TUN#

If TUN auto-route or auto-redirect is enabled while redir-port/tproxy-port is also used, the same traffic may be captured twice. Link1 checks for these conflicts during configuration compilation.

Application Transparent Proxy app-proxy#

app-proxy:
  enable: true
  bypass-self: true
  fail-open: true

app-proxy is a per-application transparent proxy entrance for desktop systems. It uses platform capabilities to capture traffic initiated by applications, passes metadata such as destination address, process name, process path, and Bundle ID to the Link1 core, and then lets normal rules decide which policy group or outbound to use.

User configuration only exposes the app-proxy concept. You do not need to, and cannot, specify the underlying backend. Link1 selects the internal implementation by runtime platform: Network Extension on macOS/Darwin, WinDivert on Windows, and NFQUEUE on Linux. The platform capture layer only passes traffic and process metadata to the core; it does not maintain a second rule engine.

macOS App Proxy requires the host App/Extension to have the relevant Apple Network Extension entitlements, such as the App Proxy capability under com.apple.developer.networking.networkextension. The Go core in the current repository already provides app-proxy integration, metadata passthrough, and fallback protection for self-traffic. Actual Network Extension installation/authorization still depends on macOS app packaging and developer account configuration.

Field impact:

Practical impact:

• Suitable for desktop scenarios where you do not want global TUN but still want transparent per-application capture.

• Process matching is still written in rules, such as PROCESS-NAME and PROCESS-PATH; the platform layer does not maintain a second rule engine.

• Cannot be enabled together with tun, to avoid capturing the same traffic twice.

• bypass-self is a core-side fallback against recursion: if the platform bridge misses Link1's own traffic, Link1 rejects such self-captured flows to avoid infinite recursion. Truly transparent bypass still requires the platform bridge to exclude the Link1 process.

• Windows uses WinDivert for packet rewrite and then forwards traffic into the local app-proxy relay; administrator privileges and a loadable WinDivert driver/DLL are required.

• Linux uses NFQUEUE + mark + REDIRECT and then forwards traffic into the local app-proxy relay; root/CAP_NET_ADMIN, kernel NFQUEUE support, and available iptables are required.

TUN Inbound#

TUN creates a virtual network interface and lets the system hand IP packets to Link1.

Explicit proxies only capture applications that are willing to use a proxy. TUN is more like inserting a virtual network interface into the system. The system first sends IP packets originally destined for the internet to this virtual interface, and Link1 then decides how to send them out based on DNS, Sniffer, rules, and policy groups. It is suitable for applications that do not support proxy settings, global capture on mobile/desktop, and router gateway mode.

Why TUN Often Needs DNS Hijacking and Fake-IP#

The most common beginner issue is: TUN is enabled and websites load, but DOMAIN-SUFFIX rules do not match. The reason is that the TUN layer naturally sees IP packets, which usually only contain the "destination IP:port" and may not contain the original domain name.

DNS hijacking and Fake-IP can be understood like this:

The app queries www.example.com
  -> Link1 DNS returns a Fake-IP, for example 198.18.1.23
  -> The app connects to 198.18.1.23:443
  -> TUN hands the connection to Link1
  -> Link1 maps the Fake-IP back to www.example.com
  -> Domain rules can match

If DNS is not captured, the application may first obtain a real IP from the system DNS and then send that real IP directly into TUN. Link1 can still handle it with IP-based rules, and it can also try to recover the domain name from TLS SNI/HTTP Host/QUIC SNI using Sniffer. However, this is not reliable for every connection: some applications encrypt SNI, reuse connections, access IPs directly, or cause sniffing to fail during the UDP/QUIC phase.

Therefore, the recommended TUN combination is:

• dns.enable: true: let Link1 handle DNS.

• dns.enhanced-mode: fake-ip: establish mappings between domains and Fake-IP addresses.

• tun.dns-hijack: [any:53]: route DNS queries from the device into Link1.

• sniffer.enable: true: use connection content as a supplement to help recover domain names, but do not treat it as a replacement for DNS.

Domains that are not suitable for Fake-IP should be added to fake-ip-filter, such as router management domains, LAN discovery, printers, casting, .local / .lan, and similar names. Otherwise, applications may fail to complete LAN discovery after receiving a Fake-IP.

Minimal TUN Example#

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

tun:
  enable: true
  backend: auto
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Core TUN Fields#

TUN Routing Fields#

Default exclusions protect common intranet/reserved addresses, such as 10.0.0.0/8, 192.168.0.0/16, and 127.0.0.0/8, to avoid incorrectly sending management traffic into TUN.

TUN Selector Fields#

These fields only affect which local traffic enters TUN and are mainly used on Linux/Android:

If auto-route=false, these route selectors are reset to zero or do not take effect, because Link1 is not responsible for automatic routing.

Linux Policy Routing Fields#

Sniffer#

Sniffer identifies domain names from connection content.

sniffer:
  enable: true
  override-destination: true
  force-dns-mapping: true
  parse-pure-ip: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443]
    QUIC:
      ports: [443]
  force-domain:
    - '+.example.com'
  skip-domain:
    - '+.lan'
  skip-src-address:
    - 192.168.0.0/16

Field impact:

Protocol Listeners#

listeners lets Link1 act as a server and accept protocol connections. Current configuration validation accepts: mixed, http, socks, redir, tproxy, tun, vless, and hysteria2. The main server-side protocols are VLESS and Hysteria2.

For details, see Outbound Protocol Configuration: Inbound Protocol Listeners.