下载托管

下载托管¶

公共路径¶

anoma.ly/release/hex/                      the Anomaly release service (docs/releasing.md)
├── index.json, desktop/stable.json        what the site, installers, and apps read
└── files/<sha256>/<name>                  hex-<v>-macos-arm64.{zip,dmg}, hex-<v>-windows-<arch>.exe,
                                           hex-setup-<v>-windows-<arch>.exe,
                                           hex-<v>-linux-<x64|arm64>{,.deb,.rpm}
anoma.ly/hex                               the one site: platform-aware download (Worker hex-production-site)
├── download/<target>                      302 to anoma.ly/release/hex/desktop/stable/<target> once stable.json
│                                          exists, else to .../dev/<target> (the newest dev build)
├── install-linux.sh, install-windows.ps1  installers (once the production site is deployed from production)
└── files/…                                hex-production-files:
    ├── install-linux.sh, install-windows.ps1   the current installers (Installers workflow, from dev;
    │                                           stable, or dev until there is a stable release)
    ├── linux-update.json, windows-update.json, windows-aarch64-update.json, appcast.xml  frozen for 2.3.1
    └── releases/HEX-2.3.1-…                    frozen 2.3.1 files
dev.anoma.ly/hex                           the dev site (reads anoma.ly/release; the service's dev stage
                                           is only for testing the service)
hex.kitlangton.com, .dev                   Kit's old site (Kit's Cloudflare account); should 301 to
                                           anoma.ly/hex (Kit's change; nothing links to it)
downloads.hex.kitlangton.dev, .com         Kit's old bucket, frozen at 2.3.1; releases up to 2.3.1
                                           compiled it, so it stays up forever; the Worker in
                                           packaging/legacy-downloads redirects it to
                                           anoma.ly/hex/files (same bytes) once deployed
github.com/anomalyco/hex/releases/tag/v<version>       identical-byte mirror of every file (app-v through 2.3.1)

docs/releasing.md 描述了 Worker 配置、发布这些文件的流程、凭据，以及从 Kit 的存储桶迁移的过程。

hex-production-files 使用旧存储桶提供的所有内容的字节副本进行初始化。anoma.ly 区域中的一条配置规则会为 anoma.ly 和 dev.anoma.ly 上的 /hex/files/ 禁用 Browser Integrity Check：该区域检查曾对 Python 的默认用户代理返回 HTTP 403。请勿在下载和更新路由上启用浏览器质询。

发布工作流会将每个文件上传到发布服务（按哈希存储，绝不替换），然后发布版本，再将文件镜像到 GitHub 发布（逐字节验证）。应用标签与 TypeScript SDK 标签保持分离。稳定版应用发布是 GitHub 的 Latest 发布（仓库徽章）；SDK 发布使用 --latest=false 创建，永远不会占用该徽章。不过，请不要使用 GitHub 的通用 releases/latest 重定向来下载应用：链接应指向发布服务或明确的 v<version> 标签。

网站在构建时会读取稳定版清单，因此稳定版发布之后的生产部署会更新所有链接。请手动更新 README 中显式的应用镜像链接；Release 工作流会推送 anomalyco/homebrew-tap/Casks/hex.rb。

bun run --cwd site check:downloads 必须通过；然后验证实际链接。

网络恢复¶

应用和模型下载使用不同的主机。受管网络可能需要允许：

• anoma.ly（路径 /release/，以及针对 2.3.1 的 /hex/files/）用于应用下载和更新（downloads.hex.kitlangton.dev 也用于最高到 2.3.1 的发布，这些发布通过重定向访问 anoma.ly）。
• GitHub 发布下载及其资产交付主机，用于备选 DMG。
• huggingface.co 及其模型下载 CDN，用于听写模型的设置。

2026 年 9 月 11 日，对固定的默认 Parakeet Unified English 工件发出的 HEAD 请求从 huggingface.co 跟随到 us.aws.cdn.hf.co，并返回 HTTP 200。这是一个观察到的交付主机，并非持久且详尽的 CDN 列表。该检查未下载任何模型主体。

模型下载、更新检查和转换脚本中的 fetch 都通过 Hex 自己的 HTTPS 客户端（src/net.rs，#894）进行，该客户端在受管网络上的行为类似于浏览器：

• 代理：在每个操作系统上都会读取 HTTPS_PROXY、HTTP_PROXY、ALL_PROXY 和 NO_PROXY（大写或小写），否则使用系统设置。Windows：使用已登录用户的代理（设置 › 网络 › 代理、Internet 选项）、该用户的 PAC 文件或 WPAD，然后使用机器的 WinHTTP 代理（netsh winhttp set proxy）。macOS：使用网络的 HTTP 和 HTTPS 代理及其例外；不会评估 PAC 文件，因此 Hex 会跳过它，转而使用列表中的下一个 HTTP 或 HTTPS 代理（#1235），而仅依赖 PAC 的网络需要设置 HTTPS_PROXY。Linux：仅使用环境变量。需要登录的代理（NTLM、Kerberos）会失败，并显示“代理需要登录”。
• TLS：使用平台自身的实现（SChannel、Security.framework、OpenSSL），并携带系统受信任的根证书，因此，对于 TLS 检查防火墙，只要 IT 已安装其根证书，就会被信任。缺少根证书时会显示“证书不受信任”。
• 失败：一行信息中会说明主机、代理和原因（“无法通过代理 proxy.corp:8080 访问 huggingface.co：……”），然后给出可以尝试的方法。下载以 8 MB 的范围分片进行，每个分片有 5 分钟的上限，因此停滞的连接会失败而不是挂起，并会从停止处继续。

2026 年 11 月在 apollo（Linux）上观察到：语音检测器、更新清单和一个 fetch 在以下情况下都能工作：直接连接、通过 mitmproxy（其根证书位于信任库中）、以及设置 NO_PROXY 绕过失效代理；当根证书缺失时，每一项都会失败并指明证书；当代理失效时，每一项都会指明被拒绝的代理。未观察到：真实受管网络上的 Windows 和 macOS 系统代理设置（Windows 代码仅交叉编译）。

如果旧更新端点被阻止，请手动安装新的已签名 DMG。恢复模型主机访问后，请在“设置”中重试准备。传输失败会保留部分下载。应用下载成功并不代表模型主机可达，我们的外部检查也不能确定特定企业网络的访问情况。

观察到的迁移检查 — 2026年9月11日¶

• 初始的 2.1.16 镜像和自定义域名的 DMG 与已发布的 Homebrew SHA-256 一致：102dc1a8d80dc359ee15a30141957b6a311e581214b44a3c615026fa91288b8a。其公证盖章（notarization staple）验证通过。
• 所有五个保留的 Sparkle ZIP（2.1.12–2.1.16）均通过自定义域名直接获取，与准备好的构建产物进行比较，对照 feed 的长度进行核对，并使用应用的 Ed25519 公钥进行验证。
• 迁移仅更改了 feed 的主机名和行尾空白；版本、签名、长度和发布说明均保持不变。发布的 feed 从自定义主机和旧的 R2 端点读回时完全相同。
• 在 1280×900 和 390×844 下渲染并检查了线上网站。两者均显示了版本、要求和备用链接。
• Homebrew 的 cask 和 livecheck 使用自定义主机名；在主机迁移期间，2.1.16 的校验和保持不变。
• cargo test --locked：455 项通过，10 项可选测试被忽略，所有 12 个键盘布局子进程均通过。在成功运行之前，清理了一个过期的 Homebrew libgit2 构建缓存路径。严格的 all-target/all-feature Clippy 检查以及网站的 TypeScript/生产构建均通过。
• 尚未发布任何已签名的 Linux feed。Linux 安装程序/更新程序的源默认值已迁移；在这些托管检查中，未执行 Linux 原生安装或企业网络测试。

观察到的 2.1.17 发布 — 2026年9月11日¶

从 5825a84 发布了 macOS 构建版本 20117，其中包括新的内置 Sparkle feed URL 和模型下载恢复文案。应用和 DMG 均已被 Apple 的公证服务接受并盖章（stapled）。Bundle 标识、签名团队、Sparkle 密钥、归档布局以及两个打包的应用副本均通过发布验证器。打包的可执行文件在未启动 GUI 的情况下报告了 2.1.17；其动态库列表中不包含 Homebrew 或 /usr/local 依赖项。

• DMG SHA-256：b8b9d0abecd86a73169ded8941b7c1979bd22d7fc838cc7b9e8696f15570bcc8。
• Sparkle ZIP SHA-256：b773685fba2fb105c91eb30a4a8434003bcba300bece837149b3f42a5fcf17ce。
• 该 ZIP 的 Ed25519 签名已独立验证，与其中的应用内公钥匹配。发布后，自定义域名的 DMG、ZIP 和 latest-DMG 指针与准备好的文件逐字节一致。两个 feed 端点使用 Sparkle 用户代理返回了完全相同的 2.1.17 appcast。
• GitHub 上的 app-v2.1.17 发布是公开的，其 DMG 具有相同的 SHA-256。Homebrew 的 cask 固定在该版本和校验和上；其样式检查通过。
• 一个干净的无头 Chromium 会话阻止了所有 *.r2.dev 请求，点击了线上网站的主下载按钮，并验证了完整 DMG 的校验和。在自定义下载主机也被阻止的情况下，点击 GitHub 备用链接仍然下载了相同的 DMG。这证明了独立的浏览器下载路径，而非特定企业的网关行为。
• 桌面端和移动端的实时渲染显示 2.1.17、要求和备用链接，且没有水平溢出。在主机名迁移期间，Curl、Homebrew、Sparkle、Python 以及浏览器用户代理探针在进行分段下载时均直接收到了 206 响应。
• 该镜像辅助工具还曾针对某个现有发布的、内容故意不同的本地 DMG 运行；在发布或替换 GitHub 资产之前，它检测到不匹配并拒绝操作。
• 最终的 debug 和 release 套件各通过 457 项测试，10 项可选测试被忽略，并且每种配置文件下的所有 12 个键盘布局子进程也均通过。严格的 all-target/all-feature Clippy 检查在两个配置文件中均通过。格式化、应用身份保护、shell 语法、diff 检查以及网站的生产构建均通过。

在此次发布验证中，未执行本机原生原位 Sparkle 安装、新模型下载、麦克风采集或 Linux 二进制文件的发布。