Direct/Freedom outbound: Add blockDelay to finalRules (30~90s by default)

[Meo597]

#6058 (comment)

[Meo597]

delay 现在是全局的，要不要做到每个 rule 不过好像没啥意义
单位是 sec

[RPRX]

加给 rule，命中哪条就执行哪个，对于 UDP dial 时直接执行它就不会导致 #6058 (comment) ，逐包过滤导致 drop 时不用管

没写的话默认值 30-90s，判断第一条规则为 allow 那里不用管它，文档更新一下

[RPRX]

#6057 也改一下，直接 commit 到那个分支就行

[RPRX]

#6057 只改 UDP，暂时不加选项

[Meo597]

#6057 他现在是没包过会儿再掐，我是给时间范围
还是做成不管他有没有包到点直接掐掉

[RPRX]

#6057 改成随机 30-90s 就行

[RPRX]

@Meo597 咋感觉写得这么怪呢，你这个 timer 确定起作用了吗，先别包装成一个函数了吧，逻辑简单些

[Meo597]

打过日志看的，生效的
那我把这段函数拿掉直接写底下

[Meo597]

buf.Copy 会阻塞，所以到不了 timer.close
除非 input 关了，只可能是 tcp 才会有这种情况，再留着黑洞也没意义，所以关闭 timer
udp 还是会一直阻塞住直到时间到了

[RPRX]

@Meo597

[Meo597]

哦，对，不行这里得改一下 UDP dial 你要解析了封一段时间
我得改一下

[Meo597]

这里状态真复杂，被疯狂毒打了

[Meo597]

现在的行为是：

1. 目标改写
   domain 且非 asis 直接改写目标了（跟以前一样）
   domain 且是 asis 并且存在有效规则，强行 go 解析改写为 ip 无视 sockopt
2. 判定 ip 如果在黑名单中
   udp 开黑洞，此 rule delay 范围 roll 一个，倒计时关闭
   tcp 同样，但如果客户端主动关闭了，那就撑不到那时候，会直接给关了
3. dial 后
   udp 如果 b.UDP != nil 会逐包过滤，否则会漏；断言失败也会漏
   SRV 改写不会被拦

[Meo597]

时间范围 30-60 等价 60-30
单数字就是固定时间

顺带说一下 blackhole 出站那边 tcp 还是会立即掐，udp 是停止发包空闲 x 秒后再掐
没有 mux 的话，墙还是能看到快速打开并关闭了 x 个连接

[Meo597]

上面说着说着又漏了。。UDP 断言失败也会漏过滤
。。。

[RPRX]

udp 如果 b.UDP != nil 会逐包过滤，否则会漏；断言失败也会漏

让你改 dial 那里覆盖到 UDP 就是因为第一个包的 dest 会作为默认写地址（若 b.UDP==nil），所以不会漏，读的都有 b.UDP

外部自定义 dialer 会导致 UDP 走另一套 writer/reader，可能会漏，这个能套一层但里面可能还有 domain 就不好搞，但只有客户端拿 Xray 当 lib 时可能有自定义 dialer，服务端是直接跑 Xray-core 的，所以不会漏

[Meo597]

哦我光以为你是为了防止快速关闭的特征
不知道咋回事……freedom 被疯狂吊打
八字不合

[RPRX]

之前的 UDP 哪有“快速关闭”，又说错了吧，这东西可能性太多了，我也是这几天才重新熟悉的

如果弄 NEXT 架构每一层只管一点点而不是那么多复杂状态挤同一层会轻松很多，但我觉得还是先把传统架构弄完吧

等明/后年 AI 再强一些，用 Golang 给 Xray-core 实现 NEXT 然后让 AI 翻译成 Rust

[Meo597]

tcp 啊，没有 mux 被关了客户端会连续多 dial 几次
我刚开始以为你比较在意这个行为

现在的 ai 上下文一长就完蛋，写的东西味道不对，再等几年感觉有戏

[RPRX]

tcp 啊，没有 mux 被关了客户端会连续多 dial 几次

讨论的不是 UDP 吗，这个 PR 前没在 dial 拦截，只靠 b.UDP 静默 drop，所以反而会监听一个极大概率不会使用的 UDP 出口

我刚开始以为你比较在意这个行为

TCP 的话肯定也在意啊，不能让客户端疯狂开连接

[Meo597]

目前 blackhole 出站的 tcp 也是立马关的要不要加选项

[RPRX]

Blackhole 的 TCP 先不加 delay，因为我还要观察一下新的行为会不会导致什么问题（比如应用“卡住”），没问题的话再加

Blackhole 的 UDP 加 delay 没问题，毕竟 UDP 本来就不一定有回复或“关闭通知”，而 TCP 的话有没有断，应用是能感知到的

[Meo597]

现在 delay 更像是 duration
立即 block 并持续 x 秒

[RPRX]

现在的情况属于是应用觉得自己 TCP dial 成功了、数据也发出去了、TCP 也没断，应用可能就一直等待而不会 fast fallback

下个版本给 VLESS 的响应 pb 加个“拒绝通知”吧，客户端存一下，遇到应用再发包给相同的目标直接本地 fast reject/drop 了

[Meo597]

这样假如某些应用没做心跳的话行为也正常了

[RPRX]

再加上 VLESS 实现代理 ICMP #5178 (comment) ，VLESS，赢！什么叫做现代协议，都六年了刘某人还搁那期待“昙花一现”呢

不断升级不断进化就有，即使有点错 star 到隔壁的，Xray 的 stars 都比 v2fly 多 4.3k 了，三大内核中更是第一，还当是 SSR 呢

[RPRX]

方便转发到频道，重新发了一下