3. Install, Start, and Verify#
This chapter focuses only on the user perspective: how to prepare a configuration, import and apply it in the Link1 App, verify the configuration when running the core directly, and confirm that the proxy is working.
Recommended Method: Manage with the Link1 App#
Regular users are advised to complete the following workflow through the Link1 App:
- Create a new configuration profile.
- Paste YAML, import a local file, or enter a subscription URL.
- Click validate to confirm there are no field errors or reference errors.
- Apply the configuration and wait for the core to finish starting.
- On the App home page, confirm the running status, current mode, real-time speed, and log summary.
- Enable system proxy, TUN, or router mode so traffic enters Link1.
- Use the connection list, policy groups, and logs to confirm traffic is forwarded as expected.
The App automatically handles the internal management channel, status synchronization, and page display. Users usually do not need to write additional management configuration manually.
Configuration File Location#
The default configuration file name is config.yaml. If you run the core directly, you can specify it with -f:
spark -f /path/to/config.yaml
Specify the working directory with -d:
spark -d /path/to/workdir -f /path/to/config.yaml
Practical effects:
- Relative paths are resolved based on the configuration file directory or the working directory.
- provider caches, state databases, Fake-IP persistence, and downloaded subscription files are usually related to the working directory.
- For router deployments, it is recommended to use a fixed working directory to avoid relative path changes after reboot.
- If you use the App, the working directory is generally managed by the App. You only need to focus on the configuration profile itself.
Common Command-Line Arguments for Users#
| Argument | Meaning | Practical effect |
|---|---|---|
-f | Specify the configuration file | Reads the specified YAML |
-d | Specify the working directory | Affects relative paths, caches, and state files |
-config | Use base64-encoded configuration content | Suitable for the App or external configuration managers to deliver configurations directly |
-t | Test the configuration and exit | Does not start listening ports; only checks whether the configuration can be compiled |
-v | Print version | Used to confirm the binary version |
-m | Override and enable geodata-mode | Temporarily switch GeoData mode |
These arguments are mainly used for troubleshooting, router deployments, or development debugging. Desktop users should prioritize the configuration import and validation buttons in the Link1 App.
Step 1: Write a Minimal Configuration#
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
If you do not have an upstream proxy yet, you can also use direct connection only to verify that the core can start:
mixed-port: 7890
mode: rule
log-level: info
rules:
- MATCH,DIRECT
Step 2: Verify the Configuration#
In the App, click “Validate Configuration”. If running the core directly:
spark -f config.yaml -t
If the configuration is invalid, Link1 will try to tell you the path, for example:
compile config "config.yaml": proxies[0].server is empty
How to read it:
proxies[0]: the first node in theproxieslist.
.server is empty: this node is missingserver.
Common errors and meanings:
| Error pattern | Common cause | Resolution |
|---|---|---|
is undefined | A rule or policy group references a name that does not exist | Check whether names in proxies, proxy-groups, and rules are consistent |
server is empty | The node is missing a server address | Add server |
invalid port | The port is not in the range 1-65535 | Check the port field |
unsupported | An unsupported protocol or field was used | Refer to the outbound protocol chapter and remove or rewrite it |
Related to tun / route | TUN conflicts with the platform or route fields | Disable TUN first and verify the basic link with an explicit proxy |
Step 3: Start Link1#
In the App, click start or apply the configuration. When running the core directly:
spark -d . -f config.yaml
A successful startup does not mean the proxy is already usable. You still need to confirm that traffic is actually entering Link1.
Step 4: Connect Clients to Link1#
Browser or System Proxy#
Enter:
HTTP proxy: 127.0.0.1:7890
HTTPS proxy: 127.0.0.1:7890
SOCKS5 proxy: 127.0.0.1:7890
mixed-port accepts both HTTP proxy and SOCKS5. For first-time use, it is recommended to set only the browser proxy to avoid a system-wide proxy affecting other applications.
Verify with curl#
curl -x http://127.0.0.1:7890 https://www.example.com/
To verify Cloudflare WARP:
curl -x http://127.0.0.1:7890 https://www.cloudflare.com/cdn-cgi/trace
Do not combine --noproxy '*' with -x; --noproxy '*' bypasses the proxy.
Verify in the App#
After the request is sent, confirm in the Link1 App:
- The target domain or target IP appears in the connection list.
- The matched rule is visible in the connection details.
- The outbound shows the node or policy group you expect.
- The logs do not show continuous DNS, authentication, handshake, or timeout errors.
If curl succeeds but the App connection list does not change, it usually means the request did not go through Link1, or you are not viewing the currently running configuration profile.
LAN Usage#
If you want other devices on the same LAN to use Link1:
mixed-port: 7890
allow-lan: true
bind-address: '*'
lan-allowed-ips:
- 192.168.0.0/16
authentication:
- alice:password
Practical effects:
- Link1 listens on all network interfaces.
- LAN devices can set the proxy to the Link1 host IP, for example
192.168.9.2:7890.
lan-allowed-ipsrestricts which source IPs are allowed to access it.
authenticationrequires clients to enter a username and password.
Risk: Do not expose the proxy port without authentication on public Wi-Fi or untrusted networks.
Router Usage#
Common approaches on routers:
- Explicit proxy: devices manually enter the router IP and
mixed-port.
- Transparent proxy: use
redir-port,tproxy-port, ortunto take over device traffic.
- DNS takeover: point LAN device DNS to the router, then let Link1 DNS handle it.
If you use TUN:
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
tun:
enable: true
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
The key in router scenarios is not whether the core has started, but three things:
- Whether LAN device traffic is taken over by the router.
- Whether DNS from LAN devices enters Link1.
- Whether Link1 outbound traffic can access the internet from the router itself.
Common Startup Issues#
| Symptom | Common cause | Resolution |
|---|---|---|
| Port is occupied | An old Link1 core or another proxy is still running | Change the port or stop the old process |
| Configuration test passes but clients cannot connect | Incorrect client proxy address, allow-lan=false, firewall blocking | Test locally with curl -x first, then verify from the LAN |
| Rules do not match domains | DNS does not enter Link1, Fake-IP is not enabled, Sniffer is not enabled | Check DNS/TUN/Sniffer |
| App shows no connections | Client bypasses the proxy, system proxy is not effective, TUN has not taken over traffic | Use browser proxy or curl for minimal verification |
| Linux TPROXY does not work | Missing system routing/iptables/nftables setup | Prefer TUN or check the transparent proxy script |
| HTTP Engine captures nothing | Capture is not enabled, host does not match, HTTPS MITM is not configured | Check http-engine.capture and mitm.hosts |