有了翻墙的服务器节点后，还需要让代理软件接管电脑的网络流量，然后才能将你的流量转发到翻墙节点，从而实现翻墙。

本文介绍两种常用接管流量的方法：HTTP/Socks 和 Tun VPN，并总结优点和缺点，选择适合自己的方法。

HTTP/Socks​

如果你使用的是 Windows 操作系统，并且平时只是看看网页，刷刷视频的，启用这个入站最合适你。

实现原理​

当你在用浏览器访问 Google.com 时，一般来说浏览器会先检查你操作系统中是否设置了 系统代理，如果使用了，那么就会将请求先发送到 系统代理 所提供的地址，例如说：127.0.0.1:9110，这个地址就是由 UIF 提供的，所以 UIF 就能获取你想访问的网站，从而转发翻墙。

优缺点​

• 要软件的支持；浏览器检不检查，转不转发并不是强制的，全看软件愿不愿意支持
• 侵入性小，性能较好；随启随用，无负担
• 适用性有限，无法代理 UDP 流量；所以也就适合看看网页

如何使用？​

① Windows 和 Mac 用户​

仅需在 UIF 入站中点击 启用按钮 即可。UIF 会把操作系统中的系统代理设置为 UIF 所提供的地址。

② 有图形化界面的 Linux 用户​

由于发行版较多，无法做到统一适配，一般来说都是支持一键设置系统代理的，例如说 Ubuntu 操作系统。但如果出现 initialize system proxy: unsupported desktop environment 就意味着不支持自动设置。那就需要 自行设置。

③ 没有图形化界面的 Linux 用户 和 Docker 用户​

无法做到一键设置，是绝对会出现 initialize system proxy: unsupported desktop environment 的，从而导致内核无法运行（就是显示 未运行 状态）。

如何解决 initialize system proxy: unsupported desktop environment ?

出现这个错误的意思就是：UIF 无法自行设置系统代理，你需要手动去设置。去到 HTTP 的入站设置，如下图所示：

取消启用 设置系统代理，然后点击右上角 保存 即可解决问题。

自行设置操作系统的系统代理​

不需要 UIF 帮你设置系统代理，或者UIF 无法自动帮你设置系统代理，那么就需要你自己手动去操作。

一般而言，Windows 和 Mac 都可以在图形化界面一键启用或关闭系统代理：

所以只需讨论 Linux 是如何操作的，具体情况参考文章。简单来说，你需要自行执行两条命令即可：

export http_proxy=http://127.0.0.1:9110
export https_proxy=http://127.0.0.1:9110

9110 是 UIF 默认 HTTP 入站的端口，你可以在入站列表里自行去查看或修改监听的端口。

如果你想在局域网内的用户都可以使用你所提供的代理服务，你仅需将监听地址改为公网，并开放防火墙，这样就可以让其他人也使用你的代理。

Tun VPN​

如果你做软件开发或者需要游戏加速等复杂情景，Tun 能最大限度的满足所有的需求。

然而 Tun 的实现方式比较复杂，而且必须需要管理员权限（Root）。具体的请看 透明代理 。

** 本文 4K 高清视频已上传到 Youtube**

什么是链式代理（detour）？假设现在有两个节点 A 和 B，他们分别有不同的 IP 和网络环境，而且最重要的是他们都提供代理功能，假设 A 提供 Vmess 入站，B 提供 HTTP 入站。

如果要访问 google.com，我们想将内容先发送给 A 节点，然后再由 A 节点，发送给 B 节点，最终由 B 节点发起 google 请求，此时 google 识别到的 IP 也是 B 节点的。

使用场景​

外贸企业通常会用到这种方法来使用住宅 IP，因为 B 节点（也就是落地节点）通常无法在国内直连的，所以需要先连接到 A 节点。

链式代理也可以用来作为中转服务提高速度或减少延迟，因为即使 B 节点在国内能连接上，连接线路可能会绕圈，经过大半个地球后才能连上 B 节点，用 A 节点作为中转，用户仅需关注你和 A 节点之间的网络情况，A 节点甚至可以部署在国内，从而减少延迟，提高可用性。

如何实现链式代理？有什么限制？​

首先就得要本机的翻墙工具具有链式代理的功能，也就是内核必须要支持 A 和 B 的出站方式。

相比于传统的中转服务，链式代理并不需要 A 和 B 节点做什么特殊的设置，因为用户通常也修改不了 A 和 B 节点。用户仅需在客户端添加 A 和 B 出站，然后修改一下 B 的 detour 即可。

在桌面系统（Windows、Linux、Macos） 上如何使用？​

首先你要下载好 UIF，参考 UIF 的安装教程。然后添加 A 和 B 节点并启用这两个节点，你可以添加很多个节点，为了简化，这里仅演示两个而已，因为也至少要有两个，而且 A 节点是必须要在国内可用的。

添加好并启用好入站之后，选中 B 节点 -> 点击 操作 按钮 -> 配置 -> 拨号设置 -> 在 链式代理 中选中 A 节点 -> 点击 保存。

设置好后，B 节点就可用了。最后如果你需要全部流量都走 B 节点，需要设置路由让所有流量走 B 节点，或者选择 简化版选中 B 节点即可。

在手机上（IOS、安卓） 上如何使用？​

首先你需要在电脑上设置好，然后去到 设置 点击 复制分享链接，把订阅分享到手机上即可。

首先我们要知道技术上是如何屏蔽广告的？当访问一个网页时，广告也会随着网页内容一同显示在浏览器上，要屏蔽某一个网页上的广告，就必须得区分出真实内容和广告内容。所以总的来说，屏蔽广告的方法分为俩大类：

非侵入式​

屏蔽广告程序不会去检查传输的内容，仅知道传输的域名和 IP。

比如说谷歌有专门的广告域名 ad.google.com，当我们检测到存在该域名的链接，就把他中断掉，从而无法显示出来。然而，如果某个网站的广告域名是 user.x.com，用户的信息也会通过此域名传输，即使我们知道这个会传输广告，但是屏蔽了他，也就同样屏蔽了正常的功能。

即使可能会误杀，但还是有好心人收集整理了这些广告域名数据库，例如说 domain-list-community

支持这种屏蔽方式的软件有：

• clash
• v2ray/xray
• sing-box

以上的软件的原理基本上都是接管所有网络流量，然后分析识别，匹配目标域名是否在广告数据库中，如果在，那么就中断。而且他们所依赖的数据库基本上都是 domain-list-community，效果可以说是大同小异。

同时也存在能屏蔽广告的 DNS，例如说 AdGuard DNS，只要把你的设备的 DNS 设置成他们的就可以屏蔽广告。原理还是一样的：通过域名匹配广告数据库。但是这些 DNS 都在国外，延迟非常高，基本不可用，所以就有 AdGuardHome，允许你本地搭建一个 DNS Server。

侵入式​

这种方式效果最好，我们会获得传输的所有内容，更加细化和精确。但也是同样依赖数据库更新的。

支持这种方式的基本只有浏览器插件，例如说：

• ADBlock
• AdGuard

图中所展示的就是 AdGuard 的移除广告效果，因为，这类插件都是寄生在浏览器身上，本来就能获取网页内所有的内容，所以能区分广告内容还是有效内容，做到精确移除网页内的广告。

但如果你是用通过 App 使用 YouTube 之类的，你是无法安装并使用这些插件的。想要屏蔽 App 的广告是不现实的，我们首先需要做中间人 MITM 解密 传输内容，即使能获取传输内容，我们也需要花费大量精力研究如何修改这些传输内容，不同于广告数据库，修改这些内容有可能需要复杂的编程。

如果一个 APP，直接内嵌证书，而不使用系统内的证书，那么连解密的机会都没有了，只能去破解 APP。市面上也有许多非官方版的破解 APP，但非常不建议去使用这些来源不明的 APP，可能会留有后门。

最佳方案​

维护广告数据库是十分困难的，全球几千万站点，每天上百亿次广告展现，频繁变更的广告植入方式。

当然了，最佳方案就是给 APP 钱，开会员去广告。但如果你不想给钱，可以尝试一下：使用 AdGuard 规则的 sing-box；原理跟 Clash、V2ray 之类是一样的，但使用了 更加完善的广告数据库，更新更加频繁，生态更好。

如果你是浏览器用户，那么直接使用插件即可。

通常在软路由上，人们都喜欢去安装 AdGuardHome，使用 Sing-Box 的具体优势参考上图。在 UIF 中，你仅需点击启用即可使用 AdGuard 的广告过滤，全系统支持 WIndows、Linux、Macos 当然也包括软路由。

市面上有很多分享免费节点的，在 Github 中可以搜出一大堆，但是可用的寥寥无几，更有甚者，订阅里面提供了 5 千多个节点，但是我们测下来，也就只有不到 200 个节点可用。

所以 我们 通过爬虫技术，在国内部署了服务器，收集互联网上好心用户分享的免费翻墙节点。并且会通过软件程序，每隔半小时收集并测试这些节点的可用性，没被 GFW 屏蔽的高可用节点才会出现在这里。

选择下列其中一个可用的订阅地址，点击复制即可:

如果我们微不足道的东西对你有帮助，请转发分享 UIF 就是对我们最大的支持。

如何使用？​

免费节点采用的是 Sing-Box 配置的分享格式，全平台支持，包括：Windows、Linux、Macos、Android、IOS；仅需几步就可以使用了。

你需要先确保已安装了翻墙软件，具体的下载安装参考 移动端 和 电脑端 的教程。安装完成后，把文本提供订阅链接导入到软件中即可使用。

导入订阅后，软件会自动选择延迟最低的节点。

无法使用？​

免费的节点是共享的，任何人都可以使用，所以为了避免滥用和被攻击，设置了自动更新；导入订阅后，请测试一下节点的延迟；若显示则为可用。如不可用，请更新订阅，或到本文生成新的订阅链接。

免责声明​

本文所有代理服务器均收集自互联网，并不由 UIF 提供，使用这些来源不明的服务器，可能会导致信息泄露等安全问题。

背景

很多人害怕通过某些手段找到自己的肉身，或者自己的网络行为被发现，说到底，其实是对现行网络安全的不信任，担心自己受到监控；在初期网络时代，对于电信运营商来说，用户的浏览内容完全可见，毫无隐私可言。随着 HTTPS 的普及（但是还是不能架住流氓，参考 cnnic 事件），浏览内容不能被看到了，但是浏览记录还可能会被监控着。

本文介绍在技术上如何防止自己的身份泄露，对于社工攻击（主动发言暴露身份的）暂且不涉及。而且本文的解决方案最先进和安全的。

本机 IP 泄露​

当我们用 VPN 翻墙时，有两个 IP，一个是本机国内的真实 IP，一个是 VPN 代理服务器的 IP。正常来说，使用 VPN 时，无论访问什么网站，网站方收到的 IP，始终是代理服务器的 IP。

通过域名分流检测 IP 泄露​

但是因为我们想要用路由分流，来提高访问速度，也就是“国内网站用本机真实的 IP，国外网站用 VPN 的代理 IP”。实际上，我们根本无法精确的区分哪个网站是属于中国大陆的，哪个网站不属于中国大陆，然而还是有好心人，整理维护一些数据库，用于区分不同类型的网站。参考 Geosite。

一些网站可以利用 Geosite 的精确度很低的缺点来获取用户的真实 IP，比如说：用户需要访问 A.com ，A.com 在 Geosite 中属于非中国网站，用户在访问 A.com 时，故意在他的网页内隐蔽地对 B.com 发起一次请求，然而 B.com 在 Goesite 里面属于中国大陆网站，从而 B.com 使用了真实的 IP，导致了真实 IP 泄露。

通过 UDP 检测 IP 泄露​

还有一种就是通过请求非 HTTP 协议（例如说 WebRTC），探测用户的真实 IP。因为我们常用的 HTTP 代理协议，只能用于代理 TCP，无法代理 UDP，也就是 UDP 永远只能使用真实的用户 IP，从而导致真实 IP 泄露。

解决 IP 泄露，唯一有效的解决方法就是：使用具有代理 UDP 功能的透明代理，并且不要使用路由分流功能。

DNS 泄露​

什么是 DNS 泄露？当我们访问 google.com 时，必须要先进行 域名解析，从而获取目的服务器的 IP，然后才能打开谷歌，当我们发起 DNS 请求时，也必须要把我们想要的域名发送给 DNS 服务器；DNS 服务器必须要看到域名明文才能把目标服务器的 IP 发还给我们。

由 DNS 运营商泄露​

有一些服从政府安排的 DNS 运营商，例如说阿里云（223.5.5.5）、腾讯云（1.12.12.12）等，你把域名发给他们解析，他们会记录下来，然后就可以随时上报你所访问的域名。

解决 DNS 运营商泄露只能用自己信任的 DNS 提供商，也有部分的会选择自建 DNS 服务器，但成本太高，而且有点技术难度。

所以有的人会信任国外的 DNS 提供商，例如说谷歌（8.8.8.8）、Cloudflare（1.1.1.1） 等提供的 DNS 服务器，但是通常他们都是在国外，所以访问速度堪忧。

中间人挟持的 DNS 泄露​

假如说你想使用处于国外的谷歌 DNS 服务器： udp://8.8.8.8 ，这种 udp 方式的 DNS 是最常见最悠久的方式。

但是这种 DNS 请求是没加密的，也就是说，中间人可以拦截并解析出你想访问的域名，更有甚者，直接挟持返回错误的 IP，在远古的网络时代，运营商经常通过此方法往我们的电脑“弹”广告，许多人苦不堪言。

同时，用 DNS 来阻止用户访问境外网站是 GFW 封锁的最主要手段。

不过幸运的是，业界很早就认识到，没有加密的 DNS 是很邪恶且危险的事情。带有加密的 DNS 服务器，例如说 https://8.8.8.8 ，已经很常见了。

解决中间人挟持泄露必须使用带加密的 DNS 服务器，也就是前缀为 https 和 tls 的那种。

解决 DNS 泄露的最佳方案​

有些事情非常有趣：国外带加密的 DNS 服务器（例如说 https://8.8.8.8） 都是被 GFW 屏蔽的，也就是无论你怎么弄，都是无法使用的；反而不带加密的国外 DNS 服务器却是可以正常使用的，例如说： udp://8.8.8.8。

所以，我们必须要清楚地认识到，使用国外 DNS 提供商并不能解决问题，无论何时都必须要带加密的。

那问题来了：既然不能使用带有加密的国外 DNS 服务器，那不是说废话吗？别担心，UIF 已经你设置好了远程（国外）DNS 是默认走代理的，只要你有可用的翻墙节点，那么就可用，如果你没有翻墙节点，可以试试 免费的翻墙节点。

UIF 还提供了用 IP 来提高分流的精确度，在 自定义路由 中可以看到 IP 分流 选项：

带 ECS 的远程 DNS 还需要可用翻墙节点；CDN 地区选择可能会稍差，取决于 DNS 提供商，仅谷歌等极少量提供商支持。具体使用哪一种，根据自己的需求选择即可。UIF 默认不使用。

有属于自己的一台 VPS 有什么好处？假如你肉身在中国大陆，你在美国的家里有一台常年开机的服务器，通常为了可以像在美国家里一样访问网络的任何资源（也就是俗称翻墙），你可以通过 VPN 技术，把所有的网络流量转发到美国。

同样的，你也可以在美国时，想要使用网易云、QQ音乐等有版权隔离的应用，也需要IP”回国“才能正常使用。

为什么需要内网穿透？​

如果你的需要时“翻墙”、“回国”，通常只需购买具有公网 IP 的 VPS 即可，并不需要内网穿透。但有些人就喜欢折腾。

最佳实践​

必要的：

• 一台具有公网的VPS
• 两台电脑客户端（Client）和服务端（Server）

使用 frp​

将 frp 安装在公网 VPS​

将 frp 安装在服务端​

在服务端安装 UIF​

开启 UIF 入站​

在客户端安装 UIF​

添加 UIF 出站​

客户端启用 Tun 模式或者 HTTP​

启用 Tun，那跟 VPN 无差异，使用 HTTP 就可以满足绝大部分人群。

背景介绍​

由于中国网络环境的特殊性，以及较为封闭的经济制度，导致外贸行业需要某些特殊技术或技巧，才能正常工作。特别是国外电商平台，都有非常全面的防止滥用机制。

例如说：Meta 系列下的产品（Facebook 和 Instagram），只要你用邮箱注册的账号，无论你的 IP 有多纯净，无论你的翻墙技术有多万无一失，无论你所使用的浏览器是否“唯一”，都有非常高的概率会封你号，要求你用手机号验证，并且上传自拍照认证。

本文结论​

先放本文结论，方便许多不想仔细看的人。

• 跨境电商是否需要指纹浏览器 —— 完全不需要

• 跨境电商是否需要海外 IP —— 必须要

• 跨境电商是否需要纯净 IP（原生 IP） —— 最好要

• 要怎么保证运营跨境电商账号安全？ —— 保持 IP 稳定，不滥用，不违法，公司最好注册在国外

跨境电商第一步​

肯定是要解决翻墙问题。连网页都打不开，谈何施展拳脚？第一个，肯定不要去使用机场、VPN 服务商。

最好自建一个专享的、独享的；或者你也可以给钱给别人帮你建好。

稳定的 IP 是必须的​

必须是得自己独享。事实上，自建一个独享是非常简单且便宜的事情，你只需选择一个正确的 VPS 商家，每个月的价格 100 人民币已经是顶天的存在。

如果被封了，你也可以使用“中转”的方式依然使用自己的独享 IP。

最好要纯净的 IP​

目前很多平台都会去检测是否是机房 IP（Hosting），也就是 VPS 商家，还有另外一种是 ISP（住宅 IP）。还是那句，只要你选对了 VPS 商家，每个月 100 人民币，就可以获得住宅 IP。

但是，并不是说住宅 IP 就是纯净的，还是有很多滥用的住宅 IP，比如说“住宅 IP 代理提供商”，他们提供的 IP 其实是万人骑的，表面上是显示 ISP，实际上很多所谓“网赚”项目，早就用烂抛弃这些 IP，然后转销给你个人。

最好使用全局模式和 Socks5​

分流模式可能会导致 DNS 泄露，还有很多代理软件或协议对 UDP 支持不够好，唯一有明确规范的代理协议只有 Socks5。

第二步​

解决收款问题，这个不是翻墙技术问题，我就不发表看法。但是我强烈建议是：注册并使用海外公司来运营。

能省税且金融自由。直接去淘宝、拼多多等平台搜”注册香港公司“，选择销量最高的即可。

第三步​

使用苹果手机、Windows 系统和 Chrome 浏览器来运营。苹果手机是跨境电商必备的，这我就不用多说了，在 IOS 上很多使用“小火箭”来翻墙。

这里肯定是要推荐一下 UIF，可以使用完全免费的 Sing-box。你只需去到 UIF 的设置，点击一下“复制分享链接”，然后把他粘贴到 Sing-box 订阅中，就可以使用了。

第四步​

谷歌账号隔离，也就是所谓的“指纹”。由浏览器的编译版本、设置的语言、什么什么技术特征，说这个指纹纯粹是“炒作概念”。

唯一能追踪你身份的只有 Cookie 和你的 IP；谷歌公司曾几何时还想着开发一个能够用于广告追踪的、有别于 Cookie 的身份识别码，遭到空前反对。

我说的这个例子是想表达，在软件开发时，工程师们是很在意身份能否被追踪的。在维护 Chrome 时，根本没有人在乎所谓什么浏览器的“指纹”，反倒是有“访客模式”和“多个登录用户”，这些都是可以隔离 Cookie 和设置的模式。

所以，你完全不需要理会什么“指纹”影响你的运营。你需要多个账号时，可以直接使用 Chrome 提供的“多用户”即可。当然，那种要维护成千上万个账号的除外，他们不可能使用手动的方式的维护账号。

总结​

我说的这些都是大实话，然而，我在谷歌中搜索“跨境电商是否需要指纹浏览器”，答案都是必须要的。当然不是我反其道而行，而是把“正确答案”推至搜索首页的人就是“指纹浏览器提供商”。

背景介绍​

李老师在 2024-02-25 发布了一则紧急通知

“目前公安部正在我的160万追随者列表和评论区逐个排查关注我的人，一经确认身份就会通知地方警察打电话叫人喝茶”

照成了一定程度的恐慌。

本文列出一些翻墙软件的安全建议，以供读者参考。

总的来说，原理很简单：就是不能将国内”肉身“与墙外身份关联在一起

切勿使用国内手机号注册​

无论是注册哪个社交媒体，用国内手机号注册是绝对不安全的，而且也不应该使用手机号注册，能用邮箱则用邮箱。

邮箱优先选择 ProtonMail，Gmail 注册较为麻烦且可能需要验证手机号。

切勿共用密码和用户名​

有些人可能会贪图方便，所有的网站注册都用同一套用户名和密码。正确的做法：每次注册都用尽可能随机的用户名和密码。

能使用 HTTPS 则使用 HTTPS​

无论使用哪个 VPN 服务器提供商或“机场”，他们都能准确无误地获得你将要访问的域名、IP 或端口。若你使用 HTTPS，那么他们将无法获得你和目标服务器之间的通讯内容，但目标服务器是可以被识别出来的。若不使用 HTTP，那么通讯内容将会完全地暴露。

使用国外加密 DNS​

切勿使用传统无加密的 udp:// DNS，优先使用 https://、tls://的加密 DNS。而且是非中国大陆政府控制的 DNS 提供商，例如：

• https://dns.google/dns-query
• https://1.1.1.1/dns-query

你可以在 UIF 路由 修改你当前所使用的 DNS 地址

不用分流​

不使用 国内直连，国内代理 分流功能，Clash 中称为“规则”，若将访问服务器中插入了后缀为.cn 的网址，UIF 会将其识别国内地址，所以会导致被识别出使用了不同的 IP。

建议使用 全部代理。

你可以在 UIF 路由 修改你当前所使用的路由规则。

自建“翻墙”服务器时，只选“大厂”​

自建”翻墙“服务器，需要购买 VPS，市面上 VPS 的竞争很激烈，有许许多多的可以选择的厂牌。建议只使用”大厂“：

• 谷歌云
• 亚马逊云
• 甲骨文云

切勿使用“不知名”、容易受到威胁的“小厂”，他们往往会很愿意配合调查。

自建“翻墙”服务器时，务必使用 TLS​

无论是哪种代理协议，只要你套上了 TLS，就可以免遭监控、破解。而且很重要的一点，不应该使用 Skip-Verify（insecure）、信任系统默认根证书；最保险方法：自签证书

UIF 的 TLS 配置 默认使用自签证书方式，每个用户都会有自己的 证书 和 秘钥。

留言、评论时注意“社工”攻击​

发布照片、帖子、评论等，往往会在不经意间泄露你的个人信息。尽可能做到“沉默是金”。

QUIC 简介​

QUIC 是基于 UDP 的传输层协议，减少了建立链接所需的 RTT，解决了多路复用所带来的问题。基于 QUIC 的 HTTP 已经被标准委员会接收成为 HTTP3。

**在可预见的未来，HTTP3 将会被广泛使用。**目前，谷歌全系产品已支持 QUIC。

多路复用所带来的问题​

HTTP2是基于 TCP 复用的，虽然可以减少建立链接的延迟，但是传输效率不高，主要的原因是队头阻塞，也就是 A 必须要先于 B，如果即使 B 先到达了目标网络，A 丢失了需要重传，B 也必须要等待 A，即使 B 已经成功被接收了。

队头阻塞 不单单是 TCP 的原因，也有 TLS 的原因。因为 TLS 也有保证正确接收顺序的功能。所以，想要彻底解决这个问题，QUIC 必须要结合 TLS。

基于 UDP 的 QUIC​

基于 UDP 是必然的选择，因为我们不可能网络层重新设计一个传输层协议，这样做的成本是巨大的；参考 IPv6，不兼用带来的成本使得设备产商和使用不积极推广更加先进的协议。

可能有人会疑虑：

UDP 会被运营商 QOS，俗称限速。这样会导致 QUIC 的带宽性能不佳。

我们认为 UDP 传输质量不佳，大概率是因为运营商对 UDP NAT 支持不佳导致的。使用 UDP 并不能突破运营商对网络带宽的限制。

参考这篇文章 #776，其中提到：

这种现象很明显，比如你刚开始测试 kcptun 开启的一段时间，速度是挺快，但是挂久了，就变得非常慢，这时候，只需要释放掉隧道，重新发起新隧道即可

因为 NAT 的原因，QUIC 也有心跳包的设计，用于维护 UDP session，保持路由器能够正确地转发。但是有些路由器可能图省事，一定时间后无论是否活跃都会直接关闭；这样一来，即节省了带宽内存，又不违反 UDP 协议。

一旦随着 HTTP3 的广泛应用，在激烈的竞争环境下，所谓有 QOS 的运营商会被消费者淘汰。

QUIC 的多路复用​

QUIC 在用户层 管理链接（Connection） 和实现拥塞控制。并且使用 Connection ID 来标记每一条链接，不再使用传统的 IP 四元组，也就是说 QUIC 的链接是 IP 无关的。

无论客户端走到哪里，只要有 Connection ID，就可以被服务端识别到。在移动的网络环境中，这样做有巨大好处，例如乘坐汽车、高铁等交通工具时，即使不断更换网络（IP），也无需重新与服务器建立链接后再传输数据。

与 TLS 安全协议高度集成​

QUIC 是强制使用 TLS 的。

上文提到，TLS 也有队头阻塞的问题。为了解决这个问题，QUIC 修改了 TLS 协议，仅使用由 TLS 协商出的秘钥，由 QUIC 来保证传输顺序正确，也就是 TLS 仅在握手阶段被使用到。

代理协议​

像 HTTP 和 Sock5 等基于传输层的代理协议，根据网络协议的制定原则，他们是不会规定传输的具体内容的，也就是说可以根据用户的意愿自由替换使用传输层。

一个较早实现基于 QUIC 的代理工具有 v2ray，他可搭配各种传输层+代理层的组合。

UDP 的传输​

需要传输 UDP 数据的场景，一般都是 VPN 所需要的。他们会截获操作系统的所有流量（包括 DNS），然后传输到代理服务器。

在此之前，我们一般把 UDP 数据放在传输层中，也就是 UDP over TCP。 在 QUIC 中也是可以大同小异，UDP over QUIC。

但是有一个问题，假如这个 UDP 是 QUIC，即 QUIC over QUIC，传输层再加上一个传输层，这又会造成本来我们要解决的 队头阻塞。因此，在代理社区中，一般建议用户禁用 443 UDP 端口，来规避这个问题。

终极解决方案​

QUIC 还设计了 UDP 传输模式，也就是说使用该模式传输的数据，将与正常 UDP 传输数据无异（加密除外）。从理论上来说，UDP over UDP 就是终极解决方案。

比如说 TUIC 就是基于 QUIC 的代理协议。拥有 QUIC 的优点：超低的延迟、完全的多路复用、UDP 代理（目前已被删库，请使用 Hysteria2 代替）。

UIF 支持使用 Hysteria2，欢迎大家使用。

欢迎

UIF 是一个全平台可用，基于 Sing-Box 的第三方客户端。

你可以直接打开 uiforfreedom.github.io 浏览 UIF 的全部功能，但想要在本地使用，UIF 后端是必须的。

查看 快速使用教程

• uif-windows-amd64.zip (x64) (常见)

• uif-linux-amd64.tar.gz (x64) (常见)

• uif-linux-arm64.tar.gz

• uif-linux-armv7.tar.gz

• linux_install.sh

• ui4freedom.service

• ui4freedom.sh

• core.txt

• uif.txt