动态 · 第 5 页

Max Lvshadowsocks-libev 与 shadowsocks-android 核心维护者，SIP 规范主导者，meow-rs 内核创立者

作者发言

GitHub·2026.09.12 15:24:32（UTC+8）

madeye：test_event 失败由 macOS 文件描述符上限引起

Thanks for the report. This is caused by macOS's default per-process file descriptor limit rather than a bug in the event loop. `test_event` deliberately opens 256 UDP sockets (to exceed Winsock's 64-descriptor `select()` limit) plus a sender socket and the loop's own kqueue descriptor. A stock macOS Terminal session starts with a soft limit of 256 (`ulimit -n` prints `256`), so `socket()` starts returning -1 near the end of that loop and the unchecked descriptor trips the `bind()` assertion you saw. Running with a higher limit already makes the test pass on 3.3.6: ```sh ulimit -n 1024 ctest --test-dir build -L 'unit|vendor' --output-on-failure ``` （节选）

作者原文 · 预览@madeye

Thanks for the report. This is caused by macOS's default per-process file descriptor limit rather than a bug in the event loop.

test_event deliberately opens 256 UDP sockets (to exceed Winsock's 64-descriptor select() limit) plus a sender socket and the loop's own kqueue descriptor. A stock macOS Terminal session starts with a soft limit of 256 (ulimit -n prints 256), so socket() starts returning -1 near the end of that loop and the unchecked descriptor trips the bind() assertion you saw. Running with a higher limit already makes the test pass on 3.3.6:

ulimit -n 1024
ctest --test-dir build -L 'unit|vendor' --output-on-failure

https://github.com/shadowsocks/shadowsocks-c/pull/3060 fixes this properly: CTest now raises the soft limit to 1024 before launching each unit test, test_event raises its own limit when run directly, and a socket() failure is now reported as such instead of as a bind() failure.

查看完整动态

Ryan YanSatelite 架构师

作者发言

GitHub·2026.09.12 10:11:22（UTC+8）

zn0wii：手动点击节点后应自动变成手动模式

作者原文 · 预览@zn0wii

这里的设计其实就是为了 手动点了节点,就应该自动变成手动模式. 要不然就是感觉我都点了某个节点,怎么一会又变了的感觉. 还有就是内核自动以及目前智能模式都不够 智能,当节点大范围出现问题时,自动/智能 切换的效果都不太即时.还需要优化.

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.11 20:39:10（UTC+8）

TokenPLS：iOS 1.0.6 去掉 500KB 配置上限，正在审核中

作者原文 · 预览@TokenPLS

iOS 1.0.6 起去掉了客户端这边 500KB 的配置大小上限，大配置交给内核处理；1.0.6 正在审核中。

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.11 20:39:06（UTC+8）

TokenPLS：下个版本增加“排除 APNs 路由”开关

作者原文 · 预览@TokenPLS

下个版本在「更多 → 隧道」加一个「排除 APNs 路由」开关：打开后 Apple 推送流量不走隧道，直接从物理网络出去。默认关闭。

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.11 20:39:05（UTC+8）

TokenPLS：proxy-providers 文件导入问题已修，下个版本发布

作者原文 · 预览@TokenPLS

确认是 bug，已修。原因：从「文件」打开配置只能选一个文件，而配置里的 proxy-providers 是 type: file，导入时要求把引用的文件一起选上，满足不了就失败，而且没有任何提示。

修复后：配置正常导入，缺的 provider 文件在该配置的「资源」页补上；导入失败也会弹提示。下个版本发布。

当前版本绕法：把 provider 文件里的节点直接写进主配置的 proxies 再导入。

查看完整动态

yiguodevOneXray 开发者

作者发言

GitHub·2026.09.11 19:54:40（UTC+8）

yiguodev：Linux 内核进程校验已在开发分支修复

Thanks for reporting. Fixed on `dev-26.9.2-5` in 32564a2 and 762f775. On Linux, file capabilities can make `/proc/<pid>/exe` unreadable, causing the old process checks to reject a Core that is actually running. Core management now uses exact `OneXrayCore` name matching via `pgrep`/`pkill`, preserves exit notifications, and confirms shutdown before reporting Disconnected. The slow per-process Dart `/proc` scans have also been removed. Verified on Linux ARM64 with the real app: connect/disconnect, reconnect, adoption after app restart, and automatic status updates when Core exits externally. （节选）

作者原文 · 预览@yiguodev

Thanks for reporting. Fixed on dev-26.9.2-5 in 32564a2 and 762f775.

On Linux, file capabilities can make /proc/<pid>/exe unreadable, causing the old process checks to reject a Core that is actually running. Core management now uses exact OneXrayCore name matching via pgrep/pkill, preserves exit notifications, and confirms shutdown before reporting Disconnected. The slow per-process Dart /proc scans have also been removed.

Verified on Linux ARM64 with the real app: connect/disconnect, reconnect, adoption after app restart, and automatic status updates when Core exits externally.

Closing as fixed in the development branch. Please retest with a build containing these commits and reopen if the problem persists.

查看完整动态

dyhkwongExclave 代码贡献者

作者发言

GitHub·2026.09.11 15:59:31（UTC+8）

dyhkwong：没有支持 finalmask 的计划，KCP 与 Hysteria 2 部分功能除外

作者原文 · 预览@dyhkwong

I explicitly made configurations with finalmask fails to import because there is no plan to support the huge mess of finalmask, and a configuration with finalmask enabled is imcompatible with the same configuration without finalmask enabled. Exceptions:

• For KCP (they moved part of KCP to finalmask).
• For Hysteria 2 obfuscation and port hopping.

查看完整动态

yiguodevOneXray 开发者

作者发言

GitHub·2026.09.11 14:53:49（UTC+8）

OneXray 作者说明 TUN DNS 与路由 DNS 的区别

yiguodev 表示，普通路由模式下，通常的 DNS 查询由 Xray 内置 DNS 处理，单独修改 TUN DNS 地址不会改变这些请求所用的解析器，需要修改路由配置里的 DNS 地址。他在这条回复中表示，下一版将允许在智能路由和自定义路由中修改本地／直连 DNS 地址。

作者原文 · 预览@yiguodev

Thank you for the report.

In normal routing mode, typical DNS lookups are handled by Xray's built-in DNS. Changing the TUN DNS address alone therefore does not change the resolver used for those requests; the relevant setting is the DNS address in the routing configuration.

The next release will allow you to customize the local/direct DNS address in both Smart Routing and Custom Routing. Closing this issue with this improvement scheduled for the next release.

查看完整动态

PharosVipPharos Pro 开发者与代理生态贡献者

作者发言

GitHub·2026.09.11 14:28:05（UTC+8）

PharosVip 回应 sing-tun 审查：将 ICMP 转发改为有界异步队列

针对 wwqgtxx 提出的阻塞风险与重复加锁问题，PharosVip 表示已将 PrepareConnection 和数据包转发移入有界异步队列，并移除外层 s.icmpMu 锁，后续将继续跨平台测试。这是 mipstack 适配 PR 中的修订进展，尚不代表正式合并或发布。

作者原文 · 预览@PharosVip

As a side note, I don't think the changes in the second commit are entirely sound. The forwardICMP section, in particular, appears to boost performance but introduces greater risk. In reality, the ICMPForwarderHandler should return as quickly as possible and avoid any blocking or long-running operations internally; clearly, PrepareConnection offers no guarantee against blocking.

Furthermore, I don't quite understand the addition of s.icmpMu there; DirectRouteMapping is already thread-safe, so what is the purpose of wrapping it in an external lock?

Thank you for pointing this out. I’ve moved PrepareConnection and packet forwarding to a bounded asynchronous queue.
I’ve also removed s.icmpMu. DirectRouteMapping uses its own synchronization, and the worker handles route cleanup when it exits.
I’ll spend some time conducting additional tests across platforms and share the results.

查看完整动态

Ryan YanSatelite 架构师

作者发言

GitHub·2026.09.11 11:18:15（UTC+8）

zn0wii：最新版本内置内核，增加镜像下载地址

作者原文 · 预览@zn0wii

最新版本支持读环境/系统代理来尝试下载，增加了镜像下载地址。也内置了内核。 智能切换目前还不够智能，除了会降级外，还会选到不好的节点。还需要优化

查看完整动态

wwqgtxxMihomo 核心贡献者与 GreatAgent (wwqgtxx-goagent) 开发者

作者发言

GitHub·2026.09.11 11:10:19（UTC+8）

wwqgtxx：forwardICMP 的改动存在阻塞风险

作者原文 · 预览@wwqgtxx

As a side note, I don't think the changes in the second commit are entirely sound. The forwardICMP section, in particular, appears to boost performance but introduces greater risk. In reality, the ICMPForwarderHandler should return as quickly as possible and avoid any blocking or long-running operations internally; clearly, PrepareConnection offers no guarantee against blocking.

Furthermore, I don't quite understand the addition of s.icmpMu there; DirectRouteMapping is already thread-safe, so what is the purpose of wrapping it in an external lock?

查看完整动态

xchacha20-poly1305Husi 核心作者

作者发言

GitHub·2026.09.11 08:25:52（UTC+8）

Husi 作者建议使用链式代理与代理集合

xchacha20-poly1305 在为分组增加前置代理和落地代理的功能请求下表示，这一功能会引入难以解释的行为，建议改用链式代理与代理集合。

作者原文 · 预览@xchacha20-poly1305

This feature introduce unexplanable behavior. Use Chain proxy + proxy set instead.

查看完整动态

wwqgtxxMihomo 核心贡献者与 GreatAgent (wwqgtxx-goagent) 开发者

作者发言

GitHub·2026.09.10 22:46:08（UTC+8）

wwqgtxx：不打算处理未发布 uTLS 版本的兼容问题

作者原文 · 预览@wwqgtxx

We have no interest in wasting time dealing with such compatibility issues, nor do we wish to expend energy managing the security risks associated with unreleased versions of UTLS. Just because some projects feel free to use commits from the master branch does not mean everyone else should follow suit. If you believe they are right, please use their client directly instead of demanding that others do the same.

查看完整动态

233boysing-box 部署脚本作者与维护者

作者发言

GitHub·2026.09.10 21:49:53（UTC+8）

233boy：Xray 脚本不打算在更新选项里增加测试版，需要的人自行指定版本更新

在回应「要不要在更新选项里增加一个测试版本」的建议时表示没必要，想用测试版本的用户直接自己指定版本来更新就行，并说明他的看法是绝大多数人用不上这个功能。

作者原文 · 预览@233boy

没必要，想要用测试版本的，直接自己指定版本来更新就行了，我的意思是绝大多数人用不上这

查看完整动态

2dustv2rayN 与 v2rayNG 核心维护者

作者发言

GitHub·2026.09.10 19:05:13（UTC+8）

2dust：无法统一定义“不合格的节点”

作者原文 · 预览@2dust

不合格的节点，这个定义不了。
因为 xray core 安全性要求高，sb 就没有这个要求；并且他们的代码都是随时变化的，无法定义。

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

作者发言

Telegram·2026.09.10 13:41:18（UTC+8）

clash_verge_re：2.5.4 autobuild 若无新问题，将于近期发布

频道原文 · 预览@clash_verge_re

2.5.4 autobuild 进行了海量改进与重构，如果没新问题反馈，将于最近发布，请各位提前下载帮忙测试，在发布前找到问题及时修复 https://github.com/clash-verge-rev/clash-verge-rev/releases/autobuild

敬请关注 每日开发更新频道https://t.me/vergetest

查看完整动态

alireza0X-UI 与 S-UI 核心维护者

作者发言

GitHub·2026.09.10 08:57:12（UTC+8）

alireza0：s-ui 的 web/html 是构建产物，前端改动应提交到 frontend 仓库

在关闭一个主题 PR 时说明，该 PR 的全部文件都在 web/html 下，而这一目录在 .gitignore 中，是 frontend 子模块执行 npm run build 的输出，由 Dockerfile 与发布流程复制到位，仓库不跟踪其中任何内容。因此这里没有可审查的源码改动——主题只以压缩后的 bundle 形式存在（单个文件一行就有 25 万字符），无法看出它实际做了什么；即使合并，下一次发布构建也会重新生成 web/html 并全部覆盖。他表示若想改面板外观，应改 frontend 仓库里的 Vue 组件与 Vuetify 主题，并认为做一轮 Material Design 3 是合理想法、愿意看一下，随后关闭了该 PR。

作者原文 · 预览@alireza0

Hi @YiranrumengQAQ, thanks for the interest — but this can't be merged as it is.

Every file in this PR is under web/html, which is in .gitignore. It isn't
source: it's the output of npm run build in the frontend/ submodule, copied
into place by the Dockerfile and the release workflow. Nothing under it is
tracked in the repository.

That means two things. There's no source change here to review — the theme
exists only as a minified bundle (one line of df02d90cfd573e6a.js is 254,000
characters), so there's no way to see what it actually does. And even if it were
merged, the next release build would regenerate web/html from source and
overwrite all of it, so it would have no effect.

If you'd like to work on the panel's look, the place for it is the frontend
repository, in the Vue components and the Vuetify theme — a change there is
reviewable and survives a rebuild. A Material Design 3 pass is a reasonable idea
and I'd take a look at it.

Closing this one. Thanks for understanding.

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

作者发言

GitHub·2026.09.09 23:47:20（UTC+8）

Clash Verge Rev 提出 Windows 按用户安装与商店分发准备方案

wonfen 提出新增 x64 current-user 安装包、离线依赖及独立更新通道，并准备 SignPath 签名流程和 Microsoft Store 分发。服务与 TUN 的启用仍需明确提权；正式签名和商店提交取决于基金会受理与完整签名产物，目前属于开放提案。

作者原文 · 预览@wonfen

The Windows package currently installs per-machine, downloads WebView2 and the VC++ redistributable during setup, and includes unsigned Mihomo and service executables. It cannot yet provide a current-user installation or meet Microsoft Store EXE package requirements.

Implement an additional x64 currentUser package with offline dependencies and no machine-wide installer actions. Keep service/TUN enablement explicit and elevated, and isolate its update feed and cached installers from the perMachine channel. Preserve the existing release packages.

Prepare SignPath Foundation enrollment and a signing pipeline with an explicit ownership boundary. Resolve upstream PE signatures, sign the app and uninstaller before the outer installer, and generate updater signatures only after Authenticode signing. Production signing and Store submission depend on Foundation acceptance and complete signed payloads.

Validate the actual unsigned/signed payload, silent installation as a standard user without network access, upgrade, uninstall, and perMachine coexistence. Track Partner Center registration and immutable release URLs for submission.

Historical context: #3614. This request re-evaluates the previous Store proposal with an EXE/currentUser delivery plan.

查看完整动态

klzgradNaïveProxy 创作者

作者发言

GitHub·2026.09.09 23:00:43（UTC+8）

klzgrad：因不受约束地发布 AI 内容而封禁 ssharkkky

作者原文 · 预览@klzgrad

The user ssharkkky is blocked from this repo due to unconstrained release of AI slops.

查看完整动态

richerfuPaws 独立开发者

作者发言

GitHub·2026.09.09 17:31:56（UTC+8）

richerfu：模拟器方案暂时沿用当前实现

richerfu 表示，官方模拟器不支持 VPN 配置，所需命令行工具体积较大且当时缺少公开安装方式；自定义 QEMU 镜像也存在组件支持和未知限制。考虑这些取舍，他认为暂时应沿用当前实现。

作者原文 · 预览@richerfu

I'm still unsure which option is better for us. For example:

Using the command-line tool to install an emulator that behaves like HarmonyOS has its drawbacks: the official emulator doesn't support VPN configuration, and we must first install the command-line tool — which currently lacks a publicly available installation method. Additionally, the tool itself is quite large in file size.
On the other hand, using a custom QEMU image also presents challenges: some sub-components or features may not be fully supported, and we aren’t yet aware of all the limitations.
Given these trade-offs, I think we should stick with the current implementation for now.

查看完整动态

RPRXProject X 与 Xray-core 创始人

作者发言

Telegram·2026.09.09 10:22:09（UTC+8）

RPRX：Xray-core 26.9.8 强制 ClientHello 使用 X25519MLKEM768，多个客户端受影响

频道原文 · 预览@projectXtls

26.9.8这个更新猛啊，ClientHello强制X25519MLKEM768，Stash、Quantumult X、Shadowrocket、Loon这几个客户端都干趴下了😏

查看完整动态

FanglidingXray-core 代码贡献者

作者发言

GitHub·2026.09.08 17:33:36（UTC+8）

Fangliding 回应 ECH 的最低 TLS 版本要求

Fangliding 在 ECH 最低 TLS 版本问题的讨论中表示，这是固定要求；如果有人把 Min 设为 1.2，旧版本还能连接属于 bug，留空应该没有问题。

作者原文 · 预览@Fangliding

这是固定要求啊 要是有人填了 Min 1.2 旧版本还能连上属于是bug 空的应该没问题

查看完整动态

FanglidingXray-core 代码贡献者

作者发言

GitHub·2026.09.08 16:24:58（UTC+8）

Fangliding：已在 go1.27 分支做初步迁移，主要让 ML-DSA 使用标准库

Fangliding 链接了 Xray-core 的 go1.27 分支，并表示此前做过一些初步迁移，主要是让 ML-DSA 使用标准库。

作者原文 · 预览@Fangliding

https://github.com/XTLS/Xray-core/tree/go1.27

我之前做了一些初步迁移了 主要是mldsa使用标准库

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.07 14:52:05（UTC+8）

TokenPLS 排查 OpenVPN 兼容性，向 Mihomo 提交 tls-auth 摘要算法修复

TokenPLS 在排查 tls-crypt 超时时发现，tls-auth 固定使用 HMAC-SHA1 会导致 auth SHA256/SHA512 配置握手失败，并向 Mihomo 提交 PR #3189。作者明确说明这是另一项独立问题，不能据此认定原 tls-crypt 故障已解决；该修复 PR 后于 9 月 8 日合并。

作者原文 · 预览@TokenPLS

Update on the tls-crypt investigation.

We now have an interop test that runs the OpenVPN outbound against an official OpenVPN 2.7.5 server with tls-crypt, tls-crypt-v2, tls-auth and auth-user-pass. We will post its results here once the run completes.

One finding already: the upstream tls-auth implementation hard-codes HMAC-SHA1, so any profile that combines tls-auth with auth SHA256 or auth SHA512 cannot complete the handshake at all. That is a different bug from yours; we sent the fix upstream in https://github.com/MetaCubeX/mihomo/pull/3189. If you try the tls-auth comparison we asked for, expect it to fail for that reason until the fix ships, so that comparison is not informative for now. tls-crypt does not depend on auth, so your profile is not affected by that bug.

Still the most useful data for your case: the server-side openvpn --verb 4 lines from the moment the app tries to connect (or confirmation that the server logs nothing at all), and whether the official client on the same Mac connects with the same profile.

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.07 14:24:52（UTC+8）

TokenPLS：use 中只能填写已定义的 proxy-provider 名称

作者原文 · 预览@TokenPLS

all 不是内核的关键字：use: 里只能写 proxy-providers 中定义过的 provider 名字，配置里没有叫 all 的 provider，所以报 'all' not found。两种改法任选其一：

1. 用 include-all——把每个策略组里的

use:
  - all

换成

include-all: true

（只想包含 provider 里的节点用 include-all-providers: true。）

2. 保留 use: [all]——补一个名字就叫 all 的 provider（区分大小写）：

proxy-providers:
  all:
    type: http
    url: 你的订阅链接
    interval: 3600
    path: ./providers/all.yaml

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

Telegram·2026.09.06 13:42:28（UTC+8）

clashbyhako：上游历史与修改说明

频道原文 · 预览@clashbyhako

上游历史与修改说明

Hako 是基于 MetaCubeX/mihomo 的独立衍生项目，上游基线为 v1.19.30，提交为 ac017cdd246ce8bd547653d927e7bf77d7ee73d5。本项目与 MetaCubeX 无隶属关系。上游要求无隶属关系的下游项目不要在项目名称中使用“mihomo”。

2026-09-06，本仓库恢复了截至该基线的完整上游祖先历史，原始提交及贡献者署名均保持不变，并保留了已有公开历史（恢复上游 4,263 个提交及原始署名。）。此次历史衔接保留原已发布源码，仅补充这些来源说明。Hako 的累计修改包括 Apple 绑定、SDK 构建工具及内核适配。比较上游基线与具体 Hako 提交即可查看完整差异；后续修改以增量公开提交记录。
上游 GPL-3.0 许可证保留在 LICENSE 中。署名与依赖许可证见 NOTICE 和 THIRD_PARTY_LICENSES.md。

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

Telegram·2026.09.06 12:58:11（UTC+8）

clashbyhako：关于未从 Mihomo fork 与提交不够原子化的说明

频道原文 · 预览@clashbyhako

关于没从 Mihomo fork，以及提交不够原子化的问题，在这里跪着狡辩一次🙇

README 和官网一直都写着上游是 Mihomo。上游我们认，贡献我们记，GitHub 我们确实还在学。属于是项目先建了，GitHub的驾照还没考到就上路开车了。

给开源社区添堵了，对不起。后面会认真研究仓库历史怎么补救（可能也无法补了），但我们后期的更新也尽量按独立改动拆分提交。
错不起，我对了，都怪 GitHub。

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.06 11:05:27（UTC+8）

TokenPLS：下一版将在启动时读取物理接口的 DNS 解析器

作者原文 · 预览@TokenPLS

Update: this is implemented and is in the next macOS and iOS releases. At start, the client reads the physical interface's resolvers through the system resolver library and hands them to the core; system (and dhcp://) is replaced by those resolvers in every resolver field, nameserver-policy included, so domains assigned to system resolve through your corporate DNS instead of NXDOMAIN. Verified on macOS and iOS that the tunnel now sees the interface's resolvers at start. If a domain still answers NXDOMAIN on the new build, the extension log line system resolvers before the tunnel: shows what it read — please paste it.

查看完整动态

tokenplsClash by Hako 创作者与 Hako 内核核心维护者

作者发言

GitHub·2026.09.06 09:28:54（UTC+8）

TokenPLS：隧道 DNS 设置问题已修复，将随下一个 macOS 版本发布

作者原文 · 预览@TokenPLS

已复现并修复，谢谢这份日志——那三行字典键（ServerAddresses / InterfaceName / ConfirmedServiceID）正是关键。

真因不在 On Demand 本身：隧道扩展给系统下发 DNS 设置时，有一条路径先把 DNS 对象交给了设置、之后才补上「接管全部域名」的匹配项，而系统保存的是交出去那一刻的副本，补上的匹配项从未生效。凡是没走「上次成功设置的快速缓存」的启动都会踩到：配置第一次启动、扩展异常退出后被 On Demand 拉起、切换到一个新配置。手动停止再启动走的是缓存路径，所以立刻恢复。现在两条路径共用一份已经配齐的 DNS 设置。

修复会随下一个 macOS 版本发布；发布后如果同样的恢复场景仍出现 SupplementalMatchDomains 缺失，请再贴一次 utun 的 DNS 字典行。

查看完整动态