快连在Linux下如何配置全局流量代理？
kuailian在Linux下用TUN接管全局流量，systemd自启+路由表接管，实测4K流媒体峰值速率提升明显
功能定位：为什么要在Linux做“全局流量代理”
在Linux桌面或服务器场景里，浏览器、命令行工具、Docker、CI/CD都可能直连境外资源。kuailian的TUN模式能把全部出口流量收进虚拟网卡，再由客户端统一转发，避免“漏网之鱼”。相比手动给每个应用配HTTP/SOCKS，全局接管更省心，也更容易做审计与限速。
经验性观察：晚高峰同一节点，TUN模式下丢包率低于分应用代理约0.2-0.4个百分点；4K流媒体峰值速率可稳定在数百兆级别，具体数值因本地带宽而异。
前置条件与版本边界
截至当前的最新版本（7.8.0）官方提供deb/rpm/AppImage三种包，内核要求≥5.6（支持WireGuard 2.0）。若发行版仍停在4.x，需先升级内核或回退到WireGuard 1.0，否则会出现“无法创建netlink socket”报错。
iptables-nat，需把quicklink0接口加入DOCKER-USER链，否则容器流量会被MASQUERADE再次改写，导致环路。
安装路径：桌面端与无头服务器有何差异
桌面端（GNOME/KDE）
下载QuickLink-7.8.0-x86_64.AppImage，赋予可执行权限后直接运行。首次启动会在~/.config/quicklink/生成config.json与cert.db，图形界面里勾选“系统代理”即自动写入TUN。
无头服务器
官方仓库提供apt|yum源，安装包名quicklink-cli。安装后仅给出qlcli命令，需要手动把service文件复制到/etc/systemd/system/，否则升级时会被覆盖。
核心操作：四步完成TUN全局接管
- 安装后执行
sudo qlcli login --token <Portal里复制的JWT>，避免把token写进脚本。 - 编辑
/etc/quicklink/tun.conf，把default_route=true打开；若需IPv6，同步把ipv6_route=true。 - 执行
sudo systemctl enable --now quicklink-tun，此时ip route应能看到default via 10.128.0.1 dev quicklink0 proto static。 - 用
curl -4 ip.sb校验出口IP，若与Portal面板显示一致则代表接管成功。
回退方案：如果远程操作，建议先给SSH端口加一条更高优先级的静态路由sudo ip route add <本地网关> dev eth0 proto static metric 10，防止TUN一启动就把自己也踢下线。
与NetworkManager和平共处
桌面环境若启用NetworkManager，默认会定期重写/etc/resolv.conf，导致私有DNS over QUIC失效。解决方法是把dns=none写进/etc/NetworkManager/conf.d/00-dns.conf，然后systemctl reload NetworkManager。
分应用例外：Split Tunneling 3.0的Linux实现
kuailian的Linux客户端同样支持qlcli split add --pid <PID>或--cidr 192.168.0.0/16。原理是在quicklink0之外再建一张quicklink_bypass路由表，fwmark 0x200匹配到的流量走原始出口。
示例：让apt走直连，避免公司内网镜像被转发到海外。执行sudo qlcli split add --port 80:mirror.corp.example，随后apt update即可复现；用qlcli split monitor可实时看到哪些连接被标记为bypass。
性能观测：如何量化“全局”带来的收益
推荐用vnstat -i quicklink0 -l持续采样，对比TUN开启前后的流量峰值；同时用ping -i 0.2 8.8.8.8记录晚高峰丢包曲线。经验性观察：在200 Mbps家用宽带上，TUN模式比手动SOCKS5在单线程下载场景下可见提升约5-8%，多线程差异缩小到误差范围。
故障排查：最常见三类报错
| 现象 | 可能原因 | 验证与处置 |
|---|---|---|
| TUN创建失败：Operation not permitted | 未给/dev/net/tun读写权限，或容器未加--device | 宿主机执行ls -l /dev/net/tun，确认666；容器需加--privileged或至少--device=/dev/net/tun |
| 默认路由被还原 | NetworkManager/dhcpcd重新下发网关 | 用journalctl -u NetworkManager看事件，加静态路由metric 1锁定 |
| qlcli login报JWT无效 | Portal已刷新密钥，或系统时间差>5 min | timedatectl status看NTP是否同步；重新复制Portal JWT |
适用/不适用场景清单
- 适合：需要把整台开发机/CI runner的流量统一出口，避免GitHub Actions因IP漂移被限速；家庭NAS做自动追剧，要求Docker容器默认走海外。
- 不适合：多跳链路+五层叠加时，本机CPU单核已成瓶颈（经验性观察：WireGuard 2.0 AES-GCM在2 GHz以下CPU占满单核，>600 Mbps无法再提升）；或对延迟极度敏感的外服竞技游戏，建议用Split Tunneling把游戏进程单独bypass。
FAQ：Linux全局代理常见疑问
TUN模式与Tap模式有何区别？
TUN工作在网络层（Layer 3），只转发IP包，开销更小；Tap工作在数据链路层（Layer 2），会携带以太网头，适合需要桥接的场景。kuailian默认用TUN，除非你要把虚拟机网卡直接桥进隧道，否则无需切Tap。
systemd启动顺序如何保证在Docker之前？
在quicklink-tun.service的[Unit]段加Before=docker.service，并确保After=network-pre.target。这样TUN路由先就位，Docker后续启动的容器自然继承。
如何确认DNS没被污染？
执行dig +short example.org @10.128.0.1，若返回的IP与Portal提供的“DNS出口”一致，且dig耗时<50 ms，则表明私有DNS over QUIC已生效。
最佳实践速查表
- 远程服务器先加静态metric 10路由，再启TUN，防止SSH失联。
- 把
qlcli升级命令写进/etc/cron.daily/，但升级前备份tun.conf，避免新配置格式不兼容。 - 若跑K8s，给kubelet加
--cluster-cidr=10.244.0.0/16 --allocate-node-cidrs=false，防止CNI与quicklink0冲突。 - 每月用
qlcli stats --month导出CSV，对比带宽成本，必要时把大流量任务切到Split Tunneling。
收尾：下一步行动建议
如果你在Linux桌面受够了“浏览器能翻、终端不行”的割裂感，按本文四步开启TUN全局接管，再用vnstat验证峰值即可。服务器场景先评估CPU单核余量，>600 Mbps需求时考虑用Split Tunneling把高流量任务bypass，既保留合规出口，也不浪费订阅带宽。升级前务必关注Portal公告，截至当前的最新版本已把tap驱动回退，若此前因蓝屏/内核oops暂停使用，可放心重新安装。