2. Core Concepts and Data Flow#

This chapter explains how a connection flows inside Link1. Once you understand this path, the configuration fields will be easier to read.

Overall Data Flow#

Client connection
  -> Inbound listener
  -> Authentication and LAN access control
  -> Target address identification
  -> DNS / Fake-IP / Hosts / Sniffer
  -> Rule engine
  -> Policy group selection
  -> Outbound protocol dialing
  -> Traffic forwarding
  -> Link1 App displays status

Every step can be affected by configuration. The connections, logs, proxy group status, and HTTP captures you see in the App are all generated at different stages of this chain.

1. Client Connections Enter Link1#

Entry points may include:

• A browser connecting to mixed-port through an HTTP proxy.

• An app connecting to socks-port through SOCKS5.

• A router redirecting TCP traffic to redir-port.

• Linux TPROXY redirecting TCP/UDP traffic to tproxy-port.

• The system sending all IP packets to a TUN virtual network interface.

• An external client connecting to listeners with VLESS/Hysteria2.

The entry point generates metadata: inbound type, inbound name, inbound port, source IP, source port, user, network type, and more. Rules can use this metadata, for example:

rules:
  - IN-TYPE,tun,PROXY
  - SRC-IP-CIDR,192.168.9.0/24,DIRECT

Practical effect: the same destination can match different rules when it enters through different entry points. For example, you can route browser proxy traffic through PROXY while letting LAN devices transparently handled by the router go DIRECT.

2. Access Control and Authentication#

If you expose Link1 to the LAN, you need to understand four types of fields:

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

Practical effects:

• When allow-lan=false, explicit proxy entry points are available only to the local machine by default.

• bind-address='*' or 0.0.0.0 makes ports listen on all network interfaces.

• lan-allowed-ips / lan-disallowed-ips further restrict which LAN devices can use Link1 by source IP.

• authentication can require HTTP/SOCKS clients to provide a username and password.

Beginner recommendation: keep allow-lan=false at first. After local testing succeeds, then expose it to the LAN. When exposing it to the LAN, restrict the subnet or use username/password authentication.

3. Destination Address Identification#

Different entry points provide different destination information:

Therefore, DNS configuration is critical in transparent proxy and TUN scenarios. Without a domain, rules such as DOMAIN-SUFFIX and GEOSITE may not match as expected.

4. DNS, Fake-IP, and Sniffer#

Link1 uses the following information to recover “what the user originally wanted to access”:

1. hosts: static domain mappings.

1. Link1 DNS resolver: resolves using fields such as dns.nameserver.

1. Fake-IP: assigns a virtual IP to a domain. Later, when a connection targets this virtual IP, Link1 can look up the original domain.

1. Sniffer: sniffs domains from HTTP Host, TLS SNI, and QUIC SNI.

1. Original transparent proxy destination: uses the original IP when the domain is unavailable.

Recommended configuration approach for transparent proxy/TUN:

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

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]
    QUIC:
      ports: [443]

Practical effects:

• Fake-IP can improve the match rate of domain rules.

• dns-hijack can route DNS queries from devices into Link1.

• Sniffer can compensate for connections that did not go through Link1 DNS.

• Over-reliance on Sniffer increases first-packet identification overhead, and not all protocols can be sniffed.

5. Rule Engine#

Rules are evaluated in order. Evaluation stops at the first match.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Practical effects:

• Earlier rules have higher priority.

• MATCH should be placed last as the fallback.

• no-resolve prevents some IP rules from triggering DNS resolution.

• RULE-SET can reference a large number of rules and is suitable for rule subscriptions.

• AND / OR / NOT are suitable for complex conditions.

• SUB-RULE is useful for extracting a block of rules for reuse.

The rule testing feature in the App essentially lets you construct a “virtual connection” and see which rule it matches. It does not actually access the target website, so it is useful for troubleshooting rule order and metadata correctness.

6. Proxy Group Selection#

A rule action can point to a specific node or to a proxy group:

proxy-groups:
  - name: AUTO
    type: url-test
    proxies: [node-a, node-b]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - MATCH,AUTO

Practical effects of proxy groups:

The Link1 App displays the current selection, available members, latency, and health status of proxy groups. For select groups, the user’s selection is usually persisted. For automatic groups, the selection result changes with probe results.

7. Outbound Protocol Dialing#

The outbound protocol establishes the actual connection to the remote endpoint. For example:

• direct connects directly to the target.

• http / socks5 connects to an upstream proxy.

• hysteria2 connects to a Hysteria2 server over QUIC.

• wireguard establishes an L3 tunnel.

• openvpn connects to an OpenVPN remote.

• warp provider materializes WireGuard/MASQUE candidates.

Protocol fields affect:

• Whether authentication succeeds.

• TLS handshake behavior.

• Whether UDP is available.

• Whether a network interface or routing mark is bound.

• Whether another dialer-proxy is used as a preceding outbound.

• Whether extensions such as TFO/MPTCP/SMUX/UDP-over-TCP are enabled.

Outbound errors usually include the node name, protocol type, remote address, or handshake stage in the logs. When you see an error, first confirm whether “the node cannot connect” or “the rules did not route traffic to this node.”

8. How Status Returns to the Link1 App#

After a connection starts, the Link1 App can show:

• Current connection list: source address, destination address, network type, inbound, outbound, and matched rule.

• Upload/download traffic: total traffic, per-connection traffic, and real-time rate.

• Proxy group status: current selection, member latency, and health check history.

• Provider status: subscription refresh time, number of nodes, filtering results, and health check results.

• DNS results: domain resolution, Fake-IP mappings, and upstream selection.

• Logs: startup, configuration compilation, DNS, rules, protocol handshakes, and dialing failures.

• HTTP Engine captures: request/response summaries, matched rules, body preview, or on-disk location.

This information is used for troubleshooting, but it is not a new data path. Actual data still flows along “inbound → rules → outbound”.

Data Flow in Four Common Scenarios#

Scenario A: Manually Configuring a Proxy on a Computer#

Browser
  -> 127.0.0.1:7890 mixed-port
  -> Link1 receives the target domain directly
  -> rules
  -> PROXY / DIRECT

Advantage: easiest to verify. Disadvantage: only apps configured with the proxy are handled.

Scenario B: Global Takeover with TUN#

System routing
  -> TUN virtual interface
  -> Link1 restores the domain via DNS/Fake-IP/Sniffer
  -> rules
  -> Outbound

Advantage: apps do not need separate proxy settings. Disadvantage: DNS configuration, route exclusions, and system permissions become more important.

Scenario C: Router Transparent Proxy#

LAN device
  -> Default gateway
  -> Router firewall/TUN
  -> Link1
  -> rules
  -> Outbound

Advantage: LAN devices do not need to install the App. Disadvantage: if DNS is not taken over, domain rules may fail.

Scenario D: Link1 as a Protocol Server#

Remote client
  -> VLESS/Hysteria2 listener
  -> Link1 reads the target from the protocol payload
  -> rules
  -> Outbound

Advantage: Link1 can be used as a relay or entry point. Disadvantage: you must handle server certificates, user authentication, port exposure, and security boundaries.

Data Flow Troubleshooting Checklist#

When asking “why didn’t it use the expected node?”, troubleshoot in this order:

1. Did the traffic enter Link1? Check the client proxy, TUN status, router forwarding, or listener.

1. Does Link1 know the destination domain? Check DNS/Fake-IP/Sniffer and connection details.

1. Did the rules match as expected? Use the App’s rule test, or check the matched rule in connection details.

1. Does the group or node for the action exist? Check the proxy group and Provider pages.

1. Which member is currently selected by the proxy group? Check the group’s current selection in the App.

1. Is the node healthy? Check latency tests, health checks, and logs.

1. Are the outbound protocol fields correct? Check startup errors, handshake errors, and protocol configuration.