Link1 User Manual#
Slogan: One link. Every protocol.
Link1 is a proxy and network takeover app for general users. You can think of it as a “software router” running on your computer, phone, or router: it receives network connections from browsers, the system, mobile apps, routers, or LAN devices, identifies where each connection wants to go, and then, according to your configuration, chooses to connect directly, reject it, or send it through a proxy/VPN egress.
The Link1 App is responsible for importing configurations, displaying nodes, switching policy groups, viewing connections, viewing logs, and troubleshooting. The underlying core handles the actual DNS, routing, protocol dialing, and data forwarding. In some scenarios where the core is run directly, the command name may still appear as spark. This manual refers to it as the “Link1 core”.
This documentation is intended for users who have never used Clash or mihomo. It only assumes basic computer knowledge: what IP addresses, ports, domain names, HTTP, DNS, and configuration files are. After reading this manual, you should understand:
- Where Link1’s data flow enters, where it is resolved, where it is routed, and where it exits.
- What the Link1 App and the underlying core are each responsible for.
- What each major configuration block in
config.yamldoes.
- What real behavior each configuration parameter changes.
- How to configure each outbound protocol.
- How to troubleshoot issues using the Link1 App, logs, the connection list, and rule tests.
Reading Path#
If this is your first time using Link1, read the first 6 chapters in order. If you only need to look up fields, you can jump directly to the reference manual.
| Chapter | Document | What you will learn |
|---|---|---|
| 1 | Project and Proxy Basics | What problems Link1 solves, and what explicit proxy, transparent proxy, TUN, DNS, and outbound protocols are |
| 2 | Core Concepts and Data Flow | The complete path of a connection from entering Link1 to going outbound |
| 3 | Installation, Startup, and Verification | How to import a configuration in the App, validate it, start the core, and connect clients |
| 4 | Configuration File Model | YAML structure, relative paths, naming, references, default values, and common errors |
| 5 | Inbound and Traffic Takeover | mixed-port, port, socks-port, redir-port, tproxy-port, tun, app-proxy, listeners |
| 6 | DNS and hosts | DNS server syntax, Fake-IP, DNS routing, hosts, fallback, nameserver-policy |
| 7 | Routing, Rules, and Policies | rules, rule-providers, logical rules, rule sets, policy groups, health checks |
| 8 | Providers and Policy Groups | Subscriptions, files, inline providers, WARP providers, node filtering, overrides, group selection |
| 9 | Outbound Protocol Configuration | How each outbound protocol works, how to write it, and how fields affect DNS/routing/transport/authentication |
| 10 | HTTP Engine | MITM, URL/Header/Body/JSON/JQ/QuickJS, Capture, Replay |
| 11 | Link1 App Management | App operations for configuration profiles, connections, policy groups, Providers, logs, rule tests, and HTTP capture |
| 12 | Observability and Troubleshooting | Common issues, troubleshooting order, and how to read errors and metrics |
| 13 | Glossary | Quickly look up unfamiliar proxy core terminology |
| 14 | Configuration Field Reference | Complete fields for top-level options, DNS, TUN, Sniffer, Provider, HTTP Engine, and more |
| 15 | Coverage Index | Which feature modules, protocols, App management capabilities, and configuration structures are covered by the manual |
Minimal Runnable Configuration#
The configuration below opens only one local mixed HTTP/SOCKS proxy port and sends all connections to a SOCKS5 upstream. It is suitable for confirming that the Link1 core can start and that clients can connect.
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
proxies:
- name: example-socks
type: socks5
server: 127.0.0.1
port: 1080
udp: true
proxy-groups:
- name: PROXY
type: select
proxies:
- example-socks
- DIRECT
rules:
- MATCH,PROXY
When using it in the Link1 App, the usual flow is:
Create a configuration profile
-> Paste or import YAML
-> Validate configuration
-> Apply configuration
-> Confirm runtime status on the home page
Configure your browser or system proxy to use:
HTTP proxy: 127.0.0.1:7890
SOCKS proxy: 127.0.0.1:7890
Advanced: Run the Link1 Core Directly#
General desktop users do not need to use the command line. You only need to run the core directly for router deployments, troubleshooting, automated testing, or development debugging.
Validate the configuration:
spark -f config.yaml -t
Start:
spark -d /path/to/workdir -f config.yaml
Example Configurations#
The manual includes several copyable YAML examples:
| Example | Purpose |
|---|---|
| desktop-mixed-direct.yaml | Minimal local explicit proxy, all traffic connects directly |
| desktop-mixed-proxy.yaml | Local explicit proxy + SOCKS5 upstream |
| router-tun-fakeip.yaml | TUN + Fake-IP + Sniffer template |
| warp-provider.yaml | WARP provider template |
| http-engine-capture.yaml | HTTP Engine Capture template |
| all-in-one-tun-http-engine.yaml | Comprehensive DNS/Fake-IP + TUN + Sniffer + HTTP Engine skeleton |
Where to Start Writing a Complete Configuration#
Recommended configuration order:
- Basic runtime parameters:
mixed-port,allow-lan,mode,log-level.
- DNS: first decide whether Link1 should take over DNS, and whether to use Fake-IP.
- Outbounds: write
proxiesorproxy-providers.
- Policy groups: write
proxy-groupsto organize nodes into selectable egresses.
- Rules: write
rulesto direct traffic to policy groups or nodes.
- System takeover: only then enable
tun,redir-port,tproxy-port, or protocollisteners.
- Advanced features: enable
http-engineonly when you need to debug HTTP content.
The benefit of this order is that each step can be verified independently. Do not enable TUN, complex DNS, subscriptions, dozens of rules, and HTTP Engine all at the same time from the start. Otherwise, it will be hard to tell which layer caused a problem.
Relationship with Clash/mihomo#
Link1 tries to follow common proxy core configuration conventions, such as mixed-port, dns, proxies, proxy-groups, rule-providers, and rules. However, Link1 is not a wrapper around another project: protocol implementations, the rule engine, TUN, HTTP Engine, and App management capabilities are all implemented by the Link1 core system.
This means:
- You can use existing subscriptions or common YAML configurations as a starting point for migration.
- You cannot assume every historical field from other cores is supported by default.
- Link1 will try to tell you during configuration compilation “which field is unsupported at which location”.
warpis not used as a regularproxiesleaf. It should materialize nodes throughproxy-providers.type=warp.
Documentation Conventions#
config.yamlindicates the main Link1 configuration file.
proxies[].type=httpmeans thetypefield of a node in theproxieslist ishttp.
- “Inbound” means an entry point where traffic enters Link1.
- “Outbound” means the egress where Link1 finally connects to the target or an upstream proxy/VPN.
- “Policy group” means a collection of egresses that can be referenced by rules.
- “Rule” means a matching condition that decides which egress a connection uses.
- “Core command” means running the underlying binary directly. General users should operate through the Link1 App first.