透明代理与进阶配置：32 个常见问题汇总

透明代理与进阶配置｜共 32 问：为什么在编写透明代理的防火墙规则时，一旦发生网络“回环”（Loopback）现象，路由器就会死机或者断网？；采用Tun模式（例如Clash Premium的Tun功能）来实现全局透明代理，与传统的iptables劫持方式相比有什么优势？

最后更新: 2026年09月27日

说明： 本页内容整理自公开资料并经 AI 辅助撰写，非本站实测结论。当您通过本页链接购买时，本站可能获得联盟返利（不会增加您的支付金额）。这构成利益冲突，请结合其他信息源判断。

这一页收了 32 个透明代理和进阶配置的问题，涉及 Clash / mihomo、Surge、OpenClash、PassWall、Xray 这几套东西。

我先说清楚两件事。第一，这些答案整理自公开文档，经 AI 辅助写成，非本站实测结论。第二，路由器和防火墙的改动会影响全家断网，动手前先把现有配置导出备份，改一处测一处。

为什么在编写透明代理的防火墙规则时，一旦发生网络“回环”（Loopback）现象，路由器就会死机或者断网？

回环会把路由器的 CPU 和连接表吃满，所以表现为卡死或断网。

回环是这样形成的：防火墙规则把局域网流量重定向给代理进程，代理进程再往外连代理服务器。如果规则没把代理进程自己发出的包排除掉，这些包又被重定向回代理进程，一圈一圈转下去。每转一圈都新建连接，几秒内连接数和内存就上去了。

破解办法是给代理自己的出站流量开豁免，常见做法有三种：

按标记放行：mihomo 的 routing-mark 会给出站包打 fwmark，iptables / nftables 里匹配这个 mark 直接 RETURN。
按进程身份放行：让代理以单独的用户或用户组运行，用 -m owner --uid-owner / --gid-owner 排除。这只对本机 OUTPUT 链有效。
按目标地址放行：代理服务器的 IP、局域网网段、127.0.0.0/8 等保留地址在重定向之前先 RETURN。

排查时看两个数：conntrack -C 的连接数是不是在猛涨，top 里代理进程 CPU 是不是长期打满。两个都在涨，基本就是回环。

采用Tun模式（例如Clash Premium的Tun功能）来实现全局透明代理，与传统的iptables劫持方式相比有什么优势？

TUN 的好处是规则写起来简单、跨平台、UDP 天然能走；iptables 劫持的好处是路由器上开销可控、能精细到接口和端口。

TUN 会建一张虚拟网卡，再改路由表把流量引过去，客户端从这张网卡读包。在 Windows、macOS 上，这基本是唯一能把不认系统代理的程序也接管的办法。

但「不依赖防火墙规则」这个说法要打折扣。Linux 上 mihomo 的 auto-route 背后同样是在加路由表和 ip rule；拿它做网关给别的设备用时，还要开 IP 转发、处理 DNS 劫持。只是这些由内核程序自动做了，你不用手写。

另外，原文提到的 Clash Premium 内核已经停更。现在带 TUN 的主流选择是 mihomo（原 Clash Meta）和 sing-box，Clash Verge Rev 这类图形客户端用的就是 mihomo。

我的判断：电脑和手机用 TUN；性能弱的路由器，先看插件默认用哪种方式，别为了省事硬切 TUN。

在家庭网络布局里，为何将光猫设为桥接并由路由器负责拨号，是折腾软路由及透明代理的首要基础？

桥接光猫、由路由器拨号，是做主路由式透明代理最省心的布局，但不是唯一的做法。

光猫负责拨号时，它就是网关，DHCP 和端口映射都在它手里。光猫后台权限通常被运营商锁住，你想改网关、改 DNS、开端口转发，经常找不到入口。改成桥接后，拨号和路由交给你自己的路由器或软路由，这些设置才都能碰。

两种情况下可以不桥接：

你只想做旁路由：光猫和主路由照旧，旁路由只接管部分设备的网关，不需要拨号权。
光猫改桥接要找运营商或需要超级管理员密码，你拿不到：先用旁路由方案跑起来，别卡在这一步。

改桥接前记下光猫里的宽带账号和密码，不然桥接后路由器拨不上号。IPTV 业务如果和上网共用一根线，还要单独处理 VLAN，这一步改错了电视会黑屏。

Surge里的Module（模块）指的是什么？它和普通的规则有哪些不同之处？

Module 是可以单独开关的配置片段，普通规则写死在主配置（Profile）里。

一个模块里能放规则、URL 重写、Header 改写、脚本、MITM 主机名这些东西。开启时它叠加到主配置上，关闭时整块撤下，主配置本身不改。

这样做的实际用处有三个：主配置保持干净，出问题好定位；别人维护的模块可以通过 URL 订阅，作者更新你就跟着更新；临时要用的功能（比如某个 App 的去广告）开了测，不行就关，不用回头删规则。

要注意的是，第三方模块里经常带 MITM 和脚本。装之前打开链接看一眼它要解密哪些域名、跑什么脚本。我不会装一个来源说不清、还要求 MITM 银行或支付域名的模块。

相比于传统的TLS，Clash Meta（现已更名为Mihomo）所支持的VLESS Reality协议具备哪些优势？

Reality 的核心好处是：服务端不需要自己的域名和证书，探测者连过来看到的是一个真实网站的 TLS 握手。

机制要说准确。Reality 不是「伪造」一张大厂证书。服务端配一个目标站点（dest）。客户端握手时用约定的密钥在 ClientHello 里带上认证信息；服务端认出是自己的客户端，就用临时证书完成握手并进入代理流程。认不出来的连接（比如审查方的探测），服务端把它原样转发给目标站点，对方拿到的是目标站点真实的证书和响应。

所以它解决的是两个问题：不用买域名、申请证书；主动探测时服务器的表现和一个普通网站转发一致。

目标站点也不是随便挑大厂就行。社区建议选支持 TLS 1.3 和 HTTP/2、离你 VPS 近、没有被墙的站。选苹果、微软这类，你的 VPS IP 和它们的真实 IP 段明显对不上，反而可能成为特征。它降低的是被识别的概率，不等于不会被封。

Surge中的Scripting（脚本）特性能够完成哪些高阶玩法？

Surge 脚本用 JavaScript 在请求的不同阶段插手，能做改包、定时任务和事件响应。

常用的脚本类型：

http-request：请求发出前改 URL、Header 或 Body。
http-response：响应回到 App 前改内容，去广告、改接口返回值多用这个。
cron：按时间表运行，常见用途是定时签到、刷新数据。
event：监听事件，比如 event-name=network-changed，网络切换时触发。

原文把 network-changed 写成一个独立的脚本类型，不准确，它是 event 类型下的一个事件名。

改 HTTPS 内容的前提是对应域名开了 MITM，并且设备装了、信任了 Surge 的证书。没开 MITM 的 HTTPS 请求，脚本看不到内容。脚本写得慢或死循环会拖慢所有匹配的请求，调试时先把匹配范围缩到一个具体的 URL 正则。

在流量接管机制上，Sing-box的TUN模式与系统代理（System Proxy）有什么根本性的差异？

根本差异在接管层级：系统代理靠程序自愿配合，TUN 在网络层把包拦下来。

系统代理只是在系统设置里登记一个 HTTP / SOCKS 地址。浏览器会读，很多命令行工具（git、npm、curl）、游戏、部分 UWP 应用不读，它们的流量就直接出去了。命令行工具可以另外设 HTTP_PROXY / HTTPS_PROXY 环境变量补救，游戏一般没有办法。

TUN 建虚拟网卡并改路由，三层的 IP 包都先进 sing-box，TCP 和 UDP 都能处理。这比系统代理全得多，但不是 100%：

回环地址 127.0.0.1 的流量不经过 TUN。
显式绑定物理网卡发包的程序可能绕过去，sing-box 的 strict_route 就是用来收紧这一点的。
被你在路由规则里排除的网段、应用，本来就不走。

判断是否漏流量：开 TUN 后打开客户端的连接列表，运行那个程序，看它的连接有没有出现在列表里。

Clash Meta的路由分流策略里，GEOSITE与GEOIP匹配功能的底层运作原理是怎样的？

GEOSITE 按域名分类匹配，GEOIP 按 IP 归属地匹配，两者都是查预先打包好的数据库。

GEOSITE 的数据多来自 v2fly/domain-list-community，按标签（google、cn、category-ads 等）分组。它只看请求里的域名，不需要解析，所以放在规则前面既快又不会触发 DNS 查询。

GEOIP 要拿到 IP 才能判断。请求本身是 IP 时直接查；请求是域名时，内核要先解析出 IP。这一步如果用的是国内 DNS，查询记录就会落到国内 DNS 那里，这就是常说的 DNS 泄露。给 IP 类规则加 no-resolve，没有 IP 的域名请求会直接跳过这条规则，不去解析。

实用的顺序是：域名类规则（DOMAIN、GEOSITE、域名规则集）在前，IP 类规则（GEOIP、IP-CIDR）在后并加 no-resolve，末尾一条 MATCH 兜底。GEO 数据库几个月不更新会有漏判，客户端里一般能设自动更新周期。

在Surge的DNS配置模块里，server、local以及encrypted这三种参数分别适用于哪些场景？

这三种 DNS 分工很清楚：普通 DNS 处理日常解析，本地或运营商 DNS 处理内网名和国内 CDN，加密 DNS 防监听和篡改。

在 Surge 配置里，普通 DNS 写在 [General] 的 dns-server，可以填 system 表示用系统下发的 DNS；加密 DNS 写在 encrypted-dns-server，支持 DoH 等格式；某个域名要指定 DNS，写在 [Host] 段里用 server: 语法。原问题里「local」这个词我没在 Surge 手册里对上一个同名参数，按用途理解就行：它指的是把内网域名和国内域名交给路由器或运营商 DNS 去解。

有两点容易踩：

配了加密 DNS 后，按 Surge 手册的描述，普通 DNS 主要只用来解析加密 DNS 服务器自己的域名。你以为国内域名还走运营商 DNS，其实可能没走。
国内网站想拿到就近的 CDN 节点，要让它们走国内 DNS。全部丢给海外 DoH，国内站可能被解析到远的节点，打开变慢。

具体参数名以你当前版本的 Surge 手册为准，版本更新时这里改过不止一次。

Clash Meta的策略组（proxy-groups）功能提供了哪些主流的高可用以及负载均衡机制？

mihomo 的策略组主要有四种：select、url-test、fallback、load-balance。

select：手动选。你点哪个用哪个。
url-test：定时访问 url 字段里的测试地址，选延迟最低的。tolerance 用来设一个容差，差距在容差内不切换，避免节点来回跳。
fallback：按列表顺序用第一个可用的节点，前面的挂了才往后顺延。适合「主力 + 备用」。
load-balance：把连接分到多个节点。策略有 consistent-hashing、round-robin、sticky-sessions。

load-balance 要说清楚：它分的是连接，不是把单个连接的带宽叠加。单个下载任务不会因此变快。它的副作用是出口 IP 变化，登录类网站、ChatGPT 这类会因为 IP 频繁变化弹验证或登出。用 consistent-hashing 能让同一个目标域名固定走同一个节点，副作用小一些。

测试地址别用会被墙或者本身不稳定的站，不然 url-test 会把好节点也判成超时。

为什么Surge控制台里的Dashboard（仪表板）会被评价为极佳的网络抓包工具？

Surge 的 Dashboard 好用，是因为它把每条连接的来源 App、目标、走的规则和策略放在同一个界面里。

你能在里面看到：哪个进程发的请求、目标主机和端口、命中了哪条规则、走了哪个策略、实时速率和耗时。排查「某个 App 为什么不走代理」时，这比翻日志快得多。

要看 HTTPS 请求的完整 Header 和 Body，前提是对该域名开启 MITM 并信任证书，同时打开请求内容的抓取。没开 MITM，只能看到连接层面的信息。

拿它和 Charles 比，适用场景有交集但不重合。Surge 的优势是和代理规则、策略绑在一起；Charles 在断点、改包重放这类调试上更专门。另外，开了 MITM 的应用如果做了证书固定（Certificate Pinning），会直接报错连不上，这不是 Surge 坏了。

Clash Meta中的sniffer（流量嗅探）机制究竟解决了哪些实际问题？

sniffer 解决的是「请求里只有 IP、没有域名」时域名规则失效的问题。

有些程序直接连 IP，或者在 TUN / redir-host 模式下内核只拿到了目标 IP。这时 DOMAIN、GEOSITE 规则都匹配不上。sniffer 会读连接的第一个数据包，从 HTTP 的 Host 头、TLS ClientHello 的 SNI、QUIC 的初始包里取出域名，再拿这个域名去重新匹配规则。

它有明确的边界：

只对带这些字段的协议有效。游戏常用的自定义 UDP 协议里没有域名，嗅不出来。
客户端开了 ECH（加密 ClientHello）时，SNI 是外层的公共名称，嗅到的不是真实站点。
嗅到的域名和实际 IP 可能不一致，mihomo 的 sniffer 有 override-destination 选项决定是否用嗅探结果改写目标，开之前想清楚。

所以它修的是一部分纯 IP 请求，不是全部。游戏分流还是得靠 IP-CIDR 或进程名规则。

怎样通过配置Surge Mac版的Gateway（网关）功能，来实现整个家庭网络的科学上网？

思路是让局域网设备把网关和 DNS 指向那台 Mac，Surge 用增强模式接管这些流量。

步骤大致是：

Mac 用网线接入局域网，固定一个 IP（在路由器里做 DHCP 静态分配，或者在 Mac 网络设置里手动填）。
Surge Mac 打开增强模式和网关相关的开关。只开「系统代理」没用，它只影响这台 Mac 自己。
让其他设备的网关和 DNS 指向 Mac。两种办法：在路由器 DHCP 设置里把网关和 DNS 改成 Mac 的 IP；或者关掉路由器的 DHCP，用 Surge 自带的 DHCP 服务。

很多家用路由器的 DHCP 页面不让改下发的网关，这时只能走第二种，或者在单台设备上手动填网关。

这个方案的代价要算清楚：Mac 一睡眠、一重启，全家断网。系统设置里要关闭自动睡眠，Surge 设为登录启动。电视、游戏机能用，但它们的流量都绕一圈 Mac，Wi-Fi 连接的 Mac 做网关会明显拖慢速度，所以我说用网线。

在Clash Meta的配置里，dns.fake-ip-filter选项主要为了防范什么异常情况？

fake-ip-filter 用来列出「必须拿到真实 IP」的域名，避免 fake-ip 模式把它们弄坏。

fake-ip 模式下，内核收到 DNS 查询就立刻回一个假地址，默认网段是 198.18.0.1/16。多数程序拿假 IP 去连，内核再按域名走规则，没问题。但有几类会出错：

局域网服务、NAS 的内网域名：解析成假 IP 就连不上。
NTP 时间同步、STUN 打洞（语音通话、游戏联机）：需要真实地址。
Windows 网络连接状态检测：拿到假 IP 可能显示「无 Internet」。
下载工具的 Tracker：假 IP 会导致汇报地址异常。

写进 filter 的域名，内核会做正常解析，返回真实 IP。常见写法是加 +.lan、+.local、time.*.com、+.msftconnecttest.com、+.stun.*.* 这类通配。遇到某个 App 在 fake-ip 下异常、切到 redir-host 就好，先把它的域名加进 filter 试一次。

Surge里提供的\

Surge里提供的"Always On" VPN选项，在iOS操作系统的机制下有什么独特的意义？

Always On 的作用是让 VPN 断开后被系统自动拉起，不是让 iOS 不杀进程。

iOS 在内存紧张时照样会结束网络扩展进程，任何 App 都没法「向系统声明自己更重要」。Surge 的这个选项利用的是 iOS 的按需连接（On Demand）规则：连接因为任何原因断了，系统会按规则重新建立它。结果上看，Surge 大部分时间都处于连接状态。

它对谁有用：

依赖 cron 脚本定时运行的人：VPN 不在线，脚本就不会跑。
不希望流量在 VPN 断开的空档里直连出去的人。

原文说推送消息离不开它，这点要改正。WhatsApp、Telegram 的推送走苹果的 APNs 通道，和你的 VPN 是否在线没有直接关系。推送收不到，更可能是 App 自身的后台刷新或通知权限问题，先去系统设置里查这两项。

开了 Always On 后如果想临时断开，要在 Surge 里关，在系统 VPN 设置里关它会被重新拉起。

与直接在配置里罗列rule相比，Clash Meta的rule-providers机制带来了怎样的性能提升？

rule-providers 把大批规则放到外部规则集里，内核按类型建索引，匹配和加载都比逐条写在 rules 里省资源。

逐条写的规则，内核只能从上往下一条条比，规则上万条时启动慢、占内存。规则集分三种 behavior：

domain：纯域名集合，内核会建成域名树，查找速度基本不随条目数线性变慢。
ipcidr：纯 IP 段集合，同样有专门的查找结构。
classical：混合写法，灵活但没有前两种的优化。

mihomo 还支持 mrs 二进制格式，比文本格式体积小、加载快，只适用于 domain 和 ipcidr。

规则集可以设 interval 定时更新，更新在后台进行，不会中断现有连接。有一个坑：规则集的下载地址本身在国外时，要给它指定走代理，否则首次启动下载失败，规则集是空的，分流全乱。

「质的飞跃」这种话我不说。几十条规则的配置，换不换规则集你感受不到差别；上万条时差别才明显。

什么是 TUN 模式？什么时候需要开？

TUN 模式是建一张虚拟网卡，把整机的 IP 流量引进代理内核。遇到有程序不走系统代理时，才需要开它。

典型场景：

游戏、部分 UWP 应用、命令行工具（git、npm、pip）不认系统代理。
需要代理 UDP，比如某些语音通话和游戏联机。
想让所有程序统一按规则分流，而不是逐个配代理。

开之前的条件：Windows 上要管理员权限或安装客户端的服务模式，还需要 Wintun 驱动；macOS 上客户端要安装辅助程序并授权。

开了以后不是所有问题都解决。回环地址不经过 TUN；有些程序绑定物理网卡发包；有的安全软件会和虚拟网卡冲突。原文写「解决 99% 的流量绕过问题」，这个数没有出处，我删了。平时只用浏览器的话，系统代理就够了，不用常开 TUN。

在自己搭建节点时，为何强烈建议采用VLESS+TCP+XTLS-Reality这一协议组合？

VLESS + TCP + Reality 加 Vision 流控，是目前自建节点里被广泛采用的一个组合，原因是它不需要域名和证书，而且针对已知的几种识别方式都做了应对。

各部分分工：

VLESS：轻量的传输协议，本身不加密，靠外层的 TLS / Reality 加密。
Reality：替代传统 TLS。服务端不用自己的证书，探测者会被转发到你配置的目标站点，看到的是那个站点真实的握手。
Vision（flow 填 xtls-rprx-vision）：处理「TLS 里套 TLS」带来的长度特征，并在内层是 TLS 1.3 时减少一层重复加解密。

原文说「蹭用苹果、微软的证书」，这个理解不准确，而且目标站选大厂反而可能让 VPS IP 和域名对不上。目标站一般选支持 TLS 1.3 与 HTTP/2、在你 VPS 附近、国内能正常访问的站。

它不是「最佳方案」这种一劳永逸的东西。审查手段在变，协议也在更新。保持服务端和客户端的 Xray / mihomo 版本不太旧，比纠结组合更重要。

所谓的“链式代理”或“前置代理”是指什么？它能在安全防护方面起到何种作用？

链式代理是让流量先经过节点甲，再由甲转发到节点乙，最终由乙访问目标网站。

各方能看到什么：

你的宽带运营商：只看到你连节点甲。
目标网站：只看到节点乙的 IP。
节点甲：知道你的真实 IP，也知道你连了节点乙。
节点乙：知道节点甲的 IP 和你访问的目标；目标网站不是 HTTPS 时，还能看到内容。

所以原文说「节点乙被攻破你也是安全的」要改正。节点乙被攻破，攻击者看不到你的家庭 IP，但能看到经过它的所有流量去向和未加密内容。节点甲如果在国内，它掌握你的真实 IP，这一环的风险同样存在。

在机场场景里，常见的「中转 + 落地」本质就是链式结构，国内中转改善的是连接质量。拿它提升匿名性，你得清楚每一跳由谁控制。每多一跳，延迟就会加一段，节点越多越慢。

Windows 提示 wintun.sys 缺失或安装失败，导致无法启动软件。

这个提示是 TUN 模式需要的虚拟网卡驱动没加载成功，大多数情况重新以管理员权限运行或装服务模式就能解决。

按这个顺序查：

右键客户端，选「以管理员身份运行」，再开 TUN 试一次。
用 Clash Verge Rev 的话，在设置里安装服务模式，装好后 TUN 不用每次都要管理员权限。
看杀毒软件或 Windows 安全中心的隔离记录，有时 wintun.dll 被当成可疑文件删掉了，恢复并加信任。
确认系统架构：x64 电脑用 amd64 版本，ARM 电脑用 arm64 版本。放错架构的驱动加载不了。

如果客户端安装包里本来就带 Wintun，优先重装客户端，而不是单独找驱动。确实要单独下载，只从 Wintun 官方站点 wintun.net 下，别从网盘或论坛拿别人打包的 dll。驱动文件放在客户端要求的目录（一般是内核文件同目录），放错位置同样加载不了。

以上都做了还不行，看客户端日志里的具体报错，把那一行拿去对照项目的 Issue 区。

QuantumultX配置中如何设置策略组以实现负载均衡和故障转移？

QuantumultX 里做故障转移用 available 类型，做负载分担用 round-robin 或 dest-hash；url-latency-benchmark 是按延迟自动选，不是负载均衡。原文把这两个概念混在了一起。

各类型的用途：

static：手动选节点。
available：按顺序用第一个可用的，前面的不可用才往下走，适合故障转移。
url-latency-benchmark：定时测延迟，自动选最低的那个。
round-robin：轮流用组里的节点，把连接分散开。
dest-hash：按目标地址哈希分配，同一个网站固定走同一个节点，出口 IP 不会乱跳。

在配置文件里，这些写在 [policy] 段。界面上的入口位置随版本变过，我不写死路径，你在「策略」相关页面找「添加策略组」即可。

节点选择上，关键任务放延迟稳定的线路。IPLC 专线这类线路如果你有，可以单独建一个组放在分流规则的高优先级位置。原生 IP影响的是网站把你识别成哪里的用户，和切换频率没有直接关系，别把两件事混起来。

配好后，在分流规则里把目标策略指向这个组，然后手动断开主节点，看是否按预期切到备用。

什么是代理链（Proxy Chain） / 链式代理？

代理链就是让流量依次经过多个节点，每一跳只把数据交给下一跳，最终由最后一跳访问目标网站。

一个例子：你的设备 → 机场中转节点 → 机场落地节点 → 你自建的服务器 → 目标网站。目标网站看到的是你自建服务器的 IP。

在 mihomo 里，可以用节点的 dialer-proxy 字段指定「先经过哪个节点」，也可以用 relay 类型的策略组（新版更推荐前者）。

代价要算清楚：

延迟是每一跳相加的，多一跳就慢一截，跨洋的话更明显。
任何一跳断了，整条链都断，稳定性取决于最差的那一跳。
匿名性取决于每一跳由谁控制，不是跳数越多越安全。

原文把它说成匿名保护的终极手段，我改成更实际的说法：它适合需要固定出口 IP（比如用自己的 VPS 做出口）或分离信任的场景。日常看视频、刷网页用不着它。

家中的网络环境改用软路由实现透明代理之后，为何米家扫地机器人、小度音箱这类智能设备经常掉线？

这类智能设备掉线，常见原因是它们的流量被分到了海外节点，或者拿到了 fake-ip 这种假地址。

国内 IoT 设备连的是厂商在国内的服务器，还会检查自己的出口地区。被代理后出口 IP 在海外，服务器可能拒绝登录；节点一抖动，设备长连接断开就显示离线。

处理方法按优先级：

在软路由的访问控制里，把这些设备的 IP 或 MAC 设为不走代理。OpenClash、PassWall 都有按设备绕过的设置，名称各版本不一样，找「访问控制」「绕过」相关的选项。
给这些设备在路由器里分配固定 IP，不然 IP 变了，绕过规则就失效。
用 fake-ip 模式时，把厂商的域名加进 fake-ip-filter，或让这些设备的 DNS 不经过代理内核。

另外，很多 IoT 设备只支持 2.4GHz Wi-Fi，如果掉线发生在改了 Wi-Fi 设置之后，先排除这一点。改完后把设备断电重启一次，让它重新拿 DHCP 和 DNS。

XTLS 的 Vision（即 Direct 模式）是依靠什么机制来增强代理性能的？

Vision 省性能的办法是：内层已经是 TLS 1.3 加密的数据时，不再在外层重复加密一次，直接转发。

先纠正一个名字。Vision（xtls-rprx-vision）和早期的 xtls-rprx-direct 不是一回事，direct 已经废弃，现在用的是 Vision。

原理大致是：你访问 HTTPS 网站时，数据本身已经被网站的 TLS 加密。外层代理的 TLS 再加密一遍，就是「TLS 里套 TLS」，既浪费 CPU，又会产生可识别的长度特征。Vision 在内层 TLS 握手完成后，把后续的应用数据直接转发，跳过外层的重复加解密；在 Linux 上还能用 splice 让内核直接搬数据。

效果的边界：

只有内层是 TLS 1.3 时才走这条路径。内层是明文 HTTP、或者是 UDP，都享受不到。
在 CPU 弱的路由器或小内存 VPS 上差别明显，性能好的电脑上你未必感觉得到。
它减少的是加解密开销，带宽上限最终还是看线路。

在 vless+tcp+xtls-rprx-vision 的 XTLS 配置中，XTLS-Vision 是通过什么机制来抵御审查系统主动探测的？

在 VLESS+tcp+xtls-rprx-vision 的 XTLS 配置中，XTLS-Vision 是通过什么机制来抵御审查系统主动探测的？

抵御主动探测主要靠的不是 Vision，而是外层的 Reality 或者带回落（fallback）的 TLS。原文把功劳记在了 Vision 上，这里改正。

几个组件各管一件事：

Reality：认不出是自己客户端的连接，服务端把它转发给配置的目标站点，探测者看到的是真实网站的响应。
TLS + fallback：非法请求被回落到一个正常网站（比如 Nginx 上的静态页），探测者看到的是一个普通网站。
Vision：处理「TLS 里套 TLS」的长度特征，通过填充（padding）打散握手阶段的包长分布，对付的是流量分析，不是主动探测。

原文说服务端会「默默丢弃或伪装成超时」，这个说法不对，也不是好的设计。一个正常网站不会对请求毫无响应，沉默本身就是特征。正确的做法是让探测者得到一个普通网站该有的回应。

所以配置时，Vision 和 Reality 一起用，或者 Vision 配合带 fallback 的 TLS。只开 Vision、外层没有伪装，防不住主动探测。

透明代理（Transparent Proxy）技术的底层运作原理是什么？

透明代理的原理是：在网关上用防火墙规则把局域网设备的流量截下来，交给本机的代理内核处理，设备本身不需要做任何配置。

一套完整的透明代理通常有三部分：

流量接管：用 iptables / nftables 的 REDIRECT（只管 TCP）或 TPROXY（TCP 和 UDP 都能管），把包送到代理内核的监听端口。也可以用 TUN 方式。
DNS 接管：把设备发往 53 端口的查询劫持到代理内核或 dnsmasq，否则分流判断拿不到正确的域名信息。
豁免规则：局域网网段、代理服务器 IP、代理自身的出站流量要放行，不然会形成回环。

它的好处是电视、游戏机、IoT 设备连上 Wi-Fi 就生效。坏处是出了问题全家一起受影响，排查也比单机客户端难。

有一个前提常被忽略：设备的网关必须是这台做透明代理的机器。主路由上做，天然满足；旁路由上做，要改 DHCP 下发的网关，或在设备上手动设置。

作为 OpenWrt 平台上最知名的两款代理插件，PassWall 和 OpenClash 在流量分流策略上有什么本质差异？

OpenClash 的分流在 Clash 内核里按规则逐条匹配；PassWall 的分流更多靠路由器上的 ipset / nftset 和 DNS 分流，在内核之前就把国内、国外流量分开。

OpenClash 用 mihomo 内核，规则写在 YAML 里，支持规则集、按进程、按域名、按 IP 的组合，改起来灵活，订阅里自带规则就能直接用。代价是所有被接管的流量都要进内核走一遍规则。

PassWall 的常用模式（比如 GFW 列表、大陆白名单）依赖 dnsmasq 或 chinadns-ng 把域名解析结果写进 ipset / nftset，防火墙按集合决定哪些流量交给代理。国内流量在防火墙层就放行，不经过代理内核，路由器负担轻。PassWall 也支持用 Xray / sing-box 做更细的分流，所以「只能按 IP 分流」这种说法不准确。

怎么选：想要复杂的规则和策略组，用 OpenClash；路由器性能一般、主要需求是国内外分开，用 PassWall。两个插件别同时启用，防火墙规则会打架。

在构建透明代理环境时，Redirect 和 TProxy 这两种流量接管方式有什么不同之处？

REDIRECT 只能接管 TCP，改写目标地址；TPROXY 能接管 TCP 和 UDP，不改写包头。

REDIRECT 在 nat 表里把目标地址改成本机的代理端口。原始目标地址并没有丢：代理程序通过 SO_ORIGINAL_DST 就能取回来，这是标准做法，原文说「需要额外手段恢复」不准确。它真正的短板是对 UDP 无效。

TPROXY 在 mangle 表的 PREROUTING 链上工作，包头不动，代理程序用透明套接字直接收下发往任意地址的包。配置上要多两步：给包打 fwmark，再用 ip rule 和一张单独的路由表把带标记的包送到本机。

两个常见的坑：

TPROXY 只作用于 PREROUTING，路由器自己发出的流量不能直接用，要在 OUTPUT 链打标记再重新路由。
旧内核或精简固件可能没编译 TPROXY 模块，先查 lsmod 或固件说明。

要代理 UDP（游戏、QUIC、语音），用 TPROXY 或 TUN。只代理 TCP、追求配置简单，REDIRECT 够用。「毫无疑问最佳」这种话我不说，要看你需不需要 UDP。

Fake-IP（伪装 IP）模式的原理是什么？它是怎么帮助 OpenClash 实现网页“秒开”的？

Fake-IP 快，是因为设备发出 DNS 查询后立刻拿到一个假地址，省掉了等 DNS 返回的那一段时间。

过程是这样的：设备查询某个域名，Clash 内核不等真实解析，直接从 198.18.0.0/16 这个网段里分一个地址回去，并记下「这个假地址对应这个域名」。设备用假地址发起连接，内核收到后查表得到域名，再按域名匹配规则。走代理的请求，域名交给远端节点去解析；直连的请求，内核在本地做真实解析。

两处要改正：198.18.0.0/15 是保留给网络测试用的地址段，不是局域网地址；「路由器不去公网查询」也只对走代理的域名成立，直连和 IP 类规则仍会触发本地解析。

效果的边界：省下的是首次解析的等待，网页加载的大头通常在后面的连接和传输。副作用有两个：设备会缓存假 IP，关掉 Clash 后一段时间内部分网站打不开，重启设备或清 DNS 缓存可以解决；需要真实 IP 的应用要加进 fake-ip-filter。

透明代理环境下的“IPv6 泄露”是怎么一回事？我们该怎样去阻止这种现象？

IPv6 泄露是指：你的透明代理只处理了 IPv4，而设备拿到了公网 IPv6，访问支持 IPv6 的网站时就从 IPv6 直接出去，绕过了代理。

后果有两种：网站打不开或很慢；或者网站看到的是你家的真实 IPv6 地址。

阻止的办法按简单到复杂：

在 OpenWrt 的 LAN 接口里，关掉 IPv6 的 RA 服务和 DHCPv6 服务，设备就拿不到 IPv6 地址。路径一般在「网络 → 接口 → LAN → DHCP 服务器 → IPv6 设置」，不同固件位置略有出入。
在代理内核的 DNS 设置里过滤 AAAA 记录，mihomo 对应的是 dns 段里的 ipv6: false。设备拿不到 IPv6 地址解析结果，就只能走 IPv4。
如果你的节点支持 IPv6，且透明代理规则也覆盖了 IPv6（ip6tables 或 nftables 的 inet 族），可以让 IPv6 也走代理。这种做法配置最复杂。

改完后用任意 IPv6 检测网站看结果：显示没有 IPv6 连接，或显示的是节点的 IPv6，都算正常。

怎么通过 Docker 容器技术，把一台普通的群晖 NAS 打造成一台合格的旁路由来实现透明代理？

可以做，方法是在群晖上用 macvlan 网络跑一个代理容器，让它在局域网里拥有自己的 IP，再把其他设备的网关和 DNS 指向这个 IP。

步骤大致是：

在 Container Manager（旧版叫 Docker 套件）里，或用命令行建一个 macvlan 网络，父接口选 NAS 接在局域网的那张网卡，网段和网关填你家路由器的。
用这个网络启动一个 mihomo 或 OpenWrt 容器，给它分配一个局域网里没被占用的 IP。
容器里开启 IP 转发和透明代理（TUN 或 TPROXY 方式）。
在手机、电脑上手动把网关和 DNS 改成容器的 IP，或在路由器 DHCP 里统一下发。

几个坑要提前知道：