11. Link1 App 管理#

Link1 的用户管理入口是 App，而不是让用户直接操作底层内核。App 的职责是把配置、运行状态、策略组、连接、日志和 HTTP 捕获整理成可理解的页面，帮助你完成“导入 → 校验 → 启动 → 观察 → 排障”的闭环。

App 与内核的分工#

用户需要关注的是“页面上的信息代表哪一层出了问题”，而不是底层如何暴露这些信息。

配置档案#

配置档案是一份可启动的网络行为说明书。它通常包含：

• 入站：例如 mixed-port、tun。

• DNS：例如 dns.nameserver、fake-ip-range。

• 出站：proxies 或 proxy-providers。

• 策略组：proxy-groups。

• 规则：rules、rule-providers。

• 高级能力：HTTP Engine、Sniffer、设备发现等。

App 中配置档案的典型操作：

建议：每次做较大改动前复制一份配置档案；出问题时可以快速回退。

首页与运行状态#

首页应帮助你回答四个问题：

1. 当前内核是否正在运行。

1. 当前使用哪份配置档案。

1. 当前上行/下行速率是否符合预期。

1. 是否存在持续错误日志。

常见状态含义：

连接列表#

连接列表是排障最重要的页面之一。每条连接至少要理解这些字段：

排障时优先看“目标”和“命中规则”。如果目标只有 IP，没有域名，域名规则不命中通常不是规则写错，而是 DNS/Fake-IP/Sniffer 没有提供域名信息。

策略组#

策略组页面用于查看和切换出口。

如果规则 action 指向策略组，最终出站取决于策略组当前选择；如果 action 直接指向节点，则策略组页面不会改变这条连接的出口。

Provider 与订阅#

Provider 是节点或规则的来源。常见类型：

Provider 出问题时，症状通常是策略组成员为空、规则集不可用、规则命中失败或节点一直不可用。

规则测试#

规则测试用于在不真正访问网络的情况下，检查一条“假想连接”会命中什么规则。你通常需要填写：

规则测试的结果应包括：命中的规则、最终 action、是否触发 DNS 解析、是否落到 MATCH。如果测试结果正确但真实连接不正确，通常说明真实连接的元数据和你测试输入不同。

DNS 与 Fake-IP 观察#

DNS 页面或相关日志用于回答：

• 域名是否由 Link1 解析。

• 使用了哪个 nameserver。

• 返回了真实 IP 还是 Fake-IP。

• Fake-IP 是否能反查回域名。

• fallback 或 nameserver-policy 是否按预期生效。

典型问题：

日志#

日志不是越详细越好。建议：

读日志时先看“错误属于哪一层”：配置编译、入站监听、DNS、规则、策略组、provider、出站协议、HTTP Engine。

HTTP 捕获与重放#

开启 HTTP Engine Capture 后，App 可以展示 HTTP flow：

• 请求方法、host、path、状态码。

• 请求/响应 header 摘要。

• body 预览或完整 body 的保存位置。

• 命中的 HTTP Engine 规则。

• 修改前后的视图差异。

重放用于复现某个已捕获请求，适合调试改写规则或 Mock 规则。注意：重放可能再次访问真实目标服务，也可能带上敏感 header/body，使用前应确认目标和内容。

安全边界#

• 只在可信设备上保存配置档案和证书。

• 不要把代理入口无认证暴露到不可信网络。

• HTTP Engine MITM 只对必要域名开启，CA 私钥不要外泄。

• 订阅地址、节点密码、WireGuard 私钥、企业 VPN 凭据都属于敏感信息。

• 复制日志给别人前，先检查是否包含节点地址、用户名、token、私钥或内网域名。