下载

• Win：github release下载exe

• Linux：release有deb rpm appimage，arch的aur可下载PKGBUILD改为最新版本本地makepkg -si

跨端同步配置

同步方式

• 局域网下在应用中生成与扫描二维码完成同步，如果无法局域网同步，可以导出导入配置使用

跨端同步配置冲突

• 分流，TUN等配置都是单个的可选项，在安卓端同步桌面端配置建议取消勾选TUN避免覆盖安卓端绕过应用的配置

安卓端分应用代理

• 可参考如下配置

• 白名单是√了的才走代理

• 如下为关闭，只有√了才绕过，默认是走代理，适用于需要代理的应用远多于不需要的

IP自检与测速

相关站点

• 常用站点，用于检查节点IP与风控程度

IP Geolocation API with Threat Intelligence

Lookup the location of any IP Address with ipdata's IP Geolocation API. ipdata is fast, accurate and is used by 20,000+ developers.

https://ipdata.co/

• 常用测速

Internet Speed Test - Measure Network Performance | Cloudflare

Test your Internet connection. Check your network performance with our Internet speed test. Powered by Cloudflare's global edge network.

https://speed.cloudflare.com/

Speedtest by Ookla - The Global Broadband Speed Test

Use Speedtest on all your devices with our free desktop and mobile apps.

https://www.speedtest.net/

分流规则设置

分流规则的作用

• 为什么需要分流规则？ - 1.绕开IP限制与风控 2.在对部分服务（如AI）维持1的基础上部分（如Google搜索）服务选择速度较快的节点 3.保持部分服务（如X）IP区域

• 使用后的示例场景：在使用HK节点减小Google搜索时延的基础上，通过US节点保持AI服务最新（Google AI相关服务优先US上线），使用JP节点访问社媒X，获取相关区域内容推荐

• 不使用的示例场景：使用了没有解锁的节点导致不能访问，原因包括：1.处于不提供服务的区域（AI限制，OpenAI，Claude，Gemini，HK节点无法访问），日厂游戏锁JP 2.节点风控（Youtube可访问但点不开视频/一步一个CF人机验证） 3.节点在某些站点跳CN或HK（可访问某些网站但xx不可访问）

常用分流区域

• 在不考虑节点自身特殊情况下，一般常用以下区域的节点：
• US（Google服务优先于US上线，部分时候仅限US）
• JP（日厂游戏锁IP，社交媒体，流媒体审核）
• HK（地域上近，时延低，B站港澳台）
• TW（巴哈姆特动画站点等锁TW IP）
• KR，SG（地域上近，时延相对低）

分流规则的干扰项

• 节点的解锁情况会影响到分流的设置决策，如HK节点如果以其他区域解锁AI，也可以访问AI服务

• 一般机场测评与群中（各类tg频道）都有类似以下的表格，写明节点各流媒体等解锁情况，如要付费，建议先了解解锁情况

分流规则的潜在问题

• 对规则是否覆盖全面，是否相关联的均在一个分流组内有要求，网站的主站点可能与相关存储站点使用不相同甚至不直接相关的域名，比如油管有用到谷歌的存储，如果这时候分流规则里没有将两块合在一个规则下，可能出现跨域无法访问或跨国访问较慢的问题，如果此时仍需要分流，可以配合在线面板排查相关域名问题，自行补充分流规则

IP风险数据参考

• ip风险可参考

IP Geolocation API with Threat Intelligence

Lookup the location of any IP Address with ipdata's IP Geolocation API. ipdata is fast, accurate and is used by 20,000+ developers.

https://ipdata.co/

较好

较差

• 可以点开threats查看相关风险项，比如如果在VPN一项有✔，可能在注册一些域名站点与访问站点时被识别成VPN禁止访问

karing分流规则实践

• 不同机场自带分流配置质量参差不齐，建议使用配置覆盖，保持分流规则的一致性

基本操作

• 在分流规则界面下，选中自定义分流组，选中禁用机场分流，在右上角点击笔状按钮添加所需规则（如果不清楚应该加入哪些，可参考防止DNS泄露部分设置）

• 进入编辑界面，可点击具体分流规则进行编辑，右键省略号图标可添加新分流规则，+添加为自定义规则，第二个添加为预设规则

• 编辑界面与添加预设界面，可以在添加预设里勾选需要的规则

• 单击对应分流组可自行补充分流相关

特殊分流

• GA（自定义，可选） - 写在广告拦截前，避免Google Analysis被当广告拦截，如果不使用相关服务，可以不加

• 可以考虑合并AI相关为一个分流组，用于AI相关访问

• linux.do（自定义） - 用于直连网站 （初次✍️时L站仍可直连）

排查漏网之鱼

• 由于右上角的连接状态不能搜索，通常使用设置里的在线面板

• 通过连接tab下搜索对应域名排查所走规则，如果不合适将对应域名或域名后缀修改到适合的分流组里即可

• 比如此处将parsec远程连接，发现走到了代理，网络延迟达到100ms以上，将其对应的进程修改为走直连后，延迟降到个位数ms

进阶实践 - 自定义自动选择

• 理论上可以将同区域放一个自动选择组里，设置好后无感使用，但需要实测是否会频繁切换节点，不然容易被风控

• 功能在分流→自定义自动选择，基本用途为将不同机场的指定区域节点聚合起来使用

 

 

• 进阶用途 - 平衡延迟，流量，解锁
• 以下为例
• 当前选择HK → 确保一般网站延迟低，访问快
• 自定义YT(包含SG，JP等低延但能解锁yt music的节点) → 油管视频（包含yt music）
• Gemini(自行修改过，包含御三家)AI → 使用相对稳定的US节点分流
• 下载DL → 使用免流节点用于大文件下载



• 下载演示steam（steam可以直连，不必要使用代理）



• yt music SG解锁



• HK一般日用



• AI解锁



• 主面板可查看当前各分组的选择节点，可以点击延迟按钮重新测速，如果开启手动测速重新选择，会自动重选节点（面板本身不能直接改节点选择）

TUN与系统代理

概念区别

• 一段取自Karing文档的系统代理与TUN概念上的区别

FAQ | Karing - Clash compatible & Powerful proxy utility

Karing App

https://karing.app/faq

• 规则 → 按分流规则走代理

• 全局 → 无视分流规则走代理

• 代理 → 支持代理（如果软件不支持，需要通过fiddler这类应用☑️相关应用提供支持，通过fiddler代理对应应用的流量）且设置了代理的应用按照规则/全局走代理

• TUN → 所有应用按照规则/全局走代理

使用区别

• 在支持代理的应用中，如果仅使用系统代理，需要自行在所有需要代理的软件中全部作代理相关设置（如果设置变更，比如代理端口，对应所有应用都需要更改，除非自动识别），TUN模式下不需要任何的配置，也不需要软件支持代理，可以无感地使用代理，常见代理模式下需要自行设置的场景包括：
• 终端PowerShell
• 比如wget等命令行程序的对外访问依赖于相应shell的代理设置



• 系统代理在没有设置https_proxy与http_proxy两个环境变量的情况下，wget会超时取不到index.html，TUN模式不需要这些设置





• git
• 印象里windows下git是不走命令行的环境变量的，需要使用自己的代理设置，比如如下全局的http与https代理设置（访问本地应用不应写成https）
• 配置后可以稳定高速的使用git clone（此处示例fatal为ctrl + c中断）



• TUN下置空两个代理设置一样正常访问





• JavaScript的fetch api，参考下文设置，本身是fetch api需要引入依赖的undici显式设置代理，也是个不认环境变量的
[debug]nodejs fetch/js gemini api不使用代理问题 node:internal/process/promises:289 triggerUncaughtException-CSDN博客
文章浏览阅读2.5k次，点赞9次，收藏5次。博客围绕Gemini1.0 Pro API代码执行报错展开。报错显示为fetch failed，经分析是fetch未使用代理。解决方案是安装undici库并加入代码，再次执行后成功得到回复。

https://blog.csdn.net/m0_58360315/article/details/137288725?spm=1001.2014.3001.5501
• Docker，参考下文Docker代理问题，pull镜像的时候也是需要自行配代理
神领物流Day01复盘-环境搭建
SSH连接问题；Jenkins构建失败问题；Docker代理问题；gogs git私服克隆502错误；Maven私服配置

https://camelliav.cloudns.ch/slwl-day01

Windows下以TUN自启

• 可以先试试karing文档里的方法，实测在win11 24h2不一定生效，无法TUN自启

• linux自行在桌面设置启动即可，TUN只需要在初次使用或更新后初次使用输入sudo密码，往后不再需要

引入

• Windows下TUN模式开启需要以管理员权限启动程序，而软件设置的开机自启不能以管理员权限启动程序，使得每次开机需要自行右键管理员权限启动，比较麻烦，以下展示如何通过任务计划实现以管理员身份开机自启Karing

• 注：安卓上默认开启TUN模式，结合绕开代理的应用设置很好用

• 开启TUN后的图标显示

• 在网络设置应看到

 

流程

• win键起手，任务计划程序

可以顺手禁用夸克自动更新

• 右边创建任务，在常规tab下，名字自选，描述自选，选中使用最高权限

• 触发器tab，设置登录时（不是启动时），选中特定用户

• 操作tab，选择启动程序，找到karing的快捷方式或安装目录下的exe程序

• （仅笔记本）条件tab，取消两个电池相关选项（勾选即电池供电时不运行此任务）

• 设置tab，勾选过了开始时间立即启动

• 确定后完成创建任务，回到karing关闭自启选项

• 可重启验证是否成功自启与TUN自动开启

 

TUN设置

• 此处设置可以防止DNS泄露，哪怕不需要防止DNS泄露也可参考，因为重点是外网域名就应在代理服务器解析而不是本地

应用设置

TUN，DNS，分流，IPV6

• DNS参见如下设置，可以采用自动设置功能



 

• 建议开启严格路由，防止请求同时发到TUN跟其他网络（win）

 

• DNS开启分流，代理解析为FakeIP（dns请求会在代理服务器完成，更快与正确的CDN）

• 分流规则，如果不能保证所有海外的流量都被前面拦截，关闭acl，karing的代理兜底final在所有规则之后，GeoSite，GeoIP需要开，避免国内流量走代理，

• 最终效果上，必须在仅开启TUN的基础上，不出现DNS泄露

 

• 如有海外站点访问不了大概率节点风控，自行通过网络检测debug

• 取消IPV6，开启存在因IPV6流量DNS劫持失败而泄露的问题

• （可选）关闭浏览器安全DNS，DNS分流+TUN FakeIP不是很需要，境内流量可以走udp，需要也可以tls与https，但延迟会高些，境外直接丢给代理服务器做DNS解析，不需要此功能。如果仅使用系统代理，不使用TUN，访问被DNS污染（但未被SNI阻断的站点），可以使用此功能，选择操作系统默认选项以外其他公共DNS即可。

from

to

 

核实测试

是否浏览器层面DNS泄露

• 如果仅使用系统代理，或仅在浏览器层面希望不出现泄露，参考以下测试结果足以

• 在设置里测试结果应类似于下方结果，不能有任何CN的，包括IP地址与测出的DNS

DNS Leak Test

The DNS Leak Test is a tool used to determine which DNS servers your browser is using to resolve domain names. This test attempts to resolve 50 randomly generated domain names, of which 25 are IPv4-only and 25 are IPv6-only.

https://browserleaks.com/dns

IP/DNS Detect

What is your IP, what is your DNS, check your torrent IP, what informations you send to websites.

https://ipleak.net/

DNS 泄漏测试 - Surfshark

DNS 泄露对您的数字隐私和安全构成极大的危险。在这里检查您的 VPN 的完整性并保持在线保护。

https://surfshark.com/zh/dns-leak-test

是否分流规则正确

• 确保国内站点访问为直连，一般延迟控制在较低水平（Baidu可以除外，真的慢），也可在在线面板连接tab下进一步核查

IPCheck.ing - Check My IP Address and Geolocation - Check WebRTC Connection IP - DNS Leak Test - Speed Test - Ping/MTR Test - Jason Ng Open Source

A better and open source IP Toolbox. Easy to check what's your IPs, IP information, check for DNS leaks, examine WebRTC connections, test website availability, lookup DNS record, lookup Whois, and test latency from around the world.

https://ipgeo-myip.hf.space/#/

是否DNS解析正确

• 如果使用TUN，希望包括本地应用等均不出现DNS泄露

• 在浏览器测试之外，进一步地，可以检查dns解析与Wireshark抓包

• 检查解析方法 - 检查nslookup dns解析

• 应满足：
• 1.默认nslookup的dns请求（无论直连，代理）均发向TUN设定网关（karing默认10.20.0.2）（直连流量直接解析出目标ip，代理流量返回FakeIP，198.20.x.y，符合预期）





• 2.开启DNS劫持后，以任意DNS服务器请求解析，应返回统一的劫持后结果，即198开头的FakeIP



• 3.直连与代理DNS请求均被拦截，仅直连DNS请求被放行



• 访问油管，站点本身与相关的其他海外请求DNS进入karing，但不从本地发出（通过代理协议包裹给了代理服务器作解析）





• 访问b站，DNS请求进入karing，直接放行



• （可选）可进一步确认，直连流量走的DNS服务器与设置相同



• 类似地。在Linux上应有：





 

原理拓展阅读

• 深入理解TUN工作流程，FakeIP与更多相关知识

浅谈在代理环境中的 DNS 解析行为 | Sukka's Blog

虽然 Fake IP 这个概念早在 2001 年就被提出来了，但是到 Clash 提供 fake-ip 增强模式以后，依然有很多人对 Fake IP 这个概念以及其作用知之甚少。本文就简单谈谈在代理环境中，TCP 连接建立之前发生的事。由于移动设备操作系统中网络栈相对复杂，本文的例子也并不一定适用于移动端环境。文章中也许会存在很多错误，也希望各路大佬的勘误和斧正。

https://blog.skk.moe/post/what-happend-to-dns-in-proxy/

是什么，为什么，怎么做 —— 谈谈 DNS 泄漏、CDN 访问优化与 Fake IP | Sukka's Blog

2001 年 4 月 IETF 通过的 RFC3089 中所描述的 Fake IP，是四层代理分流场景下 性能相对最佳、体验相对最好、实现相对最简单的「最佳实践」。相比之下，Real IP 模式下为了尽可能接近 Fake IP 的性能、体验，需要大量额外配置、付出更多的代价。

https://blog.skk.moe/post/lets-talk-about-dns-cdn-fake-ip/

常见问题与其他杂项

TUN保留端口

• 有部分端口可能被保留不可使用，对8080,3306,6379等常见不影响，但对3000有影响，可以自行更换端口使用

修改设置了没有起作用

• 修改完需要回到主界面，等待自动断开重连后生效

添加更新配置与无法连接

• 参考Karing文档中部分

界面卡顿

• 删除最新版，下载857版本（上游flutter问题，新版已解决）

添加配置没有内容

• UA里仅勾选clash-verge或V2Ray再尝试

像Clash一样查看日志与断开某个连接

• 设置-在线面板

批量导入节点过滤

• 可以按正则规则导入配置时进行节点过滤

自定义自动选择组

订阅转换

• 不需要，节点，订阅链接都可以直接导入

PKGBUILD参考

WSL配置

• TUN下wsl的网络设置，如果镜像无法连接，可以换NAT，开DNS代理