11. Link1 App Management#
The user management entry point for Link1 is the App, rather than direct access to the underlying core. The App organizes configuration, runtime status, policy groups, connections, logs, and HTTP capture into understandable pages, helping you complete the full loop of “import → validate → start → observe → troubleshoot”.
Division of Responsibilities Between the App and the Core#
| Capability | Link1 App | Link1 Core |
|---|---|---|
| Profiles | Import, edit, validate, switch, and display errors | Compile YAML and generate runtime structures |
| Runtime status | Start/stop, show the current configuration, and display rates | Listen on ports, create TUN, and maintain connections |
| Policy groups | Show members, switch manually, and trigger tests | Select nodes by group type and dial |
| Provider | Show subscription sources, refresh status, and node counts | Download, parse, filter, and perform health checks |
| Connections | Show targets, rules, outbound, and traffic | Accept connections and forward data |
| Logs | Search, filter, and copy errors | Output configuration, DNS, rule, dialing, and protocol errors |
| HTTP capture | Show flows, body previews, and replay entry points | Execute Capture, MITM, rewrite, and Mock |
Users should focus on “which layer the information on the page indicates has a problem”, rather than how the underlying system exposes that information.
Profiles#
A profile is a launchable description of network behavior. It usually includes:
- Inbound: for example,
mixed-port,tun.
- DNS: for example,
dns.nameserver,fake-ip-range.
- Outbound:
proxiesorproxy-providers.
- Policy groups:
proxy-groups.
- Rules:
rules,rule-providers.
- Advanced capabilities: HTTP Engine, Sniffer, device discovery, and more.
Common profile operations in the App:
| Operation | When to use it | Actual effect |
|---|---|---|
| Import | Add a configuration from a subscription, local file, or clipboard | Adds a profile that can be validated |
| Validate | Confirm that the configuration can compile before starting | Does not start network listeners; only checks fields and references |
| Apply | Make the current configuration the running configuration | The core restarts or hot-switches according to this configuration |
| Duplicate | Keep the original configuration before experiments | Avoids accidentally modifying a working configuration |
| Export | Migrate to another device | Saves YAML and related file references |
Recommendation: duplicate the profile before making major changes. If something goes wrong, you can roll back quickly.
Home and Runtime Status#
The home page should help you answer four questions:
- Whether the current core is running.
- Which profile is currently in use.
- Whether the current upload/download rates match expectations.
- Whether there are persistent error logs.
Common status meanings:
| Status | Meaning | Next step |
|---|---|---|
| Not running | The core has not started | Apply a configuration or check startup errors |
| Starting | Compiling the configuration, listening on ports, and creating TUN | Wait or check logs |
| Running | Entry points and the data plane are ready | Verify traffic in the connection list |
| Running but no connections | The core is available, but clients are not entering Link1 | Check system proxy, TUN, and router takeover |
| Error | Configuration, permission, port, or protocol failure | Copy the error and troubleshoot by chapter |
Connection List#
The connection list is one of the most important troubleshooting pages. For each connection, understand at least these fields:
| Field | Meaning | What it helps determine |
|---|---|---|
| Source address | Who initiated the connection | Whether it is the local machine, a LAN device, or an inbound user |
| Target | Domain or IP + port | Whether Link1 obtained the correct target |
| Network | TCP/UDP | When UDP does not work, check whether the protocol supports UDP |
| Inbound | Which entry point it came from | Whether it matches your expected takeover method |
| Matched rule | Which rule returned the action | Whether the rule order is correct |
| Outbound | Which node/group is ultimately used | Whether it is using the expected route |
| Rate/traffic | Current data volume of the connection | Whether data is actually being transferred |
| Error | Reason for connection failure | Whether the issue is DNS, dialing, handshake, or remote disconnect |
When troubleshooting, first check “Target” and “Matched rule”. If the target only has an IP and no domain, domain rules not matching usually does not mean the rule is wrong; it means DNS/Fake-IP/Sniffer did not provide domain information.
Policy Groups#
The policy group page is used to view and switch exits.
| Group type | User action in the App | Notes |
|---|---|---|
select | Manually select a member | The selection is usually persisted and remains after restart |
url-test | View latency results and manually trigger tests when needed | Only represents the latency of the test URL, not the experience for all websites |
fallback | View the currently available primary/backup nodes | Available nodes earlier in the list take priority |
load-balance | View member health status | A single connection usually does not use multiple nodes at the same time |
smart | View quality feedback | Selection results may change with network quality |
relay | View the multi-hop path | Any unavailable hop affects the entire path |
If a rule action points to a policy group, the final outbound depends on the policy group’s current selection. If the action points directly to a node, the policy group page will not change the outbound for that connection.
Provider and Subscriptions#
Provider is the source of nodes or rules. Common types:
| Type | Purpose | What to check in the App |
|---|---|---|
| HTTP proxy provider | Pull nodes from a subscription URL | Update time, download errors, node count, and filter results |
| File proxy provider | Load nodes from a local file | Whether the file path exists and the format is correct |
| Inline proxy provider | Define nodes inside the main configuration | Configuration validation errors and node names |
| WARP provider | Automatically materialize WARP/WireGuard/MASQUE candidates | Account/private key, candidate nodes, and health checks |
| Rule provider | Load rule sets from a file or remote source | Rule count, update failures, and behavior type |
| Hosts provider | Load hosts from an external source | Whether domain mappings match expectations |
When Provider has a problem, symptoms are usually empty policy group members, unavailable rule sets, rule matching failures, or nodes that remain unavailable.
Rule Testing#
Rule testing is used to check which rule a “hypothetical connection” would match without actually accessing the network. You usually need to fill in:
| Input | Example | Effect |
|---|---|---|
| Target host | chat.openai.com | Affects DOMAIN/GEOSITE rules |
| Target IP | 1.1.1.1 | Affects IP-CIDR/GEOIP/IP-ASN rules |
| Port | 443 | Affects DST-PORT rules |
| Network | tcp/udp | Affects NETWORK rules |
| Inbound type | mixed/tun | Affects IN-TYPE/IN-NAME/IN-PORT rules |
| Source IP | 192.168.9.10 | Affects SRC-IP-CIDR/SRC-GEOIP rules |
| Process name | Safari | Affects PROCESS rules, depending on platform capabilities |
Rule test results should include: the matched rule, final action, whether DNS resolution is triggered, and whether it falls through to MATCH. If the test result is correct but the real connection is not, it usually means the real connection’s metadata differs from your test input.
Observing DNS and Fake-IP#
The DNS page or related logs are used to answer:
- Whether the domain is resolved by Link1.
- Which nameserver is used.
- Whether a real IP or Fake-IP is returned.
- Whether the Fake-IP can be reverse-mapped back to the domain.
- Whether fallback or nameserver-policy works as expected.
Typical issues:
| Symptom | Possible cause |
|---|---|
| Domain rules do not match | DNS did not enter Link1, and the connection only has an IP |
| Domestic sites resolve to overseas IPs | The nameserver/fallback strategy is inappropriate |
| Access fails under TUN | DNS hijack is not effective, and the system is still using external DNS |
| LAN services break after Fake-IP | Internal domains should be added to fake-ip-filter or hosts |
Logs#
More detailed logs are not always better. Recommendations:
| Scenario | Recommended log level |
|---|---|
| Daily use | info |
| Startup failure | debug or copy the startup error |
| DNS issues | Temporarily raise to debug |
| Protocol handshake failure | Check the node name, remote address, and TLS/authentication-related errors |
| HTTP Engine debugging | Enable only for the target host and limit the body size |
When reading logs, first identify “which layer the error belongs to”: configuration compilation, inbound listener, DNS, rules, policy groups, provider, outbound protocol, or HTTP Engine.
HTTP Capture and Replay#
After HTTP Engine Capture is enabled, the App can display HTTP flows:
- Request method, host, path, and status code.
- Request/response header summary.
- Body preview or the save location of the full body.
- Matched HTTP Engine rule.
- Differences between views before and after modification.
Replay is used to reproduce a captured request, which is suitable for debugging rewrite rules or Mock rules. Note: replay may access the real target service again and may include sensitive headers/body. Confirm the target and content before use.
Security Boundaries#
- Save configuration profiles and certificates only on trusted devices.
- Do not expose proxy entries without authentication to untrusted networks.
- Enable HTTP Engine MITM only for necessary domains, and do not leak the CA private key.
- Subscription URLs, node passwords, WireGuard private keys, and enterprise VPN credentials are all sensitive information.
- Before sharing logs with others, check whether they contain node addresses, usernames, tokens, private keys, or internal domain names.