naliqing 发表于 2026-9-5 23:20
那如果通过手机的Type-C连接到路由器，通过usb网络共享，由路由器放大信号行不行？我是专门拿的一个5g手 ...
这种也可以，这个丢包主要是连通性测试，路由强体验就好一点其实:lol
本帖最后由 naliqing 于 2026-9-7 20:36 编辑
广告和追踪拦截 我有 61063 条，它没有
域名规则分流 我有，它没有
常用 App 一键直连规则集 我有 65 组 5445 条，它没有
上面这个描述的这些规则是写死的吗？还说是调用的一些开源的规则，能够自动更新？例如这种：https://github.com/217heidai/adblockfilters
我看其他类似过滤逻辑的，例如flclash/Clash Verge等这种代理软件，是通过链接的形式直接调用的一些开源项目里面的规则，可以实现广告拦截过滤，并且能够自动跟随开源项目持续更新：https://fastly.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblockmihomolite.mrs
如果是写死的规则，当前规则应该是够用了吧？我看你写得有六万多条:lol
也是今天看到了这个帖子https://linux.do/t/topic/2502409/84，感觉广告拦截很有必要，现在的流氓app太多了广告无处不在，最好能将本机直连的流量出口也一起进行拦截过滤就好了，就不用再通过vpn代理之类的软件（如flclash/Clash Verge等）进行配置广告的过滤规则了，我找到的一些开源的规则也就只有五千多条没你这个六万多条丰富。
另外附上这个开源项目还不错：https://github.com/AIsouler/MyClash/tree/main，按照里面的教程配置vpn代理软件后，他的脚本配置是有广告过滤逻辑的规则的，只不过我让ai分析后它的过滤逻辑有点靠后吗，直连情况下可能不经过广告拦截过滤就出去了，可以自己喊ai改下脚本的过滤逻辑，把广告拦截过滤逻辑前置一下，让直连也可以先经过广告拦截过滤的规则。
本帖最后由 wresource 于 2026-9-7 21:12 编辑
naliqing 发表于 2026-9-7 20:18
广告和追踪拦截 我有 61063 条，它没有
域名规则分流 我有，它没有
常用 App 一键 ...
可以自己用txt文件导入啊，只是我给大伙默认内置了一个:lol，自动更新我没设置，实话有点危险了，万一有毒咋整:shutup: ，我目前这套过滤逻辑已经很完善了，用户要做的就是把不喜欢的域名或者ip拉进来就完事，直连，走那个出口我这边也有，所以你能想到的，我这个app其实都做好了，你手机配置一下，其他设备用这个代理，就实现了全部设备的过滤路由，和路由器差不多了:lol，你可以让ai读一下我的开源库，分析一下你的需求能不能实现
牛啊，我的7折叠又能发挥余热了
## 标题
升级到 1.48.76 后规则整体静默失效：直连规则与广告拦截均不生效，全部流量走代理(VPN)出口
## 现象
1. 同样的规则和设置，在 1.40.0 上「直连（放行）」与「广告拦截」都正常；升级到 1.48.76 后**两者同时失效**。
2. 所有连接在 Activity 中的出口都是代理（即 VPN 出口），没有任何 DIRECT 或 REJECT 生效。
3. 规则页仍显示规则已添加、规则集开关显示为开启，**界面没有任何报错**。
4. 共享能正常启动、能上网，所以不是启动失败，也不是出口不可达：是规则判定结果全部落到了默认 PROXY。
## 复现步骤
1. 在 1.40.0 上配置「放行」直连规则 + 开启广告拦截规则集，确认直连出口与广告拦截均生效。
2. 覆盖安装 1.48.76（保留数据）。
3. 保持设置不变，开始共享，从客户端访问一个已设为直连的域名，再打开一个广告域名。
4. 结果：直连域名没有从物理网出去，广告也没有被拦截；Activity 中所有连接出口均为 VPN。
## 期望
升级后规则继续生效：直连走物理出口，广告域名返回 403（REJECT）。
## 实际
规则引擎对全部请求返回默认 PROXY（RuleSrc.DEFAULT），直连与拦截同时失效。
## 已做的排查（请一并参考）
- 规则 → 放行：当前【__】条；规则 → 规则集：广告拦截开关【开/关】，已启用直连组【__】个。
- Activity → 域名详情 → 命中规则显示：【默认 / 你的直连列表 / 内置广告 / 其他】；出口显示：【VPN / 直连】。
- 客户端确实经由本机代理端口访问（Activity 中能看到这些连接），排除"流量没经过代理"。
- 日志中观察到（如有）：rules.rebuilt 的 reject/direct 条数为【__/__】；【有/无】rules.rebuildFailed；【有/无】assetFail；【有/无】probe FAIL。
## 代码线索（供参考，未能确认）
对比 v1.40.0 与 v1.48.76：
- RuleRepository.rebuild 在 1.48 新增了"不发布缺失 assets 的部分快照"的闸门（约 116-123 行）：
任一内置名单读取失败或构建后自检失败，直接 return false，整份 Snapshot 不发布。
v1.40.0 在同样位置是无条件 ruleEngine.update(...) 发布快照。
- 冷启动时 RuleEngine 的 snapshot 为空，未命中任何表时兜底 RuleAction.PROXY（RuleEngine 约 104 行）。
- ProxyServerRepository.startSession 在 1.48 新增 check(ready)（约 235 行），理论上构建失败会导致共享启动失败；
但我的共享能正常启动，所以我怀疑的不是启动失败，而是"构建成功但表为空/规则未装载"，
或者是 enabledRuleGroups 在升级后与引擎内的快照不一致。
- 1.48 新增的 directEgressUnavailable 只覆盖出口缺失，不覆盖"规则未生效"，因此该场景在 UI 上完全静默。