oynix

于无声处听惊雷,于无色处见繁花

在 ImmortalWrt 上配置 HomeProxy

前阵子在 VPS 上搭了个 Trojan 节点,但也只是一个简易节点,没有订阅链接那一套东西,所以如果想要用的话,就只能手动配置节点地址/端口/类型等参数,而我在软路由上用的是 ClashMeta,用过的都知道这个东西里面有多复杂,要是想把这个节点加进去,然后再修改路由规则,让流量走这个节点,光是想想就头大。

偶然灵光一闪,突然就很想试试在软路由上用 HomeProxy,正好内核是和节点同样用的 Sing-Box,想法一旦产生,就很难再自己消失,经过几天的折腾,现在已经完全切换过去,整体感觉就一个字:神清气爽。

1. 简介

HomeProxy 只是套在 Sing-Box 外面的一层可视化操作的 UI 界面,也可以直接写个配置文件,通过 sing-box 命令直接跑。操作前我还查了查 Sing-Box 内核,发现了它那丧心病狂一样的更新频率,甚至新版本可能不兼容旧版本的配置,但是无妨,不耽误我尝试。

直白来说,这类代理内核,还有 Clash/Xray 等,本质都是在做一件事,拦截目标流量,按照一定的规则,采取不同的策略,或直连、拒绝,或转发到节点,由节点去连接,就这么简单。

按照惯例,我本想找个教程,照着操作就好。但是找了半天也没有找到合适的,要不就是上来直接给个脚本,说是一键部署,也什么都不说,这种脚本轻易都不要运行,除非清楚的每一行都是在干嘛,不然在软路由这种只要正常就不会登上去检查的设备上给你埋个雷,等到发现不知道要到什么时候。

当然也有认真手把手一步一步教的,但是和我的版本不对着,这就导致教程里说的在哪哪哪设置什么什么的,而我这里连入口都没有,版本不同,差别真的很大。我甚至还尝试了替换 HomeProxy 自带的那个版本的 Sing-Box,发现换完就报错跑不起来,于是又换回去了。最终还是回到了自己动手,丰衣足食的路子上。

我用的是 1.11 版本,现在最新的已经是 1.13 了,但我这个版本的 ImmortalWrt 上只能装这个版本,所以以下都是以这个版本为准。虽然配置的是 HomeProxy,但最终它自己生成一个符合 Sing-Box 格式的配置文件,json 格式的,换句话说 Sing-Box 内核标准运行方式就是使用 json 配置文件,而图形化的 HomeProxy 是在生成配置文件。

整体看下来,可以拆成 3 个部分:节点、路由和 DNS。接下来分别说说。

2. 节点

这个的节点指的就是在 VPS 上部署的节点,如果是买的机场,那么就是订阅里的那些个节点,首先要明白一点,不管有多少节点,最终一个请求只会从其中一个节点出去,节点不是靠数量取胜,而是质量,10 个差节点也不如 1 个延迟低、不丢包的节点。

HomeProxy 有单独的节点 Tab,它只有一个节点列表,这个列表里的节点可以来自 3 个地方:手动配置节点信息、导入包含节点信息的链接,以及机场的订阅链接。

因为我一直在用的机场主良心坏了,不给订阅链接了,所以我现在就只有 2 个手动配置的节点,实际上这 2 个都在同一个 VPS 上,只是协议类型不同而已,一个是 Trojan + TLS,一个是 VLESS + Reality。在订阅页面中添加订阅链接后,其中的节点也会出现在这个列表里。

总之,这个列表中的节点,就是所有可选的节点,这种极简的页面看着就很清爽。

3. 路由

路由是用来控制流量走向的,所以至少需要 2 个组成部分,一个是规则,一个是目标。规则目前有 3 类:直连、拒绝和走代理,而只有代理需要目标,也就是节点。

举个例子,比如想要访问谷歌,如果配置的规则是:谷歌-直连,那么 Sing-Box 不会做任何操作,直接将流量发给谷歌;如果配置的规则是:谷歌-拒绝,那么这个请求就走不出去了,Sing-Box 直接返回错误;如果配置的规则是:谷歌-代理,那么 Sing-Box 就会把这个流量发给配置的代理节点。

很简单吧,如果这个能看明白,那么路由就好配置了。

HomeProxy 上路由分了 2 个页面,一个是出站节点组,一个是匹配规则。

3.1 路由节点

在页面上这个叫路由节点,不过我觉得出站节点组这个名字更好理解。出站节点组,其实就是对上一步步配置的节点的管理。

因为我就一个节点,所以我就配置了一出站节点,指向的就是 VLESS + Reality 的节点,虽说是节点组,但组里只有一个节点。

如果有多个节点,可以使用多种纬度管理已经存在的节点,比如,可以创建一个节点组:proxy_us,然后把所有美国的节点加进去,需要美国 IP 的请求就可以选择这个节点组出站,这是根据地区纬度划分。

除此之外,还可以创建:proxy_chatgpt,挑几个相对干净的节点放进去,专门给 ChatGPT 这个对节点有要求的用,防止账号被封,这是从应用角度来划分。总之,只有有需求,就可以根据需求选几个节点放进一个出站节点组里。

上面强调过,一个请求最终只会发给某一个节点,所以当节点组中有多个节点时,这个节点组都会使用 URLTest 模式,也就是测试一下这几个节点的延迟,谁低就用谁,还可以设置测试间隔,比如每隔 5 分钟测试一次,也就是每 5 分钟更新一次这个节点组选中的节点,使用这个节点组作为出站节点时,每次都会使用当前被选中的节点。

3.2 路由规则

路由规则,指的是对请求的域名或者 IP 制定匹配规则。

比如,说回上面提过的谷歌的例子,如果想让访问谷歌走代理,就要配置这样一个规则:当请求的域名是 www.google.com 时,使用 proxy 出站节点组。这样一来,当 Sing-Box 收到请求谷歌的流量时,就会匹配上这个规则,然后谷歌的流量最终就会通过代理出站。

除了匹配域名,还可以匹配 IP 地址,支持 CIDR 的格式,比如,局域网的流量应该都走直连,那么就可以添加一个规则:192.168.0.0/16 - 直连,这样只要前 16 IP 是 192.168,就会匹配上这个规则。

可以看到,我创建了很多规则,把域名和 IP 都分开了,而实际上一个规则里既可以添加域名匹配规则,还可以添加 IP 匹配规则,但是,当这两者同时存在时,它们之间的关系是 and,而不是 or。开始我一看都支持,然后同一个策略的都写到一起了,又有域名又有 IP,然后发现怎么也匹配不上,流量没有按照预期走,一番尝试才发现这个规则。

4. DNS

众所周知,虽然我们访问的是域名,而实际上网络中传输数据包时用到的是 IP 地址,之所以不用我们自己输入 IP,这是因为发起请求前,DNS 会先获取到域名对应的 IP。

传统的 DNS 请求是明文的, RFC 文件中这么规定的,请求中不仅包含你想知道 IP 地址的域名,还包括你自己的 IP,别人如果抓到这个数据包,一眼就能看到是谁要访问哪个域名。

话虽如此,由于种种原因,大多数人依然在裸奔,尤其是在公司网络环境中,网管在后台一看就知道谁在摸鱼,虽然看不到请求内容,但是你也很难解释清楚一天下来为什么请求了这么多次 bilibili.com、iqiyi.com、weibo.com。

如果不在乎这些,这个步骤甚至可以跳过,默认的 DNS 配置就够用了。

但是,为了保护隐私,也是为了更安全,大多都会改用 DoH,DNS over HTTPS,也就是通过 HTTPS 发送请求域名 IP 地址的数据包,这样别人就看不到原本是明文传输的信息了。

常见的 DNS 服务器有很多选择,比如阿里云的 233.5.5.5,谷歌的 8.8.8.8,而网上公开可用的 DoH 服务器也有很多选择,比如谷歌提供的:https://dns.google/dns-query,当希望通过加密的方式获取域名的 IP 时,就可以把请求发给这个 URI 地址。

然后问题就来了,刚刚才说过的,网络中传输数据包用到的都是 IP 地址,而这个 DoH 服务器是个域名,它本身就是获取域名 IP 的,但它自身又是个域名,那怎么办呢。很简单,照常解析一下就可以了,给它配个 DNS 服务器,专门用来把 DoH 的域名解析成 IP,然后再对这个 IP 发送 HTTPS 请求,这样就可以了。

注意,这里要区分清楚,DNS 服务器可以直接获取域名的 IP,但是数据是明文的,而 DoH 服务器需要搭配一个 DNS 服务器,先明文获取 DoH 服务器的 IP,然后再加密获取要访问域名的 IP,这里虽然听着乱,只要能明白这个关系,就不会配置错。

这里的 DNS 规则,和前面的路由规则基本类似,区别就在于,路由规则是用来匹配域名,命中后采用不同的策略,直连、拒绝或是走代理。而 DNS 规则也是用来匹配域名,命中之后使用配在规则里的服务器解析域名的 IP,就这么点区别。

4.1 DNS 服务器

我一共配了 4 个服务器,一个是传统的 DNS 服务器,用的阿里云的,2 个 DoH 服务器,一个是阿里云的,一个是谷歌的。同时还配置了一个专门给 DoH 用的传统 DNS 服务器,DNS 服务器用同一个就可以,但为了便于管理,我分成了两个。

可以看到,每个服务器除了服务器地址,还有一个出站选项,意思就是,发给 DNS/DoH 服务器的流量,使用什么策略出站,直连就是直接发出去,选节点组就是先发给节点,让节点去转发。这里其实都选直连就可以。

4.2 DNS 规则

DNS 规则实际就是把域名和 DNS/DoH 服务器匹配到一块儿。

  • dns_doh:这个规则是给基础域名使用的,里面只有节点的域名、DoH 的域名,服务器用的是 doh,也就是 233.5.5.5,这些是服务跑起来所需的基础域名,只能用 DNS 服务器来解析
  • dns_ad:这个规则是给广告用的,使用的是 geosite-ads,如果是广告的域名,直接拒绝
  • dns_cn:这个规则是给国内网站用的,使用的 geosite-cn 规则集
  • dns_google:这个规则是海外网站用的,目前是空的,因为兜底规则也是这个 DoH 服务器,这里没有命中,会自动走到兜底的服务器

兜底的域名服务器在这里设置:

5. 规则集

最后再说说这个规则集,顾名思义,就是一个集合。前面提到配置规则时,需要在规则里指定域名或是 IP 地址,一个两个的还能写得过来,如果有成千上万个域名、成千上万个 IP 呢,这时候再一个一个手写就很不现实了。

而规则集,则是已经按照一些规则整理好的集合。常用的有这么几个:- geosite-cn:这里面包含了国内绝大多数的网站域名- geoip-cn:这里面包含了国内绝大多数的 IP 地址

比如希望所有的国内网站都走直连,那就可以增加一条规则,匹配方式就选这个 geosite-cn 规则集,策略就选直连,这样一来,当访问绝大多数网站时,都会命中这条规则。此外,如果发现有漏网之鱼,或是有特殊的需求,可以加到额外的规则里。

我一共配置了这么几个,但不是每个都用上了,主要来自 Sing-Box 的库,我把链接放在末尾,如果不想去找也可以直接用。

这里的规则集实质上就是一个文件,支持 2 种来源形式,一种是本地,一种是远程。本地的直接配置本地绝对路径,远程的需要配置一个指向文件的 URL,既然是远程的,那么又涉及到出站流量了,有出站流量就可以设置出站节点组,从 CDN 来的我设置的是直连,从 Github 来的我设置的是走代理,另外还可以设置更新时间,我设置的每天更新一次。

  • geoip-cn
    https://cdn.jsdelivr.net/gh/Loyalsoldier/geoip@release/srs/cn.srs

  • geosite-cn
    https://github.com/SagerNet/sing-geosite/raw/refs/heads/rule-set/geosite-cn.srs

  • geolocation-!cn
    https://github.com/SagerNet/sing-geosite/raw/refs/heads/rule-set/geosite-geolocation-!cn.srs

  • geolocation-cn
    https://github.com/SagerNet/sing-geosite/raw/refs/heads/rule-set/geosite-geolocation-cn.srs

  • geosite-ads-all
    https://github.com/SagerNet/sing-geosite/raw/refs/heads/rule-set/geosite-category-ads-all.srs

  • geosite-ads
    https://github.com/SagerNet/sing-geosite/raw/refs/heads/rule-set/geosite-category-ads.srs

------------- (完) -------------
  • 本文作者: oynix
  • 本文链接: https://oynix.com/2026/04/02036d72b5bc/
  • 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!

欢迎关注我的其它发布渠道