1. Project and Proxy Basics#

What Problems Link1 Solves#

When a device accesses the network, the operating system creates many connections: browsing websites, syncing messages in chat apps, system updates, DNS queries, LAN devices accessing internal services, and more. Link1 takes over these connections and decides, according to your configuration:

• Whether to connect directly to the target server.

• Whether to reject the connection.

• Whether to use a proxy protocol node.

• Whether to use an enterprise VPN, WireGuard, MASQUE, Tailscale, OpenVPN, or WARP exit.

• Whether to debug, rewrite, mock, or capture traffic at the HTTP layer.

Link1 consists of two layers:

You do not need to understand every protocol at the beginning. Start with four terms: inbound, DNS, rules, and outbound.

Your app/device
  -> Inbound: how traffic enters Link1
  -> DNS: how domains become IPs, or how IPs are mapped back to domains
  -> Rules: which exit this connection should use
  -> Outbound: which protocol Link1 uses to actually connect out

What Is an Inbound#

An inbound is an entry point where Link1 receives connections. Different entry points fit different use cases:

For first-time use, start with mixed-port, because it is the easiest to understand and verify. After you confirm that the proxy path works, try TUN or router transparent proxy.

What Is DNS#

DNS converts domain names into IP addresses, for example resolving www.example.com to 93.184.216.34. DNS in a proxy core is not just “looking up domains”; it also affects whether routing rules can match.

For example:

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - IP-CIDR,10.0.0.0/8,DIRECT

If Link1 sees the domain name chat.openai.com, the first rule can match. If Link1 sees only an IP address, it may need DNS mapping, Fake-IP, or Sniffer to recover the domain name.

DNS configuration determines three things:

1. Whether Link1 handles DNS queries itself.

1. Whether domain rules can match in transparent proxy/TUN scenarios.

1. Whether domestic and international domains can use different upstream DNS servers to avoid inaccurate resolution results.

What Is an Outbound Protocol#

An outbound protocol is the way Link1 connects out. Common types include:

Outbound nodes are defined in proxies; subscriptions or dynamic nodes are defined in proxy-providers. Regular users most often interact with node names, protocol types, server addresses, ports, passwords/keys, and TLS/UDP switches.

What Are Rules and Policy Groups#

Rules decide where a connection goes. Policy groups put multiple outbounds together so that the user or Link1 can choose one of them automatically.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - node-a
      - node-b
      - DIRECT

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,DIRECT

The example means:

• Access to *.google.com is sent to the PROXY group.

• Whichever node is currently selected in the PROXY group will be used.

• All other traffic connects directly.

A policy group is not a protocol. select, url-test, fallback, and load-balance describe “how to choose a node”; the actual remote connection is made by the outbound protocol inside the group.

What Are Link1 App Management Capabilities#

Link1 does not expose user-facing management as something regular users need to call manually. Instead, the App provides:

• Configuration profiles: import, validate, apply, and switch configurations.

• Connection list: view current connections, target addresses, matched rules, and used outbounds.

• Policy groups: view available nodes, switch manually, and trigger latency tests.

• Provider: view subscriptions, refresh subscriptions, and observe health check results.

• DNS and rule testing: enter a domain/IP/inbound condition to confirm which rule will match.

• Logs: view startup errors, DNS errors, dialing errors, rule matches, and protocol handshake issues.

• HTTP capture: after enabling HTTP Engine Capture, view request/response summaries and body previews.

Therefore, the user manual will not ask you to call core management APIs. You only need to understand which layer of the data flow the information on each App page comes from, so you know what to check next during troubleshooting.

What Is HTTP Engine#

HTTP Engine is an advanced feature for HTTP/HTTPS debugging and rewriting. It can:

• MITM-decrypt specified HTTPS domains.

• Rewrite, redirect, or reject URLs.

• Rewrite headers.

• Rewrite bodies.

• Transform JSON.

• Process with JQ.

• Run QuickJS scripts.

• Mock responses.

• Capture and replay traffic.

Regular proxy users do not need to enable HTTP Engine at the beginning. It is better suited for debugging Web requests, supporting closed-source clients, and temporarily patching request/response formats. Before enabling HTTPS MITM, you must understand the certificate trust risks: only domains that you explicitly need to observe or rewrite should be added to the MITM list.

Common Beginner Confusions#

A Proxy Port Is Not a Server Port#

mixed-port: 7890 is the local port where your browser connects to Link1; it is not the port of the remote proxy server.

mixed-port: 7890       # local inbound
proxies:
  - server: example.com
    port: 443          # remote node port

DNS Matching Affects Rule Matching#

If you write domain rules but let system DNS bypass Link1, Link1 may see only IP addresses in transparent proxy scenarios. In that case, you need to use Link1 DNS, Fake-IP, TUN DNS hijack, or Sniffer.

A Policy Group Is Not a Protocol#

select, url-test, and fallback are selection policies, not network protocols. The actual outbound connection is made by the nodes inside the group.

DIRECT Does Not Mean Bypassing Link1#

The connection still enters Link1 first; Link1 simply chooses to connect directly to the target server in the end. You can still see the connection, rule, and outbound result in the App.

“Node Unavailable” in the App Does Not Necessarily Mean the Password Is Wrong#

A node may be unavailable due to DNS, network blocking, unreachable server, TLS fingerprint mismatch, UDP failure, incorrect subscription fields, an unreachable upstream dialer-proxy, and other reasons. During troubleshooting, check in this order: “inbound → target identification → rules → policy group → outbound protocol.”