OpenWrt 软路由代理配置思路

先划定范围：这不是刷机教程，也不是某一款插件的按钮说明书。OpenWrt 的代理插件生态更新频繁、界面各异，具体截图很快就会过时，但配置思路多年未变——本文讲的是无论用哪款插件都绕不开的流程与原则，读完再去操作具体插件，能避开绝大多数坑。

适用前提

硬件性能。 代理的加解密与规则匹配相当吃 CPU：百元级家用路由器（单核 MIPS、128MB 内存）装得上插件，但速度往往惨不忍睹。建议至少是双核 ARM、512MB 内存起步的机型，x86 小主机体验最佳。存储空间要装得下插件与规则库，剩余空间不足 20MB 就不要勉强。

刷机与配置风险。 刷第三方固件可能失去保修，操作失误有变砖可能；即便刷机成功，透明代理或 DNS 配置错误也会导致全屋断网。强烈建议不要拿家里唯一的主路由直接实验，先用闲置设备做旁路由验证，动手前备份好配置。整体的风险评估与准备事项可回看路由器教程入口。

一条可用的订阅。 路由器插件普遍兼容 Clash 系订阅格式，还没有订阅的读者可先看兼容 Clash 订阅的机场推荐。

常见插件方案与通用流程

OpenWrt 上的代理插件大体分三类：Clash/mihomo 内核系（以配置文件与策略组为中心）、sing-box 内核系，以及集成多内核、以 LuCI 界面为中心的传统插件。获取渠道只认两种：固件自带的软件源，或插件项目的官方发布页面。本文不提供任何插件下载链接，也不建议安装来历不明的 ipk 包。

无论选哪类，配置流程都是通用的四步：

1. 安装插件及对应内核，重启 LuCI 后确认菜单中出现插件入口；
2. 导入机场订阅，生成节点列表与策略组；
3. 选择工作模式（保持规则模式）与节点，启动服务；
4. 先验证一台终端设备的出口 IP 与 DNS 是否符合预期，再逐步放开到全屋。

导入订阅与策略组

在插件的订阅管理页粘贴机场提供的订阅链接（形如 https://example.com/sub），保存后手动更新一次，节点列表非空才算导入成功。订阅链接等同于账号凭证，不要在求助截图里泄露，相关风险见账号与订阅安全。

策略组沿用 Clash 的概念：「自动选择」组按延迟自动挑节点，地区组用于手动指定出口，流媒体、AI 等专用组按订阅预设分流。路由器场景有一条与单机不同的建议：常用组尽量固定在延迟稳定的节点上，少依赖自动切换——全屋设备共享出口，节点频繁跳动会让部分网站反复要求重新登录。

DNS 设置要点（防污染）

DNS 是软路由方案成败的关键，也是绝大多数「配置完之后全屋打不开网页」的根源。要点三条：

• 境外域名的解析必须经过防污染通道（fake-ip 模式，或经代理链路查询的 DNS），不能直接交给运营商 DNS；
• 插件自带的 DNS 服务与 OpenWrt 系统的 dnsmasq 常有端口与劫持冲突，按插件文档理顺接管关系，不要同时开两套 DNS 劫持；
• 配置完成后要实际验证：被污染的域名应当解析出真实可连接的地址。

污染的原理与验证方法见 DNS 问题排查；想确认解析请求确实没有走运营商通道，可以做一次 DNS 泄漏检测。

分流建议：大陆直连

路由器承载的是全家流量，分流原则要比单机更保守：

• 保持规则模式，境内域名与大陆 IP（GeoIP CN）一律直连，避免国内网站绕行境外导致变慢；
• 网银、支付类应用对出口 IP 敏感，直连能减少风控误伤；
• 对延迟敏感的游戏主机可按设备单独设置绕过代理。

全局模式只用于临时排查，长期开启既浪费订阅流量，也会拖慢所有国内访问。

故障回退方案

出问题时的第一原则：先恢复全屋网络，再排查原因。建议在一切正常时就把回退路径演练一遍：

1. 停用代理插件，重启 dnsmasq 或整机，网络应恢复直连——能恢复就说明问题在插件配置里，可以慢慢查；
2. 如果 LuCI 管理页都打不开，用网线直连路由器 LAN 口，手动指定同网段静态 IP 进入后台；
3. 恢复此前备份的配置；仍不行，最后手段是恢复出厂设置后重新配置。

恢复直连后再定位具体故障：整体断流、超时按连接超时排查处理，节点能通但网页打不开则优先回到上文的 DNS 章节检查。

FAQ

主路由还是旁路由？ 旁路由（插件跑在第二台设备上，需要代理的终端手动把网关指向它）影响面小、回退容易，适合实验阶段；全部验证稳定后，再考虑是否切到主路由方案。

路由器接管后，手机电脑还需要装客户端吗？ 在家不需要；离开家用蜂窝网络或其他 Wi-Fi 时仍需各自的客户端，各平台配置见客户端教程总览。

节点延迟正常，为什么部分网站还是打不开？ 十有八九是 DNS 污染或分流规则误判，按 DNS 问题排查先验证解析结果，再检查对应域名走的策略组。

性能不够会有什么表现？ 开代理后测速明显上不去、CPU 长期接近满载、网页首包变慢。确认瓶颈在路由器后，要么升级硬件，要么退回单机方案——例如服务器和开发机可改用 Linux 命令行 Mihomo 方案。