个人基于 Mihomo + Docker 实现旁路由的方案

旁路由对我最大的痛点是我没法很快的调整各个链接的路由逻辑，因为有时候网络发生了变化，我需要快速调整不同访问的 proxy

@dryadent 网络变化指的 wifi 切到 5G 这种还是？

最新版 openclash 也用的 mohomo 的吧

手动设置网关这一步就放弃了~~~还是路由器直接搞更方便。

@ChengHaha 是的，也是用的 mihomo 内核。

@dryadent 直接改 mihomo 的配置规则指定不同代理，再 docker restart ，1 秒不到重启完，因为只有一个 mihomo 进程，比软路由重启快多了。

@naver1 可以关闭路由的 dhcp ，再用 docker 自建 dhcp 服务来分地址网关信息。

主要是家里的设备不是都需要外网，所以这种按需手动切换适合我。

看了下，文章可以优化下，IPV6 不支持？

我啥也不懂，用 shellcrash 踩了好多坑

@superchijinpeng ipv6 不太熟悉，很多概念不了解，一直想看相关方面的书，但偷懒没动。

问了一下 chatgpt ,主要改 dns ，tun , rule 就行. 但主要是使用的设备的配置，因为是旁路由，不一定能劫持到 ipv6 的 dns 请求，导致直接没有使用 fake ip 绕过旁路由网关了。手动配置 ipv6 的网关与地址，又有可能导致设备没有公网的 ip ，公网回来访问自己的服务器又有问题。
这一块感觉等大牛给个更加稳健的方案。

```
dns:
ipv6: true

tun:
fake-ipv6-range: fd00:198:18::/64

```

“如果宿主机也需要使用旁路由代理，需要额外创建一个 macvlan shim 网络”

路由器 192.x.1 ，宿主机 192.x.10,容器 192.x.11 。如果在路由器上将宿主机的网关自定义指向 192.x.11 ，是不是就不需要创建 macvlan shim 网络了？ 或者 mihomo 核心允许 lan 的流量，将宿主机的 all_proxy=socks5://192.x.11:7890 直接指向容器不能实现代理吗？

你是用什么机器跑这套 docker 的。我觉得这网络相关部分我还是增配一个小设备跑。
目前我在做算存分离，算部分在用 wyse5070 跑 docker

@supertan 主要是 macvlan 方式，宿主机默认是无法与 docker 容器通信的，必须得创建 macvlan shim 网络宿主机才能访问 docker 容器里的服务。

@loading 一个功率只有 2w 左右的电视盒子在跑。


S905L3A CPU 的电视盒子，也可以看看其它的，比如 N1 ，玩客云之类的。https://v2ex.com/t/908913#reply15

目前看起来还算稳定，跑了快三年，PT 都刷了快上百 T 的流量了。

使用 mosdns + fakeip + 静态路由感觉是最优解，也不需要改网关。moddns 分流 dns 解析到旁路由，旁路由返回 fakeip ，主路由配置 fakeip 网段走旁路由。这样即使旁设备挂了，也只是魔法流量不通了，国内的是正常的。

有玩[dea]( https://github.com/daeuniverse/dae)的吗？

@superhero007 #15 正解！

稳定运行，能用 ipv6

太复杂，我选择 v2rayA

主路由 openwrt + openclash （黑白名单控制设备是否走分流）应该是最简单合理的方案

@CS50 X86 RB5009 是咋回事

有个地方不懂，很多人说不是所有设备都要翻墙，所以手动指定 ip

但是这些不翻墙的设备如果都翻墙了有啥缺点？不是会分流吗

@zsqduke 比如 bt pt 下载机，经过旁路由，以我的规则，国外的 ip 来连导致 bt 会走代理，而且因为旁路由 udp 本身经过多重 nat ，导致可连接性变差，专门的游戏 pc 也一般不会走旁路由。

macvlan 有个问题是没法访问宿主机

前面再加个 mosdns 分流，就不需要把网关指向 mihomo 了，还能减轻 mihomo 负担。

我的方案：linux + adguardhome 缓存（ docker macvlan ）+ mosdns 分流（ docker macvlan ） + mihomo （ docker macvlan ）/ surge （ Mac mini ）

由於比，直接 Debian+Dae 了， akeIP 的，它在於 DNS 污染的很蔽，家庭不於而是利於，大多情下除了有多出口分流需求以外都建用 RealIP

为什么要 docker ，直接 Linux 上启动脚本不就行了吗，搞不明白为什么还要用 docker 一下

@youdoit 机器只跑旁路由的话无所谓。如果有多个服务，比如还跑 BT PT 下载 ，跑 adguardhome 给 TV 用，还是隔离一下比较好。

可以试试 OpenWrt + smartdns + nftables sets + wireguard 方案。转发是原生内核级的（根本上是路由表），支持 TCP, UDP, ICMP 数据包，效率很高，资源占用很低，支持 VPN 的各种玩法，延迟，吞吐量大幅领先于其它。但有一个前提，到远端的 UDP 是可用的。

请问一下，文章中写了使用 tun 模式 + fake-ip-ranger （ 198.18.1 ），但是配置 → DNS → 添加 192.168.1.11 ，请问是写错了，还是这样配置有什么特别之处。

@ccc00 终端设置配置 dns 使用旁路由，这样域名 dns 请求时返回的是 fake ip, fake ip 经过旁路由时，这样在 geosite 没有识别出来时，直接通过 ip 与域名的映射强制访问经过代理。

@arphone 改的玩的

@superhero007 ip 链接的无法解决，而且要求主路由有这个功能。

很多用插件的原因主要是利用 iptables 或者 nftables 来内核转发，tun 的效率并不好。

tun 模式性能很差，我直接用 linux 主机部署 mihimo+tproxy 性能好非常多

tun 速度不行，udp 封的厉害。
我是写了个 sni 识别转代理的东西，布到某个 ip 上，本地 dns 把需要出墙的 host 指向那个 ip,就 ok 了

我用的 redir+realip 方案，速度和兼容性都有保障，个人感觉 dns 泄漏不太重要而且 fakeip 兼容性某些场景下还是有问题

我的建议是直接拉一个虚拟机跑 opopenclash ，只要你的机场稳，非常稳定

@cxh116 #6 我就是觉得改规则太累了，要是有个能直接和 proxy Omega 结合的就好了

@cxh116 感谢回复，等我实践一下

请问怎么测试的？通过局域网设备 telnet, 53 端口不通，但是 7890 是通的

@boycem 53 端口是 udp 的，一般是用 dig 之类的工具来测，可以问一下 ai 怎么测 53 dns

services:
clash:
image: docker.io/metacubex/mihomo:latest # mihomo 是 Clash 的社区维护版本，性能更好
container_name: clash
restart: always
network_mode: host
privileged: true # 特权模式：用于创建 TUN 设备实现透明代理
cap_add:
- NET_ADMIN # 网络管理权限（必需
- SYS_ADMIN # 系统管理权限（必需）
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- /vol1/@appdata/docker-flclash/config:/root/.config/clash
working_dir: /root/.config/clash
environment:
- TZ=Asia/Shanghai
entrypoint: ["/mihomo"]
command: ["-f", "/root/.config/clash/config.yaml"] # 启动命令：指定使用 mihomo 核心，加载 config.yaml 配置文件

dashboard:
image: ghcr.io/metacubex/metacubexd:v1.243.0 # metacubexd 是官方推荐的现代化 Web 面板,这里使用了国内加速镜像源
container_name: clash-dashboard
restart: always
ports:
- "9099:80" # 访问地址： http://NAS_IP:9099
environment:
- CLASH_API_URL=http://192.168.31.14:9095 # 环境变量：指定 Clash API 地址，让面板能控制核心



----------------------------------------------------
上面这个配置，直接使用 host 模式，docker 启动一个 mihomo 内核，ip 直接跟 linux 共用，只占用指定的 9095 7891 7890 等端口，这样局域网内的所有设备包括宿主机都可以 通过 7890 进行代理。

这个方案也不会影响宿主机的网络，就算 docker 挂了，宿主机网络也正常。

这个方案有什么缺点，不用旁路由模式，这样用可以不。

@cxh116 #42 容器内 lookup 没毛病，但是其他设备就不行

macvlan 好评，内网我都是用域名互联的，不关心原生的 ip 方法是否与宿主机不通

@zhlssg #20 我也一直是主路由干就完了，旁路由徒增复杂度

mihomo 会 dns 泄露

@Ealrang dns 泄露参考这个配置 https://github.com/Aethersailor/Custom_OpenClash_Rules/wiki/OpenClash-%E8%AE%BE%E7%BD%AE%E6%96%B9%E6%A1%88

都是大佬