下载代理客户端、内核或规则工具时，最浪费时间的误判是：文件已经下错，却继续排查订阅、DNS、TUN 或系统代理。GitHub 官方文档说明，Release 是基于 Git tag 发布的软件迭代，可以附带二进制文件供下载；这些文件在页面里就是 release asset。

这篇文章只处理安装前的下载校验，不评价客户端是否值得换，也不把镜像页面当版本来源。命令适用于 Windows PowerShell、macOS 终端和 Linux shell。

哪个页面才算官方源？

官方源不是「长得像 GitHub」的页面，而是项目维护者长期使用的 owner/repo。下载前先把浏览器地址栏里的 4 个字段写下来：

字段示例为什么要看
ownerMetaCubeX同名 fork 可能换 owner
repomihomo项目名相似不等于同一项目
Release tagv1.19.xtag 对应一次发布
release assetmihomo-linux-amd64...asset 才是你真正下载的文件

GitHub 文档还提醒，tag 日期和 release 日期可能不同。看到「发布时间更新」不要急着下包，先确认 tag、asset 和说明是否属于同一页。

release asset、源码包和 checksum 有什么区别？

Release 页面通常会同时出现维护者上传的 asset，以及 GitHub 自动生成的源码 zip、tarball。它们不是同一个东西。

看到的文件常见用途校验重点风险点
.exe / .msiWindows 客户端安装SHA256、签名、文件名架构同名安装包来自假仓库
.dmg / .zipmacOS 客户端或便携包SHA256、系统签名提示darwin-amd64 和 darwin-arm64 下错
.tar.gz / .gzLinux 内核或 CLISHA256、CPU 架构amd64、arm64、mips 混用
Source code.zipGitHub 自动源码归档不等于预编译客户端拿源码包当可执行文件
checksums.txt / SHA256SUMS文件哈希清单必须来自同一 tag用旧清单校验新 asset

GitHub 的 release integrity 文档给出 gh release verify 和 gh release verify-asset。这类验证和 checksums.txt 不是互斥关系：能用 GitHub CLI 时可以多一层；项目只给 SHA256 时，就把 SHA256 做扎实。

文件名伪装通常卡在哪一步？

文件名最容易骗人，因为攻击者或低质量镜像只要复制 Clash.Verge_2.x_windows_x64.exe 这种名字，就能让用户误以为来源正确。判断时不要只看最后一段文件名。

伪装信号你该看什么停止条件
owner 拼写接近项目官网、README、长期 issue 活跃仓库owner 不一致且没有迁移公告
release 数量很少历史 tag、release notes、维护者账号只有一个下载按钮和空 README
asset 名称很像同一 tag 的 checksum 里是否有该文件清单没有这个文件名
页面给了哈希截图是否有可复制文本或签名文件只有图片、评论区或网盘说明
镜像比官方更新官方 Release 是否已有同 tag镜像出现官方不存在的版本

真正的检查顺序是从来源往文件走：官方仓库 -> tag -> asset -> checksum -> 本机文件。反过来从文件名猜来源，风险会高很多。

Windows 怎么算 SHA256？

Windows 10/11 自带 PowerShell 的 Get-FileHash。把文件放到下载目录后运行：

cd $env:USERPROFILE\Downloads
Get-FileHash .\client-windows-amd64.exe -Algorithm SHA256

输出里看 Hash 一列。把 64 个十六进制字符和 checksums.txt 里的同名文件逐字符比对。

如果文件名里有空格，用引号：

Get-FileHash ".\Client Setup x64.exe" -Algorithm SHA256

PowerShell 输出大小写不影响结果，但字符必须完全一致。只比前 8 位不够，尤其是要给软路由、NAS 或多台 Windows 电脑分发时，必须留完整哈希。

macOS 怎么校验 dmg、zip 和 tar.gz？

macOS 终端常用 shasum -a 256：

cd ~/Downloads
shasum -a 256 ./client-darwin-arm64.dmg

Apple Silicon 设备通常要看 arm64 或 aarch64，Intel Mac 通常看 amd64 或 x64。如果你下载的是 universal 包，也要看 Release notes 是否说明同时支持两类架构。

校验通过后再打开 dmg。系统弹出的开发者签名、隔离提示和权限请求，解决的是另一个问题：这个应用在 macOS 上如何运行。它不能替代 SHA256，也不能证明你下的是正确 tag。

Linux 怎么校验 tar.gz、gz 和 AppImage？

Linux 常用 sha256sum：

cd ~/Downloads
sha256sum ./client-linux-amd64.tar.gz

如果项目提供 checksums.txt，可以让命令自动按清单检查单个文件。先确认清单里有你的文件名：

grep 'client-linux-amd64.tar.gz' checksums.txt
sha256sum -c checksums.txt --ignore-missing

--ignore-missing 只检查当前目录里存在的文件，不代表清单里的其它 asset 也通过。给 OpenWrt、Debian、Ubuntu 或 NAS 准备二进制时，还要看 CPU 架构：x86_64、aarch64、armv7、mipsle 不能混用。

GitHub CLI 能验证什么？

GitHub CLI 适合已经安装 gh、且项目支持对应 integrity 信息的场景。官方文档给出的两个入口是：

gh release verify RELEASE-TAG
gh release verify-asset RELEASE-TAG ./client.zip

在仓库目录外执行时，加上 -R owner/repo 更清楚：

gh release verify v1.2.3 -R owner/repo
gh release verify-asset v1.2.3 ./client.zip -R owner/repo

这类命令不能用来验证 GitHub 自动生成的源码 zip 或 tarball，因为那些归档是在下载请求时创建的。你要验证的是维护者上传的 release asset，例如安装包、压缩包、内核文件或规则包。

checksum 不匹配时怎么处理？

不要安装，也不要把问题带进客户端配置排查。按下面顺序处理：

  1. 删除本地文件，重新从官方 Release 页下载一次。
  2. 确认 checksum 和 asset 来自同一个 Release tag。
  3. 检查浏览器是否把文件保存成 client (1).zip。
  4. 确认你算的是压缩包本身，不是解压后的目录。
  5. 确认架构字段没有混用，例如 windows-amd64 和 windows-arm64。
  6. 仍不匹配时，等待维护者说明或退回前一个可信 tag。

如果项目重新上传了同名 asset，但没有说明原因，这份文件不适合直接放到生产设备。至少等 release notes、issue 或安全公告说明变更原因。

SHA256 校验不能证明什么

SHA256 只能说明「本机文件内容」和「发布方给出的哈希」一致。它不能单独证明发布者身份，也不能判断客户端运行后是否有新的安全问题。

签名验证同样有前提：公钥、证书条件、bundle、签名文件必须来自项目文档或同一 Release 说明。GitHub 的 commit signature verification 主要解释提交和 tag 的签名状态；它不是所有 release asset 的自动安全保证。

这篇没有测试每一个客户端项目的签名体系，也没有覆盖应用商店、系统包管理器、Docker 镜像和浏览器扩展。那些分发渠道有自己的签名、审核或索引机制，不能直接套用同一条命令。

下载安全继续看哪些页