全屋透明代理和多线路，怎样配才有章法

全屋接管前该想清什么

软路由透明代理要先确定接管范围，多出口分流要先确定连接归属。我建议把解析、转发和回程画清楚，再动配置。

全屋设备能访问外部服务，只能说明当前路径可以工作。它不能回答电视是否经过代理，也不能说明工作电脑切换出口后会不会中断。你准备让路由器承担多少事情，就得能解释多少条路径。把这些问题留到故障发生时再研究，排查会很被动。

我接触机场的时间不长，不拿资历替配置背书。这里没有我跑出来的性能数据，也没有可以照搬的线路排名。我更关心判断能否复查：某条规则为什么存在，关闭它会影响谁，发生异常后能不能退回原来的状态。

动手前，你可以把家里的设备按用途写下来。工作电脑可能要保留已有连接，电视主要关心播放是否连续，存储设备还要考虑内网访问。它们接在同一个网络里，不等于应该接受同一套代理规则。

透明代理省掉的是终端上的部分操作，路由器承担的责任却会增加。终端原本自己处理的连接，现在可能经过额外的解析、匹配和封装。出了问题，浏览器里的错误提示未必能指出是哪一层失败。

多线路也有类似的代价。增加出口之前，你要能回答默认出口是谁，代理进程从哪里连接远端，备用线路什么时候接手。缺少这些答案，多接宽带只是让可选路径变多，故障边界并没有变清楚。

线路名称可以帮助理解服务类型，不能代替验证。IEPL、IPLC、CN2 这样的名称，不会自动告诉你家里的 DNS 是否正确，也不会替你处理路由回环。把服务宣传和本地配置混在一起判断，很容易把本地问题归到商家身上。

我会把目标写成能检查的句子：指定设备经过代理，内网访问保持直连，主出口失效后新连接能够恢复，切回时尽量减少业务中断。每句话都对应一个动作和一个预期。含糊的“全屋都顺畅”，没有办法指导你修改配置。

如果你还没理清终端代理和路由器接管的区别，可以先看客户端分别负责什么。确认终端原本如何工作，再把责任迁移到路由器，通常更容易定位变化带来的问题。

数据包究竟怎么走

全屋透明代理的拓扑要同时画出终端请求和代理出站；多出口策略必须覆盖这两条路径，才能解释流量去了哪里。

我习惯从终端往外画。设备发起请求，流量进入局域网，再由路由器决定直连还是交给代理。交给代理以后，还会产生代理进程连接远端的流量。这是不同的处理阶段，不能在图里用同一根箭头含糊带过。

br-lan 可以作为检查局域网入口的线索，tun0 可以作为检查 TUN 接管的线索。但接口存在不代表目标连接经过了它。你还要结合当前规则、接口状态和连接表现，确认入口与出口之间确实连通。

DNS 要另画一条路径。设备向谁询问域名，回答由谁提供，代理规则在什么时候拿到域名信息，都可能影响分流。网页打不开时，连接甚至可能还没走到你正在检查的远端出口。

使用 fake-ip 思路时，终端拿到的应答需要与后续代理处理配合。不能只保留其中一部分，再假定其余环节会自动理解。解析与连接匹配脱节后，表面上像是节点异常，实际应回到应答来源和接管路径检查。

fake-ip-filter 也不是随手堆域名的地方。你发现某个应用异常，应先确认异常发生在解析阶段还是连接阶段，再决定是否调整例外。没有定位就扩大绕过范围，可能让应用恢复，却留下无法解释的分流结果。

接着看直连路径。家庭设备互访、路由器管理和代理远端连接，都要有明确归属。尤其是代理远端连接，它要能从实际出口发出去；如果又被送回代理入口，你看到的可能是不断尝试，却始终没有可用连接。

回程要从外往内再画一遍。请求能离开路由器，不代表回答能交还给原来的设备。多出口、NAT 和 TUN 同时参与时，不能只检查发出的方向。某个终端失联，也不应直接推断为整个路由器失去外网。

你可以用下面的对照检查自己是否漏画了路径：

检查对象	应当能回答的问题	无法回答时先查什么
终端请求	谁决定直连或代理	接管范围与匹配规则
域名解析	谁回答，谁使用回答	DNS 设置与例外
代理出站	从哪个实际出口离开	出口选择与绕过规则
内网回程	回答怎样交还给设备	路由、转发与连接状态

表格里的每一行都应当有自己的证据。代理日志能帮助解释代理处理，却不能独自证明局域网回程正常；路由器能访问外部，也不能替终端完成验证。

拓扑画完以后，我会在图旁边写规则归谁管理。自动生成的路由、手写标记和出口策略如果互相覆盖，单独看每份配置都可能没有明显错误，组合后却会改变实际路径。明确管理边界，比继续增加例外更有用。

怎么验证分流有效

多出口分流是否有效，要靠固定条件下的路径对照判断。我会先保留直连基线，再逐项加入代理和出口策略。

这里不提供出口对比成绩，因为我没有这页对应的测试记录。你可以自己验证，但要把“感觉变快”拆成具体问题：域名能否解析，连接能否建立，内容能否持续传输，切换出口后哪些会话需要重建。

先保存当前可用配置，并记下终端、接入方式和业务。后续对照尽量使用同一个设备、同一种访问动作。今天用电视播放，另一个时候用电脑下载，两边的差异不能只归因于路由策略。

建立基线时，先确认没有代理接管的路径能够工作。局域网访问、普通外部访问和路由器管理都应分别检查。基线本身就有异常，叠加 TUN 之后出现相同症状，不能据此认定 TUN 是原因。

随后只加入代理接管，保留原来的出口选择。观察同一项业务是否出现变化。确认这一阶段可以解释，再引入备用出口和分流规则。这样发生异常时，你至少知道应优先检查哪一组改动。

记录不要只有成功或失败。页面完全没有响应、页面框架出现但内容缺失、连接建立后传输停住，是不同线索。它们不直接等于某个确定故障，却能帮助你安排后续检查，避免盲目替换整份配置。

验证分流时，规则被匹配与业务成功要分开看。标记符合预期，只能说明某个处理步骤发生了；出口可达，也不能说明目标应用正常。把规则状态、实际出口和应用表现放在一起，证据才比较完整。

验证切换要同时观察旧连接和新连接。持续播放或保持会话的应用，可以反映旧连接的表现；重新打开的访问，可以帮助判断新连接如何选路。它们出现不同结果时，先检查连接状态，不要急着改权重。

恢复主出口也值得单独验证。备用线路接手成功，不等于切回过程同样符合预期。你需要知道恢复后哪些连接继续留在原出口，哪些新连接进入主出口，以及这种行为是否符合你的工作安排。

拥塞控制的对照应放在路径已经明确之后。cubic、bbr、bbr2 是可讨论的候选名称，不是固定名次。更改算法的同时又更换节点、出口或业务，即使表现改善，也难以解释是哪项改动起了作用。

我还会保留失败的记录。失败发生时的规则状态、解析结果和业务现象，比一句“后来恢复了”更有价值。恢复可能来自连接重建，也可能来自路径变化；没有记录，就无法判断改动是否真的解决了问题。

如果你想继续整理复查口径，可以看怎样记录网络验证条件。记录的用途是帮助你复现和比较，不是把零散现象包装成线路结论。

关键配置该怎样拆

软路由配置应按转发、标记、选路和代理分别检查。我建议每次只调整能解释的部分，并保留对应的恢复办法。

下面讨论的是配置职责，不是完整安装方案。事实材料里的片段没有覆盖设备的全部接口、规则和出站定义，不能直接拼在一起使用。字段是否受你当前环境支持，要以官方说明为准。

先判断转发是否成立。

路由器能够访问网络，与路由器能够替终端转发，是不同的检查项目。你应确认终端请求确实到达路由器，再检查它被允许走向哪里。只看路由器自身的访问结果，会漏掉终端经过的处理过程。

/etc/sysctl.d/99-router.conf 这样的参数文件，应当有明确用途。转发开关、拥塞控制和连接状态容量解决的问题不同。不要因为它们出现在同一个示例里，就认为应该一起修改。

net.ipv4.tcp_congestion_control=bbr 与 net.core.default_qdisc=fq 可以作为理解参数关系的入口，不能据此承诺吞吐改善。路由器转发的连接和代理进程建立的连接，也不能混为一谈。先确认你准备影响哪部分连接，再讨论参数是否相关。

nf_conntrack_max 同样需要结合状态判断。没有容量不足的证据，单独增大上限不能解释断流原因。你还应关注异常连接是否持续积累，以及业务恢复时连接状态有没有随之变化。

再检查标记有没有互相覆盖。

prerouting 里的标记可以参与后续选路，但标记本身不会完成出口选择。0x1、0x2、0x3、0x4 只是示例值，没有天然对应的运营商或代理含义。它们必须与实际使用这些标记的规则保持一致。

我会先写标记分配表，再写规则。表里记录谁设置标记、谁读取标记、哪些流量允许改写。若自动规则与手写规则都占用同一套标记，应先查清各自边界，不能直接假设它们会互相避让。

顺序也要看实际动作。设置标记不等于后续规则停止处理，后面的匹配仍可能改变结果。内网绕过写在什么位置，代理目标与业务规则发生重叠时谁生效，都需要结合完整规则判断。

proxy_dst 这样的集合还涉及维护问题。集合从哪里取得内容，何时更新，内容为空时会发生什么，都要交代清楚。不能因为配置里有这个名字，就推断代理程序会自动替你填充。

把选路和代理接管接起来。

使用 ip rule 与 ip route 时，应同时理解匹配条件和对应路由表。某条规则存在，不代表目标流量一定命中；某张表有默认出口，也不代表该连接会查到它。

检查 ip rule show 时，要把前后规则一起看。from all lookup main 的存在只能作为路由检查的线索，不能单凭这一行断定配置正常。真正要解释的是目标连接按什么顺序被处理，以及它最终查到哪里。

TUN 相关设置也有各自职责。auto_route 涉及自动路由，route.rules 涉及代理内部匹配，strict_route 的实际约束还要结合当前实现理解。打开某个选项，不能直接等同于所有出口都已受控。

stack: system 可以作为配置讨论的一部分，但这里没有不同设备上的性能依据。我不会把某种处理方式写成普遍更快。设备环境、现有规则与业务表现，都应进入你的验证范围。

若你准备使用 sing-box，可结合sing-box 配置怎样逐项理解检查完整结构。缺少的出站定义和接口信息，需要从自己的环境取得，不能靠片段中的名字猜出来。

出错后先查哪一层

透明代理故障应沿终端、解析、接管和出口依次定位。我会先缩小受影响范围，再决定是否修改路由或代理配置。

出现异常时，先确认是所有设备、某类设备，还是某个应用受影响。电视能播放而电脑打不开页面，和所有终端都失联，需要走的排查路径不同。影响范围本身就是线索，不要在重启后把它丢掉。

再确认内网是否正常。设备能否访问原有的局域网服务，能否打开路由器管理界面，可以帮助判断问题是否已经发生在外部访问之前。内网也异常时，持续更换远端节点通常不会解释根因。

接着把解析和连接分开。域名得不到预期应答，就先沿 DNS 路径查；得到应答后仍然无法连接，再看规则归属和出口。清空缓存可能暂时改变现象，却不能替你确认原来的应答为什么有问题。

路由器自身正常、终端异常时，应比较两者经过的路径。路由器上的进程可能没有经过同样的局域网入口，也可能采用不同的解析和选路。把自身访问成功当作全屋转发正常，会跳过关键差异。

小内容可以加载、传输稍大的内容却停住时，可以把 MTU 与路径相关问题列入候选。但这不是唯一解释。你仍需固定业务与出口，逐项对照，不能看到图片缺失就立即下调所有接口设置。

tcp_mtu_probing=1 是可讨论的辅助设置，不应当被写成通用修复。它不能替代对实际路径和封装关系的理解，也不能据此断言所有应用的传输问题都会消失。

多出口环境里，频繁切换本身也可能制造症状。你要区分出口确实失效，还是检查目标出现异常。主线路被反复判为不可用时，先审查判定依据，再讨论提高切换积极程度。

flush_conntrack 涉及现有连接状态，不是每次恢复线路都要执行的固定动作。清理之前，应知道自己准备影响哪些会话。能够让新连接恢复，与能够保留正在使用的业务，是不同目标。

回退应尽量对应最近的改动。刚加了标记规则就出问题，先移除这组规则观察；刚启用 TUN 就影响终端，先回到原来的接管方式。把多出口、DNS 和代理一起重置，虽然可能恢复，也会丢失定位机会。

不要凭发生时间判断责任。晚上卡顿可能与路径有关，也可能与家庭设备并发、连接状态或代理处理有关。没有分段证据，我不会把它写成机场限速或某条线路拥堵。

如果确认异常集中在代理连接，可以接着看节点超时怎样分段排查。先把本地转发与远端连接分开，向服务商描述问题时才会更具体。

长期使用该保留什么

软路由长期维护要保留可解释的规则和可恢复的配置。我会优先减少隐含关系，再考虑增加出口或自动化策略。

家庭使用可以从容易复查的接管范围开始。先让指定设备按预期工作，再逐步扩大覆盖。全屋接管后再到处加例外，会让你难以判断某个设备到底为什么绕过代理。

工作用途则要把会话连续性写进目标。某个出口暂时不可用时，你是否接受连接重建？主出口恢复后，要不要立即让业务切回？这些是使用安排，不能让默认设置替你决定。

配置副本应和修改说明放在一起。只保存文件，却不记得改动目的，恢复时仍然要重新猜。说明可以很短：为哪类设备增加例外，解决什么现象，怎样确认改动有效，什么情况下撤销。

自动生成的内容也要有归属。代理程序管理的路由，由谁负责检查；出口策略生成的标记，是否允许手工改动。升级或重启后出现变化时，有归属记录才能知道该从哪个组件开始比较。

配置升级前，应先确认当前业务能够恢复。升级后也要复查原来的关键路径，而不是只看进程是否启动。配置文件被接受，与终端实际按预期访问，是不同的验收条件。

增加出口之前，我会要求现有故障能够被描述清楚。若问题只是某个应用解析异常，新接线路未必有帮助；若目标是主出口失效后的备用路径，就应围绕切换与恢复验证，而不是追求更复杂的权重组合。

自动化也有维护成本。检查目标、判定条件和恢复行为都可能需要调整。规则越多，你越需要能解释它们如何共同工作。无法解释的自动切换，发生异常时往往只能靠重启碰运气。

选设备时，不要只看宣传里的吞吐描述。你计划接管的业务、代理处理方式、连接状态与长期维护能力都应纳入考虑。这里没有硬件成绩，不能替具体设备承诺能承受什么规模。

如果配置将来要由别人接手，说明里应能找到默认出口、代理绕过范围、DNS 归属和回退入口。即使一直由你维护，这些记录也能减少过一段时间后重新理解配置的成本。

客服回复速度是我判断服务时会看的硬指标，但客服不能替代你的本地记录。把终端、路径、现象和已做的对照说清楚，才能判断对方有没有在处理问题，而不是只让你反复换节点。

这些现象怎么判断

透明代理与多出口的常见疑问，应回到流量路径和连接状态判断。我把容易混淆的现象拆开，避免用同一项设置包办。

路由器能上网就正常吗

不能这样判断。路由器自身访问成功，只证明它自己的那条路径可以使用。局域网终端还经过入口转发、接管规则和回程处理，故障可能出现在路由器自身访问没有经过的地方。

你可以先确认终端请求有没有进入预期路径，再检查内网绕过和代理远端连接。若改动与 auto_route 同时发生，应对照启用前后的路由变化。不要直接断定是某条内网规则缺失，也不要看到默认路由存在就结束检查。

多出口能加快单连接吗

普通多出口分流不能直接推导出单连接叠加。多条业务连接可以被安排到不同出口，但某条已经建立的连接如何传输，仍受它实际采用的路径约束。

如果下载表现没有超过当前出口的能力，应先确认应用建立了怎样的连接，以及规则把它送到了哪里。不能把“出口都处于可用状态”理解为它们已经共同承载这条连接。多出口的价值也可以体现在备用路径，而不只是吞吐。

跨洋该换拥塞算法吗

跨洋访问表现不佳，不能直接推导出应该换算法。先确认延迟、停顿或传输异常发生在哪一段，再看你能够控制的是终端连接、代理连接，还是路由器的转发行为。

cubic、bbr、bbr2 不应按名字排列优劣。支持情况以官方说明为准；是否值得调整，要靠固定路径后的业务对照判断。这里没有算法对比记录，因此不提供升级收益承诺。

MTU 能照抄配置吗

不能只因示例能被加载，就照搬其中的 MTU。接入方式、封装和实际路径共同影响传输条件，其他人的配置值不能替你确认当前环境。

若出现小请求正常、持续传输停住的现象，可以围绕同一业务做渐进对照，并保留原值。调整后还要复查其他应用。只恢复某个页面，不足以证明整个网络的设置都合适，也不能把所有类似症状都归到 MTU。

检查目标该放在哪里

检查目标应与判断目的对应。你想确认接入出口是否可用，就不能只依赖某个远端应用的状态；你想知道业务能否使用，也不能只看近端地址能否回应。

远端目标并非不能使用，问题是不能让它独自代表整条线路。目标自身异常、跨网路径变化和本地出口故障，可能产生相似现象。把近端可达、外部可达和应用可用分开记录，再决定是否触发切换。

恢复条件同样要清楚。目标重新回应以后，是立即切回，还是让已有连接继续使用当前出口，应根据业务安排。检查机制要服务于你的使用目标，不能让反复切换成为新的故障来源。