科学之家

全部导航

软件与配置

工具与服务

阅读与网站

科学之家

动态 · 第 2 页

共 207 条动态,当前显示 30 条

动态时间线

按原始发布时间排序

liandu2024:v0.1.243 及之前在纯 tun 模式下会整份丢掉扣过段的旁路集合,v0.1.244 已修

在定位一台设备旁路失效时给出两点结论:一是该设备运行在「纯 tun(兼容)」模式,auto_redirect 的 nftables 规则起不来时面板会自动降级再起一次;而 v0.1.243 及之前在纯 tun 下会把扣过段的旁路集合整份丢掉,默认分流的 geoip-cn 与 geoip-private 恰好都是扣过段的,于是一份都没旁路、白名单也不会启用,规则页却仍写着「已配置」,他称这是缺陷并已在 v0.1.244 修好,纯 tun 也改用扣段后的集合编进路由表。二是连接被 DNAT 到 192.168.2.2:7892,而 7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口,他判断设备上还有别的代理插件在跑,其规则让 auto_redirect 起不来并先把流量截走,建议停用该插件后重启内核。

作者原文 · 预览

谢谢,文字证据把原因定死了,两件事:

1. 你这台 Open-Box 跑在「纯 tun(兼容)」模式——「入口模式:纯 tun」「nft 里当前没有旁路集合」、nft list set 报 No such file、meta 里没有 entryMode,都指向这一点。auto_redirect 的 nftables 规则起不来时,面板会自动降级成纯 tun 再起一次(内核卡片应该有一条「auto_redirect 起不来,已改用纯 tun 模式」的警告)。而 v0.1.243 及之前在纯 tun 下把扣过段的旁路集合整份丢掉了——默认分流的 geoip-cn / geoip-private 恰好都是扣过段的,所以一份都没旁路、白名单也不会启用,规则页却还写「已配置」。这是我们的缺陷,v0.1.244 已修:纯 tun 也用扣段后的集合(编进路由表),规则页「业务入口」会写明「路由表」和「纯 tun 只用黑名单」的原因。请先升到 v0.1.244。

2. 更关键的:是谁把连接改写到了 7892? conntrack 那行显示连接被 DNAT 到 192.168.2.2:7892。Open-Box 的重定向端口是随机高位端口(比如 33897),7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口。N1 上多半还有别的代理插件在跑,它的 nft / iptables 规则让 sing-box 的 auto_redirect 起不来(所以才降级),并且把流量先截走了。麻烦确认一下,贴文字:

netstat -lnp | grep 7892
ps | grep -iE "clash|mihomo|passwall|ssr|shellcrash" | grep -v grep

把那个插件停掉(或卸掉)之后重启 Open-Box 内核,内核卡片的降级警告应该消失;再用规则页测 test.ustc.edu.cn,右栏「业务入口」应该是「已旁路」。停掉 Open-Box 能跑 578M 说明硬件够,进用户态(不管是哪个插件的)就是 200M 左右,只有入口旁路真正生效才能回到接近 578。

查看完整动态

Fangliding:已将 Xray-core XHTTP 在 Go 1.27 下的连接问题反馈给 Go 上游

在 Xray-core 关于 Go 1.27 构建下 XHTTP 多路复用失效、TLS 握手挂起并导致内存占用的讨论中,Fangliding 表示已将该问题反馈给 Go 上游(golang/go#81646,标题为 x/net/http2 在 go1.27+ 的新包装实现缺少 single flight 机制)。此前同一议题中有贡献者认为该改动是有意为之、不建议向上游反馈。

作者原文 · 预览

我向上游反馈了这个问题 https://github.com/golang/go/issues/81646

查看完整动态

dyhkwong:Exclave 将按 ALPN 兼容性中断调整既有配置、新建配置与内核行为

在跟踪 V2Ray QUIC 传输 ALPN 兼容性中断的议题中,dyhkwong 列出 Exclave 需要的改动:既有配置把「无 ALPN」改写为 ALPN h2 与 http/1.1;新建配置中「无 ALPN」表示 ALPN h3;exclave-core 目前接受 h3、h2 或 http/1.1 之一(他注明这暂不具备抗主动探测能力),未来版本起只接受 h3;Shadowsocks v2ray-plugin 短期内不太可能更新,Exclave 对其始终使用 ALPN h2 与 http/1.1;分享链接始终带上 ALPN 参数,以避免隐式和含糊的默认值。

作者原文 · 预览

So Exclave needs the following changes:

  • For existing profiles in Exclave, rewrite "no ALPN" into ALPN "h2" and "http/1.1".
  • For newly created profiles in Exclave, "no ALPN" means ALPN "h3".
  • For exclave-core, accepts one of ALPN "h3", "h2" or "http/1.1" for now (not active-probing resistant). Starting from a future version, only accepts ALPN "h3".
  • It is unlikely for Shadowsocks v2ray-plugin to receive an update in the near future. Exclave has to always use ALPN "h2" and "http/1.1" for Shadowsocks v2ray-plugin.
  • For share link, always add the ALPN parameter to avoid implicit and ambiguous default values.

What a drama.

查看完整动态

dyhkwong:V2Ray 开发者确认 QUIC ALPN 变更属意外的破坏性改动,服务端临时接受多种 ALPN

在跟踪 V2Ray QUIC 传输破坏性变更的议题中,dyhkwong 表示已向 V2Ray 开发者反馈服务端一侧仍未修复、且这属于破坏性改动;V2Ray 开发者确认这是意外的破坏性改动,V2Ray 服务端目前临时接受 ALPN h3、h2 或 http/1.1 之一。他同时给出了 v2fly/v2ray-core v5.54.2 的发布页面链接。

作者原文 · 预览

https://github.com/v2fly/v2ray-core/releases/tag/v5.54.2

Reported to V2Ray's developer that server side is not fixed and this is a breaking change. V2ray's developer confirmed it is an unexpected breaking change. V2Ray server now accepts one of ALPN "h3", "h2" or "http/1.1" temporarily.

查看完整动态

OneOhCloud:OneBox 自研内核与客户端仍处于内测阶段

在关于 iOS 移动网络下 TUIC 异常的讨论中,OneOhCloud 提醒:自研的内核与客户端仍处于内测阶段,可能会存在影响体验的 bug,UI 设计也非最终定稿版本。

作者原文 · 预览

注意自研的内核与客户端仍旧处于内测阶段,可能会存在影响体验的 bug ,UI 设计也非最终定稿版本。

查看完整动态

2dust 说明 v2rayNG 真实延迟测试看起来变慢的原因

在 v2rayNG 真实延迟测试(real ping)的反馈中,2dust 说明:新版本测试时把延迟和 IP 信息一起返回,所以会比较慢;旧版本先返回延迟再返回 IP 信息,看着比较快。

作者原文 · 预览

新版本测试时,把延迟和IP信息一起返回,所以会比较慢。
旧版本测试时,新返回延迟后再返回 IP 信息,看着比较快

查看完整动态

yosebyte:Nowhere TUI 保留 TCP/UDP 命名,不改为 SOCKS5 TCP/UDP

在 NodePassProject/Nowhere 关于「上下行独立」的问题讨论中,有用户建议把 `nowhere tui` 里的 TCP / UDP 标签改名为 SOCKS5 TCP / SOCKS5 UDP,yosebyte 回应称倾向保留现有命名:TUI 里的 TCP / UDP 表示被代理的流类型,不是底层承载,也不特指 SOCKS5 协议,改成 SOCKS5 TCP / SOCKS5 UDP 会把流量统计与代理前端耦合,反而让抽象更不清晰。他给出的模型是:TUI 的 TCP / UDP = 被代理流类型;TLS / QUIC = Vector 与 Portal 之间的承载;up / down = 各方向载荷的承载选择。

作者原文 · 预览

Regarding the TUI naming, I would prefer to keep TCP and UDP as they are.

They represent the proxied flow type, not the underlying carrier and not specifically the SOCKS5 protocol. Naming them SOCKS5 TCP and SOCKS5 UDP would couple the flow statistics to the proxy frontend and could actually make the abstraction less clear.

The intended model is:

  • TCP / UDP in the TUI = proxied flow type
  • TLS / QUIC = carrier between Vector and Portal
  • up / down = carrier selection for each payload direction

So I think keeping these concepts separate is preferable.

查看完整动态

liandu2024:Open-Box 入口旁路问题按已验证关闭,tun MTU 不在面板层固定

在 Open-Box 关于 auto_redirect 吞吐与入口旁路的问题讨论中,liandu2024 确认重新编译的入口旁路集合为 37110 字节、与预期一致(比原始拷贝略大是因为 36.96.0.0/12 被切成几段),并把「入口旁路」这条按已验证关闭,后续测速数字可在该问题下追加。关于 tun MTU,他表示不打算在面板层固定:65535 是 sing-box 自己在 Linux 上选的默认值,tun 上 MTU 越大,走 tun 的那条路(纯 tun 模式的 TCP 以及 UDP)每个包越大、系统调用越少;固定成 1500 会让纯 tun 模式变慢,对当前 auto_redirect 路径(TCP 在入口 REDIRECT、不经 tun)没有任何影响。他补充用户本地改了也不会坏,只是没有收益。

作者原文 · 预览

验证结果收到,多谢。37110 字节那份就是扣掉 CloudFront 中国段之后重新编的集合(比原始拷贝还大一点是因为 36.96.0.0/12 被切成了几段),和预期一致。方便的话把客户端重新测速的数字也贴一下,好和 616 / 1331 对个账。

MTU 这个我们不打算在面板层固定:65535 是 sing-box 自己给 Linux 选的默认值,tun 上 MTU 越大,走 tun 那条路(纯 tun 模式的 TCP、以及 UDP)每个包越大、系统调用越少;固定成 1500 会让纯 tun 模式变慢,对你现在的 auto_redirect 路径(TCP 在入口 REDIRECT、不经 tun)则没有任何影响。你本地改了也不会坏,只是没收益。

入口旁路这条按已验证关掉;测速数字或别的情况直接在这里追加就行。

查看完整动态

Fangliding 报告 Go 1.27 新版 net/x/http2 缺少单连接复用机制

在 golang/go 的一个问题中,Fangliding 报告 Go 1.27 起新的包装式 net/x/http2 实现缺少旧实现的单连接复用(single flight)机制:以 100 个并发请求测试,新版会为每个请求各发起一次 TCP 拨号(共 100 次),而加 `-tags http2legacy` 的旧实现只拨号 1 次。他认为 net/http 因为事先不知道服务端 HTTP 版本才需要多次拨号,而 x/net/http2 已有前置信息,建议增加一个开关启用单连接复用,或在 ALPN 只包含 h2 时自动启用。该问题目前仍为 open,尚无官方结论。

作者原文 · 预览

Go version

go 1.27 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/codespace/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/codespace/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2735046389=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/workspaces/Xray-core/go.mod'
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/codespace/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

run this code to count dial calls in http2

package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"io"
	"net"
	"net/http"
	"sync"
	"sync/atomic"

	"golang.org/x/net/http2"
)

func main() {
	totalRequests := 100
	targetURL := "https://cp.cloudflare.com/cdn-cgi/trace"

	var dialCount atomic.Int64

	client := &http.Client{
		Transport: &http2.Transport{
			DialTLSContext: func(ctx context.Context, network, addr string, cfg *tls.Config) (c net.Conn, err error) {
				dialCount.Add(1)
				dialer := &tls.Dialer{Config: cfg}
				return dialer.DialContext(ctx, network, addr)
			},
		},
	}

	var wg sync.WaitGroup
	start := make(chan struct{})

	for range totalRequests {
		wg.Add(1)
		go func() {
			defer wg.Done()
			<-start
			resp, err := client.Get(targetURL)
			if err == nil {
				io.Copy(io.Discard, resp.Body)
				resp.Body.Close()
			}
		}()
	}

	close(start)
	wg.Wait()

	fmt.Printf("Total Dial Calls: %d\n", dialCount.Load())
}

What did you see happen?

It made 100 tcp dial calls for every http request

Total Dial Calls: 100

What did you expect to see?

In old http2 implementation, instantly sending multiple requests will only make one TCP dial, this is the expected behavior of http2
run code above with this

go run -tags http2legacy .

And it will return

Total Dial Calls: 1

I understand that HTTP package needs to dial multiple connections because the server HTTP version is unknown, but we have prior knowledge in net/x/http2, and perhaps we can add a config to enable the single flight mechanism in http package (or automatically use when alpn only contains h2?)

查看完整动态

snakem982:Pandora-Box v1.0.24-pre 新增右键修改配置,其余建议暂不考虑

在功能建议讨论中,作者回复:v1.0.24-pre 已添加右键修改配置;配置目录无法迁移的问题希望对方录制短视频后才能进一步分析;其他问题暂时不考虑。

作者原文 · 预览

感谢建议

v1.0.24-pre

已添加右键修改配置

配置目录无法迁移的问题,希望录制个短视频才能进一步分析

其他问题暂时不考虑

查看完整动态

liandu2024:核实 sing-box 1.14 的 tun MTU 默认值,Open-Box 暂不改动 MTU

在 auto_redirect 吞吐讨论中,作者核实:sing-box 1.14 不写 mtu 时 Linux 上默认就是 65535(源码 protocol/tun/inbound.go),不是 9000。开启 auto_redirect 时 LAN 的 TCP 在入口 REDIRECT 到内核的真实 socket、不经过 tun,MSS 按 LAN 口协商;经过 tun 的只有 UDP/ICMP,回程报文大小由远端数据报决定,也到不了分片。因此固定 1500 没有害处、也不会更快,先不动它。

作者原文 · 预览

MTU 核实了:sing-box 1.14 不写 mtu 时 Linux 上默认就是 65535(源码 protocol/tun/inbound.go),不是 9000。不过开着 auto_redirect 时 LAN 的 TCP 是在入口 REDIRECT 到内核的真实 socket,不经过 tun,MSS 按 LAN 口协商;经过 tun 的只有 UDP / ICMP,回程报文大小由远端那个数据报决定,也到不了分片。所以你固定 1500 没有害处,也不会更快,我们先不动它。

查看完整动态

wonfen:Clash Verge Rev 的 Merge dns 字段被覆盖属 bug,已修复

在 clash-verge-rev 关于 Global Merge 的 dns 段被「DNS 覆写」开关影响的问题讨论中,wonfen 表示 merge 的 dns 字段被合并属于 bug,已由提交 6a85d03「fix(enhance): replace DNS fields in merge overrides」修复,该提交改为替换 DNS 映射字段与 hosts 而非保留旧条目,同时保留未指定的 DNS 字段、DNS 覆写优先级与显式空值。他同时说明优先级规则:除 `dns.ipv6` 外,其余 dns 键在 GUI 设置里没有开启或留空值时,由 Merge / Script 覆盖 GUI。

作者原文 · 预览
  1. merge dns字段是合并是bug,已修复:https://github.com/clash-verge-rev/clash-verge-rev/commit/6a85d0344e5df34c750ca3158e53b8b37a5ddf82

dns.ipv6 以外的 dns 键,是 Merge/Script 压过 GUI,不是 GUI 压过 Merge/Script

如果GUI设置里没有开启或留空值的话,是 Merge/Script 压过 GUI

查看完整动态

wonfen:Clash Verge Rev 修复切换订阅后 DNS 覆写自动关闭的问题

在「切换订阅 DNS 覆写自动关闭」问题讨论中,作者回复:merge dns 字段的合并是 bug,已修复(提交 6a85d03);目前已改为首次提示,且 DNS 覆写与订阅绑定。

作者原文 · 预览

merge dns字段是合并是bug,已修复:https://github.com/clash-verge-rev/clash-verge-rev/commit/6a85d0344e5df34c750ca3158e53b8b37a5ddf82

目前已改为首次提示,且DNS覆写和订阅绑定

查看完整动态

yiguodev:OneXray 的 JSON 编辑器补上全选/复制/剪切/粘贴菜单

作者回复:JSON 编辑器在与 re_editor 集成时缺失选择菜单,已在移动端长按菜单与桌面端右键菜单中加入全选、复制、剪切、粘贴,覆盖 Raw JSON、高级自定义路由 JSON 与节点 JSON 编辑器;菜单行为已由 iOS、Android、macOS 的自动化组件测试覆盖,尚未在 iOS 18.7.8 真机上验证;该修复将包含在下一个版本中。

作者原文 · 预览

Thanks for reporting this. The JSON editor's selection menu was missing from OneXray's integration with re_editor.

We have added Select All, Copy, Cut, and Paste through a long-press menu on mobile and a right-click menu on desktop. The fix applies to Raw JSON, advanced custom routing JSON, and node JSON editors.

The menu behavior is covered by automated widget tests for iOS, Android, and macOS. We have not yet verified it on a physical device running iOS 18.7.8.

The fix will be included in the next release. Closing this issue as fixed.

查看完整动态

dyhkwong:Exclave 说明不支持 AmneziaWG 的理由

在 AmneziaWG 支持请求讨论中,作者列出不支持的理由:协议设计与质量不佳(作者称其只是带易检测混淆头的 WireGuard,完全不抗封锁);没有协议规范,他人只能逐 bug 兼容或直接引入其库;付费高级版背书,对方可随时改变对免费版的态度;Exclave 是支持代理协议的代理软件而非 VPN 软件,支持 VPN 协议需做三层-四层-三层转换,性能与体验较差,且只能代理 TCP 与 UDP。作者并表示 Exclave 支持 WireGuard 本身是个失误,只对 Cloudflare WARP 滥用者有利,WireGuard 适用既往条款,新协议不适用。

作者原文 · 预览
  • Poor protocol design and quality. It is only the WireGuard protocol with some easily detectable obfuscation headers. It is not resistant to the firewall at all.
  • No protocol specification. They did not document the protocol details, so others can only bug-to-bug compatible with them or import their library directly.
  • Paid premium version endorsement. They can change their attitude at any time towards their free (gratis) version. We don't want to endorse them.
  • VPN protocol. Exclave is a proxy software with the support for proxy protocols, and is NOT a VPN software. Supporting a VPN protocol requires to proceed a layer3-layer4-layer3 conversion, which will make the performance and user experience pretty poor. What's worse, we can only proxy TCP payload and UDP, and can not handle Layer 3 protocols and other Layer 4 protocols, and can not establish a virtual private network, defeating the purpose of a VPN protocol. Exclave did support WireGuard, but I think supporting WireGuard was a fault, which was only beneficial to Cloudflare WARP abusers. WireGuard is applicable to grandfather clause, but new protocols are not.
查看完整动态

lmlm:Hey v1.3.5 升级到 libXray v26.7.28,并说明此前回退的原因

在支持 libXray v26.7.28 的问题讨论中,作者更新:v1.3.5 已升级到 libXray v26.7.28(工具链换成 star4277/ohos-go v1.26.5)。此前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV(日志停在 VPN created,没有 Xray started);根因是自身桥接代码:新版 libXray 加载后又调用 setenv 设置资源目录,而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时,此时改环境变量会与初始化线程竞争并读到野指针崩溃,与工具链本身和 TLS 无关。修法是把设置资源目录的时机挪到首次加载库之前,已在真机反复验证。sing-box 同步用新工具链重编,版本仍是 1.12.25,1.13.18 因 libbox API 大改暂缓。

作者原文 · 预览

更新:v1.3.5 已升级到 libXray v26.7.28(工具链换成 star4277/ohos-go v1.26.5)。

之前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV(日志停在 VPN created,没有 Xray started)。定位下来根因是我们自己桥接代码的问题:新版 libXray 加载后,代码里紧接着又调用了 setenv 设置资源目录,而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时,这时候再改环境变量会和初始化线程产生竞争,导致其读到野指针崩溃。和工具链本身、TLS 都没有关系——这也印证了你和 @huopingzi 反馈的「TUN fd → setTunFd()」路径本身是可行的。修法是把设置资源目录的时机挪到首次加载库之前,真机上反复验证过(连续多次连接均正常,VLESS/REALITY 通,sing-box 切换到新核心跑 VLESS 也验证了数据面有真实吞吐)。

sing-box 同步用新工具链重编了(版本仍是 1.12.25,1.13.18 因 libbox API 大改暂缓)。

感谢你和 @huopingzi 提供的工具链信息和调用方式参考,这个 issue 先关闭,后续如果要跟进原生 TUN 直连(去掉 tun2socks 这一跳)或 sing-box 1.13.18 会再开新 issue 跟踪。

查看完整动态

dyhkwong:记录 V2Ray v5.54.1 修改 QUIC 传输默认 ALPN 造成的兼容性中断

作者开帖跟踪:V2Ray 在 v5.54.1 中为了修复「安全问题」,把 QUIC 传输的默认 ALPN 从 h2 和 http/1.1 改为 h3,且未说明这是破坏性变更;更严重的是只改了客户端、没改服务端。作者认为即便要做破坏性变更,也应默认不设 ALPN 而不是 h3,但由于 V2Ray 的基础设施,默认不设 ALPN 并不容易实现。该变更还会破坏他们自己的 Shadowsocks v2ray-plugin 实现。作者说明这并非新发现的问题,已在 Exclave wiki 的配置页记录,因为改动会破坏与 V2Ray 的兼容性,一直没有机会调整该行为。

作者原文 · 预览

https://github.com/v2fly/v2ray-core/releases/tag/v5.54.1

In this version, to fix the "security issue", V2Ray changed the default ALPN of QUIC transport from "h2" and "http/1.1" to "h3", without mentioning this is a breaking change.

What's worse, they only changed the client side and forgot to change the server side.

What's worse, even if they need to make some break changes, the should default to no ALPN rather than ALPN "h3". However, due to V2Ray's infrastructure, defaulting to no ALPN is not an easy task.

What's worse, this will also break our Shadowsocks v2ray-plugin implementation.

This is NOT a newly discovered problem. We have documented this in Exclave wiki. Because changing this behavior will break the compatibility with V2Ray, we have never had the chance to change this behavior.

查看完整动态

wonfen:Clash Verge Rev 增加重装 Service 可修复目录权限的提示

在 tun 模式程序卡住断网(code 1003)的问题讨论中,作者贴出提交 bffe91d 并说明:增加了重装提示,重装 Service 可以修复目录权限。

作者原文 · 预览

https://github.com/clash-verge-rev/clash-verge-rev/commit/bffe91db5eed88995ed1d3becc211e6f590ed47f

增加了重装提示:重装 Service 可以修复目录权限

查看完整动态

wonfen:Clash Verge Rev 本次更新会在检测到端口占用时自动切换混合端口

在 clash-verge-rev 关于「Windows 下检测 Hyper-V 保留端口范围、混合端口无法绑定时引导用户」的功能讨论中,wonfen 回复称,检测到端口占用后自动切换端口是本次更新的重要特性之一,并附上实现该行为的提交(自动选择可用的混合代理端口、协调监听端口变更、检测 Windows 监听端口冲突)。

作者原文 · 预览

检测到端口占用,自动切换端口是本次更新的重要特性之一
https://github.com/clash-verge-rev/clash-verge-rev/commit/7796259b0394df73bf35a6f1984a7f8d96603690

查看完整动态

wonfen 说明 Clash Verge Rev 会隔离冲突的 provider 缓存路径

wonfen 在 Clash Verge Rev #7989 中给出修复 commit,并说明不同来源的订阅或规则集共用缓存路径时,会自动分开保存。

作者原文 · 预览

https://github.com/clash-verge-rev/clash-verge-rev/commit/3b958acb22b2ad9fa360245f97d109f245908ea9
不同来源的订阅或规则集共用缓存路径时,会自动分开保存

查看完整动态

Fangliding 指出 XHTTP 握手阻塞问题可能成为 release blocker

Fangliding 在 Xray-core #6797 中表示,即使对正常 HTTP/2,TLS 握手等待期间多个请求也理应被阻塞;如果该问题存在,可能又会成为 release blocker,并建议反馈给 golang/go。

作者原文 · 预览

这哪怕对于正常的http2都是相当大的问题 多个请求理应被阻塞住等待握手返回 也许应该反馈给 golang/go ?
如果问题存在又release blocker了

查看完整动态

wonfen 说明 Clash Verge Rev 的 DNS GUI 设置高于 Merge 与 Script

wonfen 在 Clash Verge Rev #7994 中表示,dns.ipv6 的 GUI 设置高于 Merge/Script;DNS 覆写自动关闭提示只对原始配置生效,不修改 Merge 和 Script 行为。只要订阅包含 DNS 字段,每次重启该开关都会自动关闭并弹通知,即使最终有效配置由 Merge 定义。

作者原文 · 预览

并非bug;就是这样设计的:

  1. dns.ipv6 GUI设置高于merge/Script

2.自动关闭DNS覆写的提示,只对原始配置生效,并不会修改 Merge 和 Script 的行为。
#[serde(skip)][verge.rs:87],只要订阅含配置的 DNS 字段,每次重启开关都会自动关掉并弹通知,哪怕你的 dns 段完全由 Merge 定义、开关开关根本不影响最终的有效配置

查看完整动态

Memory2314:Clash Party 启动时序可能引发 TUN 初始化竞态

Memory2314 表示,Clash Party 某次提交把启动完成时机提前到 API 管道开始监听,可能让启动后的配置 PATCH 与 DNS/TUN 初始化并发;他称这个问题稍后会修复。

作者原文 · 预览

经排查 9a0099db2b79cbea74bb789226241f98b5d23e00 这个提交把启动完成时机从:
等待 start initial compatible provider default

提前成:
API 管道刚开始监听就执行 completeCoreStartup()
启动后的配置 PATCH 可能与 DNS/TUN 初始化并发

这个问题稍后会修复

查看完整动态

Fangliding:Xray 保留该依赖版本主要是为了 ECH 隐藏 ALPN

Fangliding 说,依赖最终会由最上层仓库统一,Xray 使用该版本主要是为了他此前编写的 ECH 隐藏 ALPN,除此之外没有太多必要。

作者原文 · 预览

顺便把依赖都升到最新版吧,uTLS 那个和 Xray-core 对齐

依赖最后会被最上面的仓库拉平的 这里改了也没啥用 xray用那个版本主要是为了我之前写的ECH隐藏alpn 除此之外没啥很必要的

查看完整动态

RPRX:AGI 时代 Xray 仍由维护者决定理念、安全策略与协议标准

RPRX 在 Xray-core #6773 的讨论中表示,他认为即使 AI 能生成大量非核心代码,Xray 在 AGI 时代的核心价值仍包括由维护者决定 CDN、网盘等使用理念与默认或强制安全策略,以及设计 VLESS 相关协议标准并提供可互联、可直接运行和分享节点的预构建核心;VLESS Encryption 这类核心加密则最好仍由人来编写。

作者原文 · 预览

Xray-core 可以更名 Xray-vibe 了,不是,我看隔壁 3x-ui 天天 vibe 也是挺香的,AI 越来越强了,要不拿赞助费充 GPT-6 Astra

AGI 时代 Xray 的核心价值大概是理念:“CDN、网盘等不算滥用”以及各种默认/强制的安全策略等,这些还是得靠维护者来决定

以及 VLESS 相关协议标准:将天马行空的想法设计为标准,并提供两端可互联的预构建 core,下载就能直接运行、节点可分享

还有 VLESS Encryption 这种最好是由人来写、相对一劳永逸的核心加密,至于其它的非核心代码,说实话 vibe 一个月要啥有啥

查看完整动态

liandu2024:Open-Box 测速地址可全局或按自动择优组修改

liandu2024 在 Open-Box #184 中说明,测速地址已经可以在“设置 → 后端设置”全局修改,也可在单个自动择优组中单独设置,保存后需重启内核。他同时指出,测速请求由节点服务器访问目标地址,Cloudflare 只处理到节点的 WS + TLS 隧道;EOF 更可能与 VMess 参数或服务端 80 端口出站有关,换用 HTTPS 测速地址可辅助排查。

作者原文 · 预览

测速地址已经可以改,不用等新版本:

  • 全局:设置 → 后端设置 →「测速地址」,填 https://www.gstatic.com/generate_204 或 https://cp.cloudflare.com/generate_204 都行,面板不会改写你填的协议;
  • 单个自动择优组:代理组编辑框里也有「测速地址」,只对这个组生效。

改完重启内核再测一次,把结果告诉我。

但有一点要纠正:那次 HEAD 请求不是 Cloudflare 处理的。测速是内核让节点服务器去访问 www.gstatic.com,Cloudflare 只负责你到节点之间那段 WS + TLS 隧道,它看不到也碰不到 gstatic 那个请求。所以 EOF 更可能是:① VMess 握手参数对不上(alterId / 加密方式 / ws path、Host),服务端直接关连接;② 你的服务器不允许出站到 80 端口。换成 https 测速地址能顺带排掉 ②。

另外第一次要的东西还是缺:一条脱敏的节点链接(uuid、域名打码,但要保留 aid、scy、net、path、host、tls、sni 这些字段)。小火箭能用而这里不行,十有八九差别就在这几个字段上,没有它我只能猜。

查看完整动态

liandu2024:Open-Box 多个 DNS 上游会并发查询并采用最快结果

liandu2024 在 Open-Box #151 中说明,单个代理 DNS 上游经节点卡住时只能等待客户端超时;Open-Box v0.1.230 起允许直连侧和代理侧各配置最多四个上游,并使用 sing-box 1.14 的 evaluate + race 并发查询,采用最先返回的结果。对于直连 UDP 上游自身的偶发丢包,也可增加备用上游或改用 TCP。

作者原文 · 预览

你这组对照已经说明问题了:同样是 TCP/53,换成 8.8.8.8 之后 180 多次查询 0 超时 —— 不是内核的 DNS 模块有毛病,是代理 DNS 上游只有一个,它经节点卡住时只能干等到客户端超时。

v0.1.230 起改掉了这个限制:DNS 上游可以配多个,并发查询,谁先返回结果就用谁的。

  • 位置:设置 → DNS 设置 →「DNS 上游」,右上角加号添加,选这条用在兜底直连还是代理;
  • 同一侧的第一条是主上游,后面的是备用,一起并发查 —— 一个上游卡住,另一个正常就照常出结果;
  • 每侧最多 4 个;没加备用上游时生成的配置和以前一字不差。

用的是 sing-box 1.14 自带的并发机制(evaluate + race),不是我们在外面轮询。

你第 3 点里那次 apple.com 超时走的是直连上游 223.5.5.5 的 UDP,和代理 DNS 不是一条路;你自己直查 223.5.5.5 也复现了 1/20,那是上游 UDP 偶发丢包 —— 现在直连侧同样可以加备用上游,或者把直连 DNS 的协议改成 TCP。

升上去配两个上游再用几天,没再复现的话我就关掉这条。

查看完整动态

liandu2024:Open-Box 修复 GL.iNet 断网保护与 TUN 标记冲突

liandu2024 在 Open-Box #157 中说明,sing-box 为跳过 TUN 设置的 0x2024 标记仍会继续匹配 GL.iNet 的 VPN 断网保护黑洞规则,导致内核自身的直连和代理连接全部报 no route to host。临时可关闭 VPN 策略路由或断网保护;Open-Box v0.1.230 起会在更高优先级让该标记查询主路由表,并在停内核时撤销规则。

作者原文 · 预览

找到原因了,你贴的 ip rule 就是答案:

9000: from all fwmark 0x2024 goto 9002     ← sing-box 装的"跳过 tun"
9002: from all nop
9910: not from all fwmark 0/0xf000 blackhole   ← GL.iNet 的 VPN 断网保护
9920: from all iif br-lan blackhole

内核自己发出去的流量会打上 0x2024 这个标记,好让策略路由跳过 tun。但 sing-box 装的那条是 goto 一个空规则(9002 nop),查找不终止 —— 接着就撞上你固件的 9910:0x2024 & 0xf000 = 0x2000 ≠ 0,正好命中,整包丢弃。所以日志里直连和代理全部 connect: no route to host,连国内 IP 直连都不通。

两个办法:

1. 立刻能用:在 GL.iNet 后台关掉 VPN 策略路由 / 断网保护(Kill Switch),9910、9920 这两条就没了。临时验证可以直接:

ip rule del pref 9910

(重启会回来。)

2. 升级到 v0.1.230 及以上:我们在内核启动时补了一条优先级更高的规则,让带这个标记的流量查到主路由表为止,到不了后面的黑洞:

8999: from all fwmark 0x2024 lookup main

停内核时会自己撤掉,普通固件上行为不变。

升级后如果还不通,把新的 ip rule 和 logread -e sing-box | tail -n 40 贴上来。

查看完整动态

liandu2024:Open-Box 以 TUN 与 auto_redirect 接管终端流量

liandu2024 在 Open-Box #192 中说明,Open-Box 以内核 TUN 配合 auto_redirect 接管流量;auto_redirect 在 nft 中使用 TCP redirect 与 UDP TPROXY,终端 TCP 连接会在进入路由器转发前被重定向进内核,因此终端无需另设代理。若仍有流量未被接管,需要结合设备、应用、主路由或旁路由模式和目标域名规则结果排查。

作者原文 · 预览

Open-Box 的入口用的就是这一套:内核以 tun + auto_redirect 接管,auto_redirect 在 nft 里装的是 redirect(TCP)+ tproxy(UDP) 的重定向链,效果和你说的 "Redirect TCP" 是一回事 —— 终端的 TCP 连接在进路由器转发之前就被重定向进内核,不需要在终端上设代理。

所以这项不用另外加。如果你遇到的是某类流量没被接管(某些设备、某些端口),那是另一个问题,麻烦说清楚:

  • 什么设备 / 什么应用没走代理;
  • 路由器是主路由还是旁路由;
  • 「规则」页查那个目标域名的结果。

这样能具体看是哪一层没接住。

查看完整动态

liandu2024:Open-Box 虚拟终端在 ESXi 下需放行 MAC 更改与伪传输

liandu2024 在 Open-Box #207 中说明,模拟终端测试会以 veth 和独立网络命名空间模拟新终端;ESXi 端口组需要允许“MAC 地址更改”和“伪传输”,混杂模式并非必需。其同时表示 Open-Box 不会修改 bridge-nf-call-iptables;该值为 1 时,桥内二层流量也会进入 netfilter,在旁路由同网段场景被重定向链处理,建议保持为 0,或将受影响设备设为“不进内核”。

作者原文 · 预览

分开说这两件事。

1. 虚拟终端在 ESXi 下建不起来

这个是 ESXi 的安全策略挡的,不是 bug。「规则」页的模拟终端测试会建一对 veth(obprobe0 挂进 br-lan,obprobe1 放进独立网络命名空间),给它一个自己的 MAC,然后在里面跑 udhcpc 去问主路由要地址 —— 相当于临时插了一台新终端。

ESXi 的 vSwitch / 端口组默认:

  • MAC 地址更改:拒绝
  • 伪传输(Forged transmits):拒绝

这两项任一为"拒绝",虚拟机发出来的、源 MAC 不等于网卡自身 MAC 的帧都会被 vSwitch 丢掉 —— obprobe0 的 DHCP 请求正好就是这种帧,所以必然 udhcpc: no lease。要跑这个测试,需要在对应端口组上把 MAC 地址更改 和 伪传输 改成"接受"(混杂模式不是必需的,我们不抓包)。

这只影响「规则」页的这一个测试功能,不影响正常分流和代理。

2. bridge-nf-call-iptables=1 时同网段间歇断网

Open-Box 不会动这个 sysctl(代码里没有任何地方设置它),所以这是固件默认或别的软件打开的。

它打开之后,桥内的二层转发流量也会走一遍 netfilter,于是同网段设备之间本不该进内核的流量也会被内核的重定向链看到 —— 旁路由 + 同网段的场景下这正是断网的来源。建议保持 0:

sysctl -w net.bridge.bridge-nf-call-iptables=0

如果因为别的组件必须打开它,可以在「终端分流」里把受影响的设备设成「不进内核」,那些设备的流量会在进内核前就被放行。

麻烦你按第 1 条放开端口组策略再试一次虚拟终端,第 2 条确认一下 sysctl 关掉后断网是否消失,结果贴出来我再跟进。

查看完整动态