nemu-xClashFest 核心作者

作者发言

GitHub·2026.10.02 23:00:05（UTC+8）

nemu-x 说明 SlothClash 设备标识头行为与 ClashFest 内核版本识别方式

nemu-x 在 Miroshka000/mikan 的 PR #13 审查回复中确认并说明：SlothClash 仅在 PrivacySettings.IsHwidEnabled() 为真时设置 x-hwid 头，磁盘无设置文件时默认开启，用户可在「高级」中关闭；x-device-os、x-ver-os、x-device-model 三个头无论是否开启都会发送。ClashFest 的正式构建不会发送裸 mihomo：构建期以 git describe --tags --exact-match --match v[0-9]* 从内核子模块读取标签，回退到最近标签（--abbrev=0），再回退到 go.mod 中的 require github.com/metacubex/mihomo；release 与 dev 工作流以 fetch-depth: 0、submodules: recursive 检出，因此标签存在。裸 token 只出现在无标签、无 go.mod 的本地检出，用户不会遇到。另确认已移除过期的 appName 注释（提交 2c5a172），并表示保留该提示、Android 列表位置由对方决定。

作者原文@Nemu-x

Fixed and confirmed:

• appName comment: the stale one is gone, only the new one is left (2c5a172).

• SlothClash and x-hwid: the header is set in subscription_identity.go#L85-L88 only when PrivacySettings.IsHwidEnabled() is true; the default with no setting on disk is true (tun_settings.go#L140-L147). The user turns it off in Advanced. x-device-os, x-ver-os and x-device-model are sent regardless, so the hint matches the code.

• Bare mihomo from ClashFest: a published build does not send it. The tag is read from the core submodule at build time with git describe --tags --exact-match --match v[0-9]*, falling back to the nearest tag (--abbrev=0) and then to the require github.com/metacubex/mihomo line in go.mod (core/build.gradle.kts#L28-L46, the same chain in CMakeLists.txt#L44-L70 for the Go side). The release and dev workflows check out with fetch-depth: 0 and submodules: recursive, so the exact tag is there. The bare token is left for a local checkout with no tags and no go.mod, which no user gets. I would keep the note as it is.

The position on the Android list is yours, of course.