科学之家

动态 · 第 3 页

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

动态时间线

按原始发布时间排序

liandu2024:Open-Box 安装与升级会检查 kmod-nft-queue

liandu2024 在 Open-Box #201 中说明,安装和升级脚本会在 apk 或 opkg 环境检查并补齐 kmod-nft-queue,安装失败时只警告而不中断;该模块用于 sing-box auto_redirect 的 nft queue 表达式。若固件不允许安装额外内核模块,需要改用包含该模块的固件。

作者原文 · 预览

安装和升级脚本本身会检查并补齐这个依赖(apk 和 opkg 都支持),装不上时只警告、不中断安装。手动装也可以:

apk add kmod-nft-queue || opkg install kmod-nft-queue

kmod-nft-queue 是 sing-box 的 auto_redirect 用到的 nft queue 表达式需要的。如果固件本身不让装额外内核模块(部分官方固件是这样),那就像楼上说的换一个带这个模块的固件。

先关掉,装完还有问题请重开。

查看完整动态

SlothClash:Linux 版暂不接入特权服务,TUN 仍待后续接线

作者说明当前 Linux 构建直接在进程内运行 mihomo,安装的 helper 不会被使用;0.9.3 先明确支持系统代理,pkexec、Unix socket 和 systemd 状态接线及真实发行版测试仍属后续变更。

作者原文 · 预览

Thanks for the precise report, and sorry for the confusing behaviour.

This is not Wayland-specific. Two things were going on:

The Linux build currently runs the mihomo core in-process and does not talk to the privileged helper service at all. So TUN mode has no root path on Linux yet, and a successfully installed service would not have been used anyway.
"Install service" launched the installer without elevation. The password prompt you saw came from systemctl (polkit), after which the copy into /usr/local/lib/sloth-clash failed with a permission error that never made it to the UI.
0.9.3 replaces the dead button with an honest message: the helper is not wired on Linux yet, and Proxy mode (system proxy) is the supported path for now.

Proper privileged TUN on Linux (pkexec-elevated install, unix-socket IPC like on macOS, systemd status) is scheduled as its own change. The service side is already Linux-ready; the desktop side needs the wiring plus testing on a real distro. I'll keep this issue open to track it and will ping here when there is a build to try. If you are up for testing an early build on Garuda/Sway when it's ready, that would help a lot.

查看完整动态

ClashBar 作者:mihomo 当前不能通过接口修改 DNS 配置

Sitoi 引用 mihomo 源码说明 ClashBar 不会改写用户配置;建议向 mihomo 提交支持请求,或手动将订阅转换为 proxy-providers。

作者原文 · 预览

https://github.com/MetaCubeX/mihomo/blob/Alpha/hub/route/configs.go

mihomo 源码中确实无法修改 DNS 配置,clashbar 不会考虑修改用户配置文件。

  1. 你可以尝试向 mihomo 提交 issue,让他们支持
  2. 你可以自己编写配置文件,将订阅转换成 proxy-providers,参考配置文件 https://github.com/Sitoi/ClashBar/blob/main/Sources/ClashBar/Resources/ConfigTemplates/ClashBar.yaml ,可以让ai 帮你修改
查看完整动态

liandu2024:Open-Box v0.1.223 修复 FakeIP UDP 缓存竞态导致的崩溃

作者说明补丁统一 ReadPacket 的原子占用逻辑,并报告竞态检测与回归用例结果;v0.1.223 会连同 1.14.1-openbox-tcp8 内核下载,仍建议继续观察。

作者原文 · 预览

你这份栈直接把问题指出来了,已定位并修好,v0.1.223 发出去了,内核版本 1.14.1-openbox-tcp8。

是什么

问题在依赖库 github.com/sagernet/sing v0.9.4 的 CachedPacketConn:同一个 UDP 缓存包有两条"取走"的路,却用了两套不同的同步——

  • ReadCachedPacket() 用原子标志 taken.CompareAndSwap
  • ReadPacket() 只是裸检查 if c.buffer != nil

并发时 ReadPacket 检查完、还没来得及 DecRef,缓存就被另一边置成 nil 了,于是 refs.Add(-1) 打在空指针上——正是你栈里的

sync/atomic.(*Int32).Add
buf.(*Buffer).DecRef                    buffer.go:297
bufio.(*CachedPacketConn).ReadPacket    cache.go:187

addr=0x30 正好是 Buffer.refs 的偏移。你那次 slice bounds out of range [:1232] with capacity 0 是同一个竞态的另一面:读到了已经 Release 回收的内存。

你的栈里有 route.(*fakeIPNATPacketConn).ReadPacket,说明你开着 FakeIP,走 FakeIP 的 UDP 流量最容易撞上这条路径(不开 FakeIP 也有机会,只是概率低)。

反过来还有一份:ReadPacket 先取走时不会置 taken,随后的 ReadCachedPacket 仍会赢下 CAS,把一个 Buffer 已经是 nil 的包交给调用方——那是另一个空指针入口。

怎么修的

让 ReadPacket 也走同一个 taken 原子标志,谁抢到谁处理。

上游 main 分支我今天核对过,至今仍是裸检查,所以这个补丁是 Open-Box 自己打的(也是我们第一个改依赖库而不是 sing-box 本体的补丁)。验证:

  • Go 竞态检测器:打补丁前稳定报 DATA RACE(读 cache.go:182 / 写 cache.go:200),补丁后干净;
  • 三条回归用例进了内核构建,两个架构都跑;
  • 反向验证:拿未打补丁的库跑,用例当场失败并打印出那个 Buffer:<nil> 的包。

你需要做的

面板里点升级到 v0.1.223。这一版会连内核一起下载(约 16 MB),不像前几版只下面板;升级过程中内核重启一次。

升完请留意一两天。如果还崩,麻烦再贴一次 logread -e sing-box | tail -n 80 —— 那就是另一条路径,我接着查。感谢你把完整栈贴出来,没有这个定位不到。

查看完整动态

Open-Box v0.1.222 新增恢复出厂与恢复默认分流入口

liandu2024 说明后端设置可执行不可撤销的恢复出厂,目标分流页也可单独恢复默认规则;两项操作的影响范围不同,升级后即可使用。

作者原文 · 预览

v0.1.222 已经加上了,而且是两个入口:

后端设置 → 恢复出厂设置(启停按钮那一行,分隔线后面那个红色按钮)
完全回到刚装好的样子:订阅、出站节点、目标分流、终端分流、链式代理、共享网络、面板外观设置、背景图、面板密码、流量统计与延迟历史全部清空,再按安装包自带的默认重新初始化;内核会停止运行。恢复后打开面板会像第一次那样让你重新设置密码。不可撤销,点之前有确认框。

目标分流页右上角 → 恢复默认分流(加号左边那个回退图标)
只把目标分流恢复成安装包自带的那套(Speed / AI / Youtube …… 共 12 条),订阅、节点这些一概不动。想重配分流但不想全清的话用这个。

面板里点升级即可。

查看完整动态

Leadaxe 计划为 Xray XHTTP 参数补充 sessionID 别名映射

sing-box-lx 当前只识别 sing-box 命名;LxBox 计划先用 contract_draft 覆盖 Xray 的 sessionIDPlacement/sessionIDKey,待别名同步后移除。

作者原文 · 预览

Живые vless+xhttp ссылки несут в extra proto-имена Xray, а реестр читает только sing-box написание.

Что теряется

В extra (URL-encoded JSON) Xray пишет:

{
  "sessionIDPlacement": "cookie",
  "sessionIDKey": "stream_auth",
  "seqPlacement": "cookie",
  "seqKey": "part_index"
}

Запись sessionPlacement смотрит только:

  • extra.sessionPlacement / extra.session_placement
  • query.sessionPlacement / query.session_placement

sessionIDPlacement / sessionIDKey ни extra, ни query не читает. seqPlacement доезжает (имя совпадает с каноном). Session id уходит в дефолт ядра path, хотя сервер ждал cookie с кастомным ключом.

Ядро sing-box-lx это уже документирует (option/v2ray_xhttp.go): proto — sessionIDPlacement, JSON — session_placement. PARAM_MAP 002 то же: Config.SessionIDPlacement / SessionIDKey.

Значения не дефолт дампа: дефолт placement — path, дефолт ключа для cookie — x_session. cookie + stream_auth — настройка сервера.

Что просим

В source записей sessionPlacement и sessionKey (URI extra/query и Xray-JSON extra) добавить:

  • sessionIDPlacement → transport.session_placement
  • sessionIDKey → transport.session_key

Канон extra по-прежнему первый. sessionIDLength / sessionIDTable не трогать: "0" без таблицы — «не задано»; протащить без пары — ошибка ядра «must be set together».

Пустые host/path/mode из extra не трогать (D-097).

LxBox

До синка зеркала повесим оверлей contract_draft на те же две записи. Снимем, когда алиасы будут в реестре.


@Cursor (сессия LxBox)

查看完整动态

Fangliding 提醒 GUI 客户端写入的未知字段可能受损

在 Xray 配置字段校验讨论中,他表示多数软件会忽略未知字段,而 GUI 客户端可能把管理数据写入 JSON,修改这些字段可能损坏客户端。

作者原文 · 预览

大多数软件来说好像都会忽略配置文件中的未知字段
有的GUI Client会往json中塞入他们自己的数据进行节点管理什么的 改了会损坏这些Client

查看完整动态

OwnBox 已上线 Windows 测试版

OwnBoxs 频道说明 OwnBox 已上线 Windows,当前仅视为测试,部分功能待完善;项目仓库为 Own716/OwnBoxForWin,建议和 bug 可在 GitHub issue 反馈。

频道原文 · 预览

OwnBox 已上线 Windows

https://github.com/Own716/OwnBoxForWin

目前仅是测试,有些功能还是挺好玩的,也有部分有待完善。

可能效果与市面上的那些相差太远,请谅解。

有任何功能建议、想法,或者 bug,可以在 GitHub 上提 issue(议题)。提的东西 90% 概率会实现。嘿嘿嘿😝

查看完整动态

liandu2024:Open-Box v0.1.213 可为订阅节点指定 DoH 解析

liandu2024 在 Open-Box #136 中说明,v0.1.213 在订阅编辑框加入「节点域名解析」:左侧填写机场提供的 DoH 地址,DoH 主机名为域名时右侧填写用于解析它的 DNS;保存后重启内核,只影响该订阅节点服务器域名、订阅测速和链式代理测速,诊断包会抹掉 DoH 主机名与路径。自动从订阅带出 DoH 暂未实现。

作者原文 · 预览

v0.1.213 加上了:订阅编辑框里的「节点域名解析」。

  • 左边填机场给的 DoH 地址,可以带端口和私有路径,如 https://dns.example.net:2096/<私有路径>;
  • DoH 地址是域名时,右边填一个解析它用的 DNS(IP,UDP 53),如 223.5.5.5。

保存后重启内核生效。它只用来解析这份订阅的节点服务器域名(这份订阅的节点出站带上 domain_resolver),普通网站和局域网 DNS 不受影响;订阅编辑框里的测速、以这些节点当上游的链式代理测速也按它解析。诊断包里会把 DoH 的主机名和路径抹掉。

「从订阅里自动带出 DoH(nameserver-policy / proxy-server-nameserver)」暂时没做,先手动填。

查看完整动态

liandu2024:Open-Box v0.1.213 新增终端分流白名单

liandu2024 在 Open-Box #187 中说明,v0.1.213 的「设置 → 终端分流」可按 IP 或 MAC 选择终端,并把处理方式设为「只让这些终端进内核」;有这类规则时局域网只有列出的终端进入内核,其余终端和未安装 Open-Box 一样,DNS 也不经内核。按 MAC 最稳;按 IP 依赖防火墙标记,IPv6 需另列;需要 auto_redirect,纯 TUN 兼容模式下白名单不生效。

作者原文 · 预览

v0.1.213 终端分流新增「只让这些终端进内核(白名单)」,终端可以按 IP 或按 MAC 填(编辑框里两个页签二选一)。

用法:「设置 → 终端分流」新建一条规则,选好终端,处理方式选「只让这些终端进内核」,保存后重启内核。有这类规则时,局域网里只有列出来的终端进内核,其余终端和没装 Open-Box 一样(DNS 也不经内核)。

几点说明:

  • 按 MAC 最稳,IP 变了也认得出;
  • 按 IP 时靠防火墙打标记实现,名单外的终端不走 mwan3 多 WAN 分流;终端有 IPv6 的,v6 地址要另外列;
  • 需要 auto_redirect(默认就是开的),纯 tun 兼容模式下白名单不生效。
查看完整动态

dyhkwong:Exclave 已移除普通插件支持,NaiveProxy 适用保留例外

dyhkwong 在 Exclave #485 中说明,Exclave 已移除非 SIP003 的插件支持;NaiveProxy 适用 grandfather clause(保留例外)。除非新协议足够好且无法用 Go 实现,他认为不会再新增插件。

作者原文 · 预览

Plugin (not SIP003 plugin) support has been removed. NaiveProxy is applicable to the grandfather clause. Unless a new protocol is good enough like NaiveProxy and can't be written in Go, I don't think there will be any new plugins.

查看完整动态

liandu2024:反向代理 Open-Box 概览实时数据需转发 WebSocket

liandu2024 在 Open-Box #175 中说明,概览连接数、内存、流量与连接等实时数据使用 /api/controller-ws/… WebSocket,其他页面使用普通 HTTP;自定义域名反向代理若未转发 WebSocket Upgrade 头,就会只缺少这些实时数据。nginx 需要使用 HTTP/1.1 并转发 Upgrade、Connection 与 Host,Lucky、NPM 等工具需开启 WebSocket 支持。

作者原文 · 预览

概览的实时数据(左下角的连接数和内存、概览页的流量和连接)走的是 WebSocket(路径 /api/controller-ws/…),其他页面是普通 HTTP 请求。反向代理没转发 WebSocket 的升级头时,就正好只有这几处是空的。

以 nginx 为例,要加上这几行:

location / {
    proxy_pass http://<路由器IP>:2026;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Lucky、NPM 这类工具一般是在反代规则里勾上「WebSocket 支持」。

查看完整动态

Husi 作者希望全局搜索包含节点与代理组两种模式

xchacha20-poly1305 在 husi #954 中回复 PR:希望该功能更接近 zashboard,提供全局搜索栏,并区分「节点搜索」(只保留匹配节点并隐藏没有匹配的代理组)和「代理组搜索」(过滤匹配关键字的代理组);他还希望保留针对单个代理组的搜索,并移除当前的 8 项限制。

作者原文 · 预览

Thank you for your pull request! But I'd rather like this feature can more like zashboard:

  1. A global search bar with two mode
  • Node search: only keeps the matched node and hide the proxy set that have no matched.
  • Proxy set search: filter the proxy set that matches the search key word.
  1. Search for a special proxy set. This is want you have done currently. And I want to remove the 8 limitation.
查看完整动态

yiguodev:Xray Linux TUN DNS 接管仍有混合解析路径反例

yiguodev 在 Xray-core #6773 中说明,已用四组真实 Linux 场景复测确认无 DNS、空 DNS 和 gateway-source-IP 到 blackhole 等修复有效;但新增只对 example.com 使用 localhost 且 finalQuery/skipFallback 的上游后,接管会被接受而查询 4/4 超时。他认为应在可选解析路径可能依赖系统解析器时拒绝接管,并在 README 明确 source-port-independent DNS path 等限制。

作者原文 · 预览

Thanks for the three commits and the explicit clarification of their scope. I retested 71b70211daf9ebe25500f64d8f8634be32fd2c3d with four real Linux matrices, nine scenarios each. This follow-up focuses on functional behavior rather than style.

Confirmed fixes

  • No dns section, an empty DNS configuration, and the gateway-source-IP → blackhole case now correctly refuse takeover while system resolution remains usable.
  • The dirty-state fix works: real private-bus ACL denials cause another revert attempt at shutdown. After restoring the private policy, I captured successful Revert method-return replies, correlated by caller and serial—not merely the absence of an error log. With permission still denied, the retry receives an error and the per-link state disappears with the TUN on exit.

Please keep the small app/dns accessor; covering the empty-server case is justified. The real-router tests are also useful, CI-friendly regression coverage. They test decisions rather than DNS responses, but that does not negate their value.

New counterexample: mixed independent and system-resolver upstreams

Starting from the working independent-upstream configuration, add this DNS server:

{
  "address": "localhost",
  "domains": ["full:example.com"],
  "finalQuery": true,
  "skipFallback": true
}

The takeover is accepted, but example.com times out in 4/4 runs. Queries reach the DNS outbound, and logs show lookups returning to the private system stub and timing out. An unrelated domain resolves successfully before and after the failing query in the same instance.

UsesSystemResolver() returns false as soon as any upstream is non-local, whereas the domain-specific selection can still choose only localhost. This is an additional configuration case, not a claim that your no/empty-DNS fixes failed.

A conservative fix would refuse takeover when a selectable resolution path may depend on the system resolver, rather than checking whether all clients do. A MayUseSystemResolver-style check and a mixed-server regression case would make that distinction explicit; do not silently remove the user's local resolver.

Source ports: the limitation you already disclosed

I acknowledge your statement that the representative source port cannot predict the real query's port. The live consequence is reproducible: with source port 49152 → DNS and remaining TUN/53 traffic → blackhole, preflight accepts takeover; real queries from 49152 answer, while 49153 and the system resolver's actual ephemeral ports fail, in all four runs.

Could the README explicitly require a source-port-independent DNS path and clarify whether unsupported configurations should be refused? We should avoid presenting the synthetic check as a guarantee for arbitrary routing rules. I am not asking for a general Router redesign in this PR.

Scope and evidence limits

Deferring godbus is fine. Fixture duplication and missing full TUN E2E coverage are not additional observed functional failures. The remaining .Base(err).Base(cause) overwrite is a diagnostic improvement, not evidence that cleanup is skipped.

The real TUN/gVisor, DNS and resolvectl path ran inside private mount/PID namespaces with a private bus/resolved. This does not establish normal-host authorization or general leak coverage. Four seconds is the client's timeout limit.

One supplementary rollback-recovery run also had a DNS timeout before policy restoration; Revert succeeded and the next identical run answered normally. That failure is retained and unexplained—not attributed to rollback or dismissed as proven network noise.

All 36 Core instances exited 0, their TUNs disappeared automatically, and all four host-preservation audits passed.

查看完整动态

RPRX 在 GitHub 的公开发言

作者原文 · 预览

@Risaro 0xe5554cceca6db722bebc4028b466d20e33d63029534ecb5875218943742cca90

我觉得最可贵的是能实时测试 Google Drive 等 backend 并改进 XDRIVE 的代码,是否 vibe 的倒不重要,可能明年全靠 AI 都行

目前比较需要一份 Google Drive API 配置教程,半年前我和 @iambabyninja 通过邮箱讨论过,但不确定是否适用于这个 PR

查看完整动态

HyNetworks 重新公开 OpenGFW,并说明后续维护计划

HyNetworks 团队表示,经过内部讨论和社区请求,已重新公开 OpenGFW 仓库;目前暂无大幅更新计划,后续将把更多精力投入 Hysteria 和其他反审查项目,同时保持仓库公开、接受 PR 并按需要发布新版。

作者原文 · 预览

Earlier this year, we removed the OpenGFW repository from GitHub. This decision was made primarily because we discovered that Geedge Networks, a company with close ties to the Chinese government that sells censorship solutions to governments around the world, was plagiarizing OpenGFW's code and incorporating it into its products.

OpenGFW was created for purposes such as network research, ad blocking, and parental controls. It was never intended to enable or assist state censorship. Seeing the project used in this way was fundamentally at odds with why we built and released it.

After further internal discussion and requests from the community, we have decided to make the repository publicly available again for the benefit of the broader community.

For now, we do not plan to actively continue developing OpenGFW ourselves. Instead, we intend to focus more of our efforts on Hysteria and other upcoming anti-censorship projects. However, if members of the community would like to continue developing OpenGFW, they are more than welcome to do so. We will keep the repository available, accept pull requests, and publish new releases as appropriate. Thank you to everyone in the community who has supported our projects and shared their feedback with us.

今年早些时候我们将 OpenGFW 的代码仓库从 GitHub 上撤下。做出这一决定,主要是因为我们发现 Geedge Networks(积至海南信息技术有限公司) ——一家与中国政府关系密切、向世界各国政府出售网络审查方案的公司——抄袭了 OpenGFW 的代码,将其整合进自己的产品中。

OpenGFW 是为网络研究、广告拦截、家长控制等用途而开发的。我们不希望它被政府用于实施或协助实施网络审查。看到这个项目被用于这样的目的,与我们开发并开源它的初衷完全背道而驰。

经过进一步的内部讨论,同时考虑到社区成员的呼声,我们决定重新公开 OpenGFW 的代码仓库,让更广泛的社区能够继续受益于这个项目。

目前我们暂无大幅更新 OpenGFW 的计划。接下来我们希望将更多精力投入 Hysteria 以及其他即将推出的反审查项目。不过,如果社区成员愿意继续推动 OpenGFW 的开发,我们保持欢迎。我们会继续保持代码仓库公开,接受 PR,并在需要的时候发布新版。感谢大家一直以来对我们项目的支持,以及意见和反馈。

https://github.com/HyNetworks/OpenGFW

查看完整动态

@projectXtls 频道 在 Telegram 的公开发言

频道原文 · 预览

💬 New comment on Xray-core#6748 XDRIVE transport: Add the Google Drive backend by @RPRX 为了凑到第 2000 个 commit 以及给 Risaro 的生日补个礼物,我打算现在就分两步合并 XDRIVE 相关的 PR 进 main 代码仍需完善,比如上面我提到的 XMUX,以及 config 的“Google Drive”改为“google-drive”,以及检测配置:需开启 mux.cool ~~可能还需要一些…

查看完整动态

RPRX 在 GitHub 的公开发言

作者原文 · 预览

为了凑到第 2000 个 commit 以及给 Risaro 的生日补个礼物,我打算现在就分两步合并 XDRIVE 相关的 PR 进 main

代码仍需完善,比如上面我提到的 XMUX,以及 config 的“Google Drive”改为“google-drive”,以及检测配置:需开启 mux.cool

可能还需要一些 deVibe,好在代码一旦进入 main 就会开始接受更广泛的 PR,会有很多人来完善,就像 XHTTP 那样

还需配套的文档、Google Drive API 配置教程等,@Risaro 请发出你的 ETH 地址,我会给你转一个 Project X NFT 作为纪念

XDRIVE 将会是 Project X 2026 最具代表性的新协议,其次是 Finalmask、TUN,以及 FinalRules 等各种默认的安全改进

查看完整动态

wwqgtxx 在 GitHub 的公开发言

我很好奇,为什么你不推动 utls 本身的发展,反而要向一个只是使用其库的下游项目施压。显然,utls 是 Go 生态中非常实用的基础库,但目前没有得到足够的支持。既然你有这么多需求,为什么不直接为 utls 做贡献? 这种情况与过去的 OpenSSL 十分相似:大量下游项目依赖这个库,却没有任何公司想到要资助它的开发。如果你认为 utls 的开发已经停滞,为什么不联系主要维护者,看看他们是否人手不足? 我们也对 Xray 团队推出的任何新东西不感兴趣。鉴于他们对其他项目极其敌对的态度,我们不会再浪费时间迁就他们那些古怪的想法,包括但不限于他们打算使用 AI 拼凑出一个所谓的、完全没有经过安全审计的“指纹库”。 归根结底,如果你认为他们的想法和做法是正确的,我们建议你干脆只使用 Xray 作为唯一的软件解决方案。

作者原文 · 预览

I am curious why you aren't pushing for the development of utls itself, rather than pressuring a downstream project that merely utilizes its library. Clearly, utls is a highly practical foundational library within the Go ecosystem, yet it lacks sufficient support. Given the volume of requests you have, why not directly contribute to utls?

This situation is strikingly similar to the state of OpenSSL in the past: a vast number of downstream projects relied on the library, yet no company thought to sponsor its development. If you feel that utls development has stalled, why not contact the primary maintainers to see if they are short-staffed?

We also have no interest in whatever new things the Xray team has come up with. Due to their extremely hostile attitude toward other projects, we will no longer waste time accommodating their eccentric ideas—including, but not limited to, their plan to use AI to cobble together a so-called "fingerprint library" that lacks any security auditing.

Ultimately, if you believe their ideas and methods are correct, we suggest you simply use Xray as your sole software solution.

查看完整动态

@clashbyhako 频道 在 Telegram 的公开发言

频道原文 · 预览

全网首发:Clash 成为首个搭载 mihomo 1.19.31 内核的 Apple 客户端。

最新内核 + 全新 MIPS 网络栈,硬生生塞进了 Apple Network Extension 苛刻的内存墙。
iPhone / iPad / Mac / Apple TV,全平台同内核,同一天上架。

别人还在等,我们已经在 App Store 了。
立即安装 → https://apps.apple.com/app/id6794257189
发行版本:iOS 1.0.9 / tvOS 1.0.12 / macOS 1.0.12

本次重点:

  • 四端同源:mihomo 1.19.31,上游发什么,你就用什么
  • MIPS 栈首次登陆 Apple:iOS / tvOS 配置TUN.STACK改为MIPS 即可体验
  • 体积砍半:iOS 173MB → 78MB (−55%),macOS 298MB → 176MB (−41%)
  • 切网无感:Wi‑Fi ↔️ 蜂窝、换网段,隧道不掉,网络保持畅通
  • macOS:新增 EasyTier 出口节点,标签样式下可直接取消固定
  • Apple TV:配置定时自动更新(到期打开即拉取)+ 每次更新自动运行脚本

💬 MIPS 栈和无感切网在你的主力机上表现如何?升级后欢迎在电报群里晒出内存占用与稳定性反馈,并说说你最想要的下一个功能。

电报交流 → https://t.me/+eCUP-ohH8xMwMzll

查看完整动态

Leadaxe:LxBox 可通过自定义抓取身份导入 Happ 返回的 Xray JSON 节点

Leadaxe 在 LxBox 议题中说明,Happ 配置里的 VLESS + REALITY + Vision 节点本身不是内核限制,差异来自订阅面板按请求头返回不同节点;LxBox 可在订阅或全局设置中自定义 User-Agent 和 HWID,随后解析 Xray JSON 中的 proxy、member、balancer 与 burstObservatory,但不导入 Xray 路由规则和 DNS。

作者原文 · 预览

Hi! This is most likely not a core limitation. Both outbounds in the Happ config are plain vless + REALITY + vision, sing-box handles those fine. What differs is the servers themselves: note the different shortIds (0c / 1f vs 26a8). Your provider simply hands out a different set of nodes depending on which client asks.

The panel decides that by the request headers, and you can change both in LxBox:

  • per subscription: open the subscription → settings → Fetch identity → enable Custom identity. There you get Custom User-Agent and Send HWID (x-hwid, plus x-device-os, x-ver-os, x-device-model, all editable);
  • globally for all subscriptions: app Settings → Subscriptions, same fields.

So set the User-Agent to what Happ sends (and turn on Send HWID if the panel has device limits), update the subscription, and you get the Happ version of it, which LxBox can use as is. It parses Xray JSON configs: proxy and member become nodes, and the balancer comes along too. routing.balancers + burstObservatory turn into an auto-select node named after remarks (your roundRobin becomes a round-robin pool over both servers, with the ping URL and interval taken from pingConfig). Only the Xray routing rules and DNS are not imported, LxBox has its own routing for that.

Please tell me what you get after that: do the nodes appear, and do they pass the whitelist?

查看完整动态

clashbyhako:TestFlight 申请通道已全面恢复

频道原文 · 预览

📢 【公告】TestFlight 申请通道已全面恢复
Clash 的 TestFlight 内测申请现已完全恢复正常,需要安装或更新的朋友可直接在群内唤起机器人申请!
🔗 电报交流群: https://t.me/+eCUP-ohH8xMwMzll
申请流程与常用指令:

  • /start@clash_group_bot:发起内测申请(按提示输入并提交 Apple ID 邮箱)
  • /status@clash_group_bot:查看当前申请进度与审核状态
  • /cancel@clash_group_bot:提交前重填或修改邮箱

💡 温馨提示:

  1. 提交成功后请留意查收来自 Apple TestFlight 的邮件通知。
  2. 多端通用:iOS / tvOS / macOS 只要登录同一个 Apple ID 账户即可同步使用,无需重复申请。
查看完整动态

@OwnBoxs 频道 在 Telegram 的公开发言

频道原文 · 预览

OwnBox v2.8.0 正式版

https://github.com/Own716/OwnBoxForAndroid/releases/tag/v2.8.0

增加新功能
• 全部分组聚合
• 节点列表延迟显示与即时排序
• 搜索多格式导出(剪贴板 / 配置文件)
• 搜索结果分享为二维码
• 免 Root 局域网共享独立面板
• 负载均衡前置代理与落地代理
• 负载均衡正则表达式规则过滤
• 物理触觉震动反馈
• 通知栏快捷重置连接

修复和优化
• 性能优先模式与后台省电深度优化
• sing-box v1.15.0 内核与 Sing-Tun 原生网络栈
• Wi-Fi 与移动网络无缝平滑切换
• 搜索输入法候选词与键盘响应体验
• 落地 IP 探测与即时刷新
• 界面主题色彩与层级精简

查看完整动态

yiguodev:OneXray UWP 版已采用新的 Windows TUN 方案

yiguodev 在 Xray-core 的 Windows TUN 讨论中说,UWP 方案确实有效,已经应用到 OneXray 的 UWP 版本;但发布较费劲,需要自签名或上架 Windows Store。

作者原文 · 预览

UWP 这个方案吧,确实有效,已经应用到 OneXray 的 UWP 版本里了。不过就是发布费劲,要么自签名,要么就得发布到 Windows Store 。感觉 wintun 这个方案就是个绝路,给 DNS 打补丁也不一定有效。

查看完整动态

kazeyukiro:3m-ui 创建 VLESS 时报缺少 username 的问题已修复

在修复说明中表示,原因是创建 VLESS 时自动填充只生成 users[].uuid(与 Mihomo 官方一致),但校验强制要求 username,于是报 vless listener users[0] requires username。改动有三点:VLESS/VMess 的 uuid 模式校验只要求 uuid、username 改为可选;自动填充缺省时补 username: "user";已有只填 uuid 的记录也会回填 username。更新到包含该提交的构建后即可正常新建 VLESS 节点。

作者原文 · 预览

已修复(main)

原因: 创建 VLESS 时 autofill 只生成 users[].uuid(与 Mihomo 官方一致),但校验强制要求 username,导致报错:

vless listener users[0] requires username

改动:

  1. VLESS/VMess 的 uuid 模式校验:只要求 uuid,username 可选
  2. autofill:缺省时补 username: "user"
  3. 已有仅 uuid 的行也会回填 username

更新到包含此提交的构建后即可正常新建 VLESS 节点。

查看完整动态

liandu2024:Open-Box v0.1.206 新增屏蔽 QUIC 开关

liandu2024 在 Open-Box 议题中说明,v0.1.206 已加入「设置 → 后端设置 → 屏蔽 QUIC」且默认关闭;开启后代理线路的 UDP 443 会被拒绝,浏览器会回退到 TCP,直连站点和前置自定义端口分流不受影响,修改后需重启内核生效。

作者原文 · 预览

v0.1.206 已加:「设置 → 后端设置 → 屏蔽 QUIC」,默认关。

打开后,走代理线路的 QUIC(UDP 443)会被直接拒绝,浏览器自动退回 TCP;直连的站点不受影响,你在前置自定义分流里按端口写的规则也不受影响。改完重启内核生效。

查看完整动态

liandu2024:Open-Box 暂不计划支持自定义安装目录

liandu2024 在 Open-Box #82 中说明,自定义安装目录暂不计划做,因为 /opt/open-box 写在 init 脚本、LuCI 页面、升级脚本和防火墙 include 等多处,改成可配置风险较大;N1 等 /opt 空间小的设备可把大分区 bind mount 到 /opt/open-box,并写入 /etc/rc.local 后再运行安装脚本。

作者原文 · 预览

自定义安装目录暂不计划做:/opt/open-box 这个路径写在 init 脚本、LuCI 页面、升级脚本、防火墙 include 等很多地方,改成可配置风险比较大。

N1 这类 /opt 空间小的设备,可以试试把大分区 bind mount 到 /opt/open-box(安装脚本检测空间时看的就是这个目录所在的文件系统):

mkdir -p /mnt/mmcblk2p4/open-box /opt/open-box
mount --bind /mnt/mmcblk2p4/open-box /opt/open-box

再把这条 mount 写进 /etc/rc.local(放在 exit 0 之前)让它开机自动挂载,然后运行安装脚本。

先关闭。

查看完整动态

liandu2024:Open-Box v0.1.203 已上线链式代理

liandu2024 在 Open-Box 议题中说明,链式代理已在 v0.1.203 上线,可在「设置 → 链式代理」添加 socks5/http/https 出口并指定前置节点或节点组;生成配置会检查上游是否存在和是否成环,链式节点可进入手动节点组、站点集与终端分流。导入 Clash 订阅时,订阅里的 dialer-proxy 关系仍需手动建立。

作者原文 · 预览

链式代理已在 v0.1.203 上线,对应你说的 detour 方案:「设置 → 链式代理」里添加出口(socks5 / http / https,链接或分字段填写),指定前置的节点或节点组;生成配置时会核对上游是否存在、是否成环。建好后它作为一个节点出现,可以进手动节点组、站点集、终端分流,代理页和域名穿透里会分层显示「前置 → 链式节点」。

目前还没做的一点:导入 Clash 订阅时,订阅里自带的 dialer-proxy 关系不会自动带过来,需要在「链式代理」里手动建。

请升级到最新版试用,有问题欢迎开新 issue。

查看完整动态

关于 huarun.win 在中国大陆访问异常的说明

近期 huarun.win 在中国大陆部分网络环境下出现无法直接访问(“被墙”)的情况,具体表现因地区及运营商而异。

本站目前运行正常,应用目录与历史资料仍在持续维护更新。

如遇无法访问,请尝试调整网络环境、DNS 或使用其他网络工具访问。

查看完整动态