Karing v1.2.22.2502 是 2026-07-10 发布的修复版。它处理了一个很具体的回归：Karing 调整 User-Agent 后，部分订阅服务端匹配错误。结果不是普通连接失败，而是更新订阅后出现“客户端太老”一类占位内容。这个现象对应 GitHub Issue #1729。

如果你没有遇到订阅识别异常，也不维护 karing://install-config 链接，这版没有必须立刻覆盖安装的功能。正在受影响的用户则应保留原订阅，升级 Karing 后复测同一份输入。一次只改客户端版本，结论才不会被 DNS、路由或订阅地址变化搅乱。

v1.2.22.2502 修了哪一个真实故障？

GitHub Release 只列了两项。第一项修复 Karing 调整 User-Agent 后，部分订阅服务端出现错误匹配。第二项给 karing://install-config 增加 outbound-dns，导入订阅时可以为代理服务器传入覆盖 DNS 列表。

Issue #1729 提供了这次修复的现场背景：报告者在 iOS 27 beta 3 上从 v1.2.20.2308 升到 v1.2.21.2409，更新若干订阅时看到客户端版本过旧提示；同一系统上的旧版 Karing 没有出现。这个 issue 是单个用户的复现记录，不能推导出所有系统或订阅服务都会受影响。Release 将修复直接关联到该 issue，能确认的是项目方已经为这类匹配错误提交修复。

表现更可能落在哪一层v1.2.22.2502 后怎么验证
更新订阅后只出现客户端过旧提示User-Agent 被服务端规则误匹配更新同一订阅，观察真实服务器条目是否恢复
订阅正常返回，但所有连接都失败出站、DNS 或路由层不要把它归给本次修复，转看日志中的具体出站错误
install-config 导入后代理服务器解析不符合预期深链接没有携带覆盖 DNS，或参数编码错误检查 outbound-dns 是否存在，逗号与 URL 编码是否完整
Karing 根本没有打开导入页面系统未注册深链接，或链接被应用截断先确认 karing://install-config 能被 Karing 接管

你该现在升级，还是等下一个版本？

更新订阅后出现“客户端太老”或相近占位信息，优先升级。尤其是 v1.2.21.2409 上才出现、旧版用同一订阅仍能取得正常内容时，现象与 Issue #1729 很接近。

维护批量导入链接的人也值得升级。outbound-dns 让 DNS 列表跟着安装链接走，省去用户导入后再手工补这一项。但要先在一台设备验证 URL 编码，不能把未验证的深链接直接发给全部设备。

只使用已有配置、订阅更新正常、也不需要 outbound-dns 的用户，可以等。Release notes 没有写内核大版本迁移、配置格式变更或安全修复，没必要把常规小修说成紧急更新。

各平台该拿哪个安装包？

GitHub Release 提供 9 个资产。下面的容量按 GitHub API 返回的字节数换算为 MiB，只用于识别文件，不是下载完整性的依据。桌面端与 Android 包以 github.com/KaringX/karing 的正式 Release 为基准。

平台官方资产约合容量选择口径
Windows 10+ x64karing_1.2.22.2502_windows_x64.exe44.0 MiB常规安装
Windows 10+ x64karing_1.2.22.2502_windows_x64.zip62.6 MiB便携目录、保留旧版并行验证
macOS 12+karing_1.2.22.2502_macos_universal.dmg98.1 MiBIntel 与 Apple Silicon 共用 universal 包
Linux amd64.AppImage / .deb / .rpm70.3 / 49.0 / 52.8 MiB按发行版包管理方式选择
Android arm64-v8akaring_1.2.22.2502_android_arm64-v8a.apk51.1 MiB大多数现代 64 位 ARM 设备
Android armeabi-v7akaring_1.2.22.2502_android_armeabi-v7a.apk51.3 MiB32 位 ARM 兼容设备
Android 未细分 ARMkaring_1.2.22.2502_android_arm.apk87.7 MiB仅按官方文件名识别，Release 未解释其 ABI 组合

官方仓库列出的系统门槛是 Windows 10 及以上、Android 8 及以上、macOS 12 及以上、iOS 15 及以上、tvOS 17 及以上。当前 Linux .deb 还标注 glibc 2.38 及以上。Windows 和 Linux 的 Release 没有 ARM64 桌面资产，不要拿 Android ARM 包替代。

iOS 与 tvOS 走 Apple App Store。2026-07-25 查询时，美区商店版本为 1.2.22.2502。项目 README 还列出 TestFlight、APKPure 与 Amazon Appstore 等渠道，但这些渠道的上架时间可能不同；本文没有逐一验证它们是否已经同步到相同版本。

升级前该留哪三份东西？

第一份是 Karing 的 ZIP 导出。官方路径是 设置 → 备份和同步 → 局域网同步 → 文件导入/导出。同一页还列出 iCloud、局域网与 WebDAV 同步。同步不能代替升级前单独保存的 ZIP，因为官方文档没有说明冲突版本与覆盖顺序。

第二份是原始订阅 URL 与升级前的更新结果。不要截图一半地址，也不要把含凭据的完整 URL 发到 issue。保存在本机加密存储中，并记录旧版更新后出现的是正常条目还是占位提示。

第三份是旧安装包。Windows ZIP 版可把当前目录另存一份，安装版保留旧 .exe。macOS、Linux 和 Android 至少留住上一个能工作的官方安装资产。旧程序只用于尝试退回程序版本，不能替代 ZIP 配置备份；Karing 官方没有承诺跨版本降级兼容。

已启用 iCloud 或 WebDAV 时，升级和恢复期间不要主动触发多端同步。先在一台设备确认 ZIP 能恢复正确配置，再决定是否把这个状态同步到其他设备。

怎样核对安装包没下错？

GitHub API 为本次 Release 的每个资产返回 SHA-256 digest。文件名和容量只能排除明显下错，真正的校验要比较完整哈希。安装了 GitHub CLI 时，可以一次列出 9 个文件名与 digest：

gh api repos/KaringX/karing/releases/tags/v1.2.22.2502 \
  --jq '.assets[] | [.name, .digest] | @tsv'

2026-07-25 取得的完整结果如下。sha256: 前缀来自 API，计算本地文件时只比较冒号后的 64 位十六进制字符串。

3010cba0eb49c94abde9a15b7178a8a50502e2d040cdea4e3cfcb55ec075391e  karing_1.2.22.2502_android_arm.apk
f71f6f4627ffd88fa04a36cae234367d238e4acd85f1eddcee4198af1fc802a8  karing_1.2.22.2502_android_arm64-v8a.apk
dfc8ae716b632cf712d86f187189b9d6fee045755b107c4774feda1246a0ebae  karing_1.2.22.2502_android_armeabi-v7a.apk
b825fb0fc6b55277760b816e389cf409969518a23a9f9509a3bcc154e99fd5f0  karing_1.2.22.2502_linux_amd64.AppImage
fc79de8d4069576b430a5deb296804d832aeaa4147fde312d2e7cfa0ca43a5ae  karing_1.2.22.2502_linux_amd64.deb
c7aa78c8788868195e8a27ef673235285dc8b586c5b4a6eb2162b0b43d36bbb4  karing_1.2.22.2502_linux_amd64.rpm
5dbf6d57013dccb57ff8d9b542527ccc63fe9f806ebf299e08517f25c0fe8407  karing_1.2.22.2502_macos_universal.dmg
a6c79f9410d9271d1fe4b584a01cdebe39e97c61803327185f3bda717835cb97  karing_1.2.22.2502_windows_x64.exe
7951437a8eb33f60f47158b3ea56b4d84640a519a9e6b59784d475c5adf99b15  karing_1.2.22.2502_windows_x64.zip

Windows PowerShell 可以这样算 .exe：

Get-FileHash .\karing_1.2.22.2502_windows_x64.exe -Algorithm SHA256

官方 digest 应为：

a6c79f9410d9271d1fe4b584a01cdebe39e97c61803327185f3bda717835cb97

macOS 对 .dmg 执行：

shasum -a 256 karing_1.2.22.2502_macos_universal.dmg

官方 digest 应为：

5dbf6d57013dccb57ff8d9b542527ccc63fe9f806ebf299e08517f25c0fe8407

Linux 对 .deb 执行：

sha256sum karing_1.2.22.2502_linux_amd64.deb

官方 digest 应为：

fc79de8d4069576b430a5deb296804d832aeaa4147fde312d2e7cfa0ca43a5ae

输出必须 64 位十六进制字符逐位一致。不同就删除该文件，从 KaringX/karing 的正式 Release 重新取得；不要用文件名相同作为继续安装的理由。SHA-256 只能确认文件与 GitHub 托管的 asset 一致，不能代替代码签名或证明软件没有安全问题。需要保存校验记录时，可照着 GitHub Release SHA-256 校验步骤 操作。

outbound-dns 参数该怎么读？

这个参数跟在 karing://install-config 深链接中。Release 给出的结构是一个经过 URL 编码的订阅地址，加一个用逗号分隔的 DNS 列表：

karing://install-config?url=https%3A%2F%2Fexample.com%2Fconfig.yaml&outbound-dns=udp%3A%2F%2F8.8.8.8%2Cudp%3A%2F%2F5.5.5.5

这里的 url 是要导入的订阅，outbound-dns 是给代理服务器使用的覆盖 DNS 列表。它不是“把系统 DNS 全部改成这两个地址”的开关，也不是用来修复 Issue #1729 的参数。两项改动恰好出现在同一个 Release，不代表存在因果关系。

维护这类链接时，先在测试设备打开一次。Karing 应进入配置导入流程，并显示对应订阅；导入后再查看代理服务器 DNS 设置是否取得两项值。如果系统只把链接当普通网页打开，先处理深链接注册，不要继续改参数。需要对照现有配置入口时，站内的 Karing 配置教程 列出了订阅与 DNS 的基础路径。

User-Agent 修复生效后会看到什么？

验证只保留四个固定条件：同一台设备、同一条订阅、同一组 Karing 配置、相近的更新时间。唯一变化是客户端从旧版切到 v1.2.22.2502。

升级后手动更新该订阅。原先出现“客户端太老”占位内容，现在返回真实服务器列表，才算命中修复。列表恢复后任选一个原有条目，查看 Karing 日志是否正常创建出站；不要因为条目出现就直接断言所有连接已恢复。

可以把验证记录写成这四行，订阅 URL 只留域名或自行脱敏：

Karing: v1.2.22.2502
subscription: example.com / 已脱敏
update result: 正常条目 / 客户端版本提示 / 其他错误
outbound result: 已创建 / 未创建

如果提示仍在，回到旧版对同一订阅再更新一次。旧版正常、新版异常，就把版本、系统和脱敏后的响应现象补到 GitHub Issue；两个版本都异常，则更像服务端规则或订阅本身发生了变化。

回滚时别让同步覆盖正确配置

Karing Release 没有承诺跨版本降级兼容。桌面端回退时，先退出新版，再安装或解压上一个官方资产；Windows ZIP 版应解压到新目录，不要直接覆盖当前目录。先看旧版能否启动并读取现有配置，读不到或内容已改变时，再从 设置 → 备份和同步 → 局域网同步 → 文件导入/导出 导入升级前的 ZIP。

恢复完成的判断不是“界面打开了”，而是订阅数量、路由组、手工选择和同步状态与备份一致。然后只更新一条受影响的订阅。旧版同样返回异常时，不要继续来回安装版本，转去核对服务端响应。Windows 上的 DNS 或 TUN 同时出错时，另看 Karing Windows DNS、TUN 与导入排查，不要把系统层故障当成本次 User-Agent 回归。

Android 旧 APK 能否覆盖安装、能否继续读取新版数据，本文没有逐机验证。Karing 官方下载页给 iOS 与 tvOS 的入口只有当前 App Store 版和 TestFlight，也没有历史版本选择。因此移动端要把“恢复配置 ZIP”和“退回应用版本”分开看，不能把前者当成后者。

Release notes 没承诺什么？

v1.2.22.2502 没有公布针对所有订阅格式的回归测试结果，也没说每一种服务端 User-Agent 规则都已覆盖。outbound-dns 的 Release 说明给了参数结构，但没有列出每个平台的界面差异。

本文没有在 Windows、macOS、Linux、Android、iOS 与 tvOS 上逐端安装，也没有用真实订阅执行兼容性测试。安装包、digest、版本时间与 App Store 版本来自 2026-07-25 的官方页面和 API；功能是否适合你的配置，仍要用升级前保留的同一份输入判断。

下一步很明确：受 Issue #1729 同类问题影响的人，先备份 ZIP 和旧安装包，再升级、校验、更新同一条订阅。其余用户把 v1.2.22.2502 记作一次小修即可，不必为两个 Release 条目重做整套配置。