想要组成稳定的路由方案，好的路由固件必不可少，尤其是在OpenWRT下
本文介绍从路由结构推荐、透明代理插件推荐、代理模式推荐还有疑难杂症等等问题

简单介绍

ImmortalWRT 24.10.5 作为PPPoE的主路由
只有两个第三方插件Passwall和Bandix

Passwall的作用

透明代理，按规则分流网站到不同节点

Bandix的作用

直观统计总流量、每个客户端的流量

运行状态

截至到今天，已经稳定运行50天，无任何断流现象发生
2026-06-18_123903.png

核心观点

功能简化

在使用更加复杂的路由系统前，应该询问自己，是否真的需要繁杂的功能。
以ROS举例，有数不清的高级功能，管理大型企业的网络绰绰有余，但作为普通的家用，显然不合适。

家用情况下的缺点

  • 要么使用盗版，要么购买昂贵的正版硬件。
  • 英文界面，对中文使用者不友好。
  • 首次配置需要使用专用客户端。
  • 在家用场景，一般功能下ROS所能做的，OpenWRT也可以做，而OpenWRT能做的，ROS不一定能做。

因此，ROS不符合我的需求。

接下来是旁路结构，不否认旁路结构确实在很多受限的网络环境下，解决了不少的问题，同时又一定程度的增加了整体网络的稳定性

同样的，带来了很多问题

  • 不支持IPV6，或者说代理部分的IPV6是几乎不可用的
  • 非对称路由结构，导致使用金融类应用时，提示网络环境异常
  • 经过旁路由的网络，实际上是再次地址转换，增加了延时
  • 容易造成DNS泄露、污染。增加了隐私泄露风险。

大多数人的旁路结构，一般是爱快做主路由，OpenWRT做旁路由或者硬路由做主路由拨号，OpenWRT旁路由
在仅IPV4下是可以接受的，但一旦增加了IPV6，会发现netflix无法访问、AI无法访问等等

使用仅主路由，是最适合普通家用场景的网络方案。

很多人谈论到OpenWRT做主路由时，便以不稳定为由进行推脱，实际上并非如此。
这些人下载到的OpenWRT固件，一般都是恩山论坛里，一些全自动编译脚本搞出来的大合集固件。
里面有几十个第三方插件，甚至接近一百个插件，这些第三方插件来源不明，有一些插件早已停更，漏洞数不清。

正确的OpenWRT主路由使用方案是什么

使用OpenWRT官方/ImmortalWRT（推荐）是最佳选择。

OpenWRT官方插件本身就是可连续稳定运行的版本，但入门的门槛相对较大
因此推荐使用ImmortalWRT，这是针对中国大陆地区用户的OpenWRT修改版，具有以下的优点

  • 可以在线安装模块。在OpenWRT官方版本时，若要安装内核级模块，需要重新编译刷写系统。而ImmortalWRT则可以直接在线安装。
  • 仓库源的连接速度很快，就像在国内连接一样，真正体验到在线安装插件的魅力。
  • 固件本身小巧简洁，无多余模块，且适配多数设备。

正确下载ImmortalWRT固件的方案

https://firmware-selector.immortalwrt.org/
这是ImmortalWRT 固件的官方网址，选择Generic x86/64，点击第一个下载按钮即可。
2026-06-18_131702.png
若是ARM设备，参考此页面
若是X86设备，参考此页面

刷写完毕后，进行基础网络的相关配置，随后进入本文最重要的部分。

透明代理插件的选择

透明代理，是安装OpenWRT作为主路由的核心动力，否则，随便搞个路由器，或者是企业路由器就可以了。
有多种选择，但我最爱使用的就是Passwall，但此插件有一些小问题，这个稍后讲解。
先来看看其它透明代理插件的特点，可能你会找到属于你的代理插件。

OpenClash

  • 拥有最复杂的界面和规则，适合追求极致自定义的人群使用。
  • 同时，拥有最反人类、最狗屎的前端界面，各种功能互相嵌套，互相糅杂，且界面经常大改，熟悉它需要不少时间。

SSR

  • 古早的王。界面简单干净，适合轻量用户使用。
  • 已经落后时代，现在的中国大陆网络封锁环境下，难以生存，仅适用于中转、专线机场用户。

Nikki （推荐）

  • 和OpenClash一样基于mihomo内核，可在覆写设置中详细设置自己的规则。
  • 不同的是，界面简洁，操作效率高，层级分明。

HomeProxy

  • 基于Sing-Box代理核心的代理插件，界面简约，功能偏少，适合轻量用户使用。

Passwall

  • 目前我在使用的代理插件，界面层级分明，且大多数操作都可以在网页端通过点点鼠标完成，除非有非常大的分流规则需求。
  • 同时，有一些小缺陷，大多数人可能遇不到，这个在后面说。

为何不选择Nikki呢？

首先我讨厌FakeIP，这个功能即使Passwall有，我也尽可能的不去用，除非真的需要。
首先就是，返回IP是保留地址，对于HTTPS/TCP流量还好，一旦遇到NTP或者STUN这种域名+UDP流量，结果是经常性超时。
但FakeIP同样有优点，减少DNS延迟，增快了网页打开速度，一定程度上的防止DNS泄露问题等等。

实际上，还要看你的主要场景是什么，如果和我一样游玩需要P2P的游戏，例如GTA-OL或者是，经常需要使用游戏加速器，那么我建议你不要使用FakeIP模式；若是日常都是网页流量，最多玩玩下载完毕的单机游戏，那么放心可以使用FakeIP模式。

不要担心需要在FakeIP和真实主机模式之间做取舍，FakeIP能取得的优点，真实主机模式也可以取得。
首先是DNS泄露的问题，以Passwall举例，将默认DNS改为远程DNS，这样陌生域名在请求时，默认走远程DNS，也就不会造成DNS泄露了。
2026-06-18_134016.png
再一个是分流问题，一些人认为使用真实主机模式，会造成分流不准确
这个问题，现在的Sing-Box代理核心早就解决，至少我目前使用下来，不会遇到分流不准确的问题。
2026-06-18_134438.png
最后一个，就是FakeIP的DNS请求延时。
很多时候，你打开的浏览器窗口，不是无痕窗口，而是带有缓存的浏览器。
缓存既有网页缓存，又有DNS缓存，同时系统本身又有一层DNS缓存，大多数时候，无需担心打开网页慢的问题。

FakeIP的优点

认为我“左右脑互博”的往下看。

我将下载和纯净分流分别进行了不同规划。
2026-06-18_134729.png
越南的落地节点，很纯净，且有双栈地址，因此可以不使用FakeIP模式，直接使用真实主机，再加一个机场做中转即可。

前置代理不需要有双栈地址，只需要有一个地址你可以连接上即可。
例如良心云机场，只有IPV4单栈出入，同样可以用于中转加速落地节点的速度。

接下来就是下载分流，分流规则我在FakeDNS开启，因为很多下载站有双栈地址，而良心云机场只有IPV4出入站
倘若不点FakeDNS而使用真实主机模式，客户端在获取到正确的DNS解析AAAA记录后，便失败，因此启用FakeDNS。

Bittorrent 协议直接直连，优雅的将Bittorrent流量从代理中过滤。

最后就是Proxy组兜底，建议Proxy组一定选择真实主机模式，因为肯定有一些牛鬼蛇神的不明流量，如果走FakeDNS肯定超时失败，尤其是UDP流量。同时，Proxy组最好支持IPV6出站，这样可做到最大兼容，即使客户端开启了安全DNS也可以代理。

Passwall的一些小问题

有多种选择，但我最爱使用的就是Passwall，但此插件有一些小问题，这个稍后讲解。

在开启 IPv6 透明代理并设置分流规则后，无论使用 sing-box 还是 Xray 作为分流核心，都可能在随机时间发生死机问题
具体表现为
SSH 无法连接或连接极其缓慢、网页管理界面几乎无法加载、CPU 满载、内存占满但没有触发 OOM、产生大量连接。

这种问题是完全随机的，有可能几个小时就出现问题，也有可能半个月不出现。
在Passwall2中也有人反映了相关情况，但是始终未得到解决。

是否解决？

已经解决了。
问题集中在 nftables.sh 的 update_wan_sets() 逻辑中。

原始逻辑问题

nft flush set ... WAN6
echo WAN6_IP | insert

flush → insert 之间存在极短时间窗口：

  • WAN6 set 被清空
  • 新地址尚未写入

与此同时，ip6 daddr @WAN6_SET return短时间内失效。

当IPV6透明代理开启时：

  • WAN6 set 被用作“直连豁免表”
  • 被 PSW_MANGLE_V6 规则实时引用

导致：

  • 本地流量可能误进代理链
  • 出现回环或异常转发
  • 路由器自身服务被拖死
  • nft 规则短时间失效 → 流量爆炸

同时，还有并发问题（非主要原因）：

  • hotplug（网络变化）
  • PassWall reload
  • DHCPv6 / RA 更新
  • 多进程同时更新 nft set

容易导致：

  • set 状态竞争
  • 顺序错乱
  • 覆盖旧数据

改造方案

通过加锁，解决并发带来的副作用。
flock -x update_wan_sets.lock

随后，IPv6 TProxy模式改变行为
修复版的修改点

if ipv6_tproxy == 1
    不 flush WAN6 set
    直接追加新地址
else
    flush + insert（原逻辑）

这样的优点是，避免有空窗期，造成异常流量
缺点是会有暂时残留的地址，一旦重新运行，地址就没了，且完全可以接受，只是几个字的空间而已，相比于随机死机、乱发病的情况，除了在代码层面会有技术洁癖的人来职责，正常使用者完全感受不到，因为服务没有中断（在节点给力的情况下）
目前连续运行50天没有中断，就是最好的证明。

下载地址在哪里

在仓库地址的正式版中，选择适合你浏览器版本的文件下载、安装即可。

一并解决的，还有前置代理不能选择节点组（URLtest）的问题，现在你可以放心大胆的使用节点组作为前置代理了，无需担心落地节点的流量会被中断。

纯净规则

# 需要较为纯净地址的网站
geosite:netflix
geosite:tiktok
geosite:category-ai-!cn
geosite:facebook
geosite:instagram
geosite:whatsapp
geosite:disney
geosite:hbo
geosite:primevideo
geosite:spotify
geosite:18comic
geosite:google-scholar
geosite:reddit
geosite:paypal
geosite:stripe
geosite:wise
geosite:patreon
geosite:playstation
geosite:nintendo
geosite:discord
geosite:telegram
geosite:kaggle
geosite:github-copilot
geosite:rockstar

# 拒绝来自于日本、韩国访客地址的网站
domain:ehentai.org
domain:e-hentai.org
domain:exhentai.org
domain:nhentai.net
domain:hitomi.la
domain:asmhentai.com
domain:hanime.tv
domain:hanime1.me

# IP检测站
ip

# 越南网站
regexp:.*\.vn$
regexp:.*\.com\.vn$
regexp:.*\.net\.vn$
regexp:.*\.org\.vn$
regexp:.*\.edu\.vn$
regexp:.*\.gov\.vn$

下载规则

# 下载
regexp:^(.+\.)?(cdn|dl|download)\.
msecnd.net
domain:registry.npmjs.org

# XBOX 下载
regexp:^(assets[0-9]*|dlassets(-ssl)?)\.xboxlive\.com$
regexp:^(assets[0-9]*|dlassets(-ssl)?)\.xboxlive\.com\.delivery\.microsoft\.com$

# 网盘
geosite:mega
domain:mediafire.com
domain:wetransfer.com
domain:dropboxusercontent.com
domain:drive.google.com
domain:googleusercontent.com
geosite:onedrive

# 容器仓库、镜像仓库
geosite:docker
domain:ghcr.io
domain:raw.githubusercontent.com
domain:nvcr.io
domain:quay.io
domain:gcr.io
domain:mcr.microsoft.com
domain:public.ecr.aws
geosite:huggingface

# 对象存储
domain:storage.googleapis.com
domain:s3.amazonaws.com
domain:blob.core.windows.net
domain:r2.cloudflarestorage.com

# 系统包
domain:archive.ubuntu.com
domain:security.ubuntu.com
domain:archlinux.org

# 开发
geosite:python
domain:pypi.org
domain:files.pythonhosted.org
geosite:android

标签: none

添加新评论