Nitter：无需 JavaScript 与登录的隐私友好 X（Twitter）前端

核心判断

Nitter 解决的是一个具体的、长期存在的矛盾：X（原 Twitter）把未登录用户挡在时间线之外，而官方网页端内置大量 JavaScript 追踪与广告。Nitter 用 Nim 重写了一个"无 JavaScript、无广告、所有请求走后端"的前端，让隐私敏感用户可以在不暴露 IP 与浏览器指纹的前提下读推文。

它的生存方式也决定了它的命门：靠 X 的非官方 API 活着，X 随时可以掐断。过去三年它经历了完整的一个循环——2024 年初 X 封掉 guest account，公共实例集体瘫痪一年；2025 年初靠真实账号的 session 池恢复；2026 年 8 月 24 日 X Corp. 发出停止函，要求永久下线所有实例与仓库；9 月 11 日仓库被归档为只读。README 随后更新了一句话：项目在获得法律建议后将继续存在，详情稍后公布。

当前状态可以概括为：技术上可用，公共实例在跑，法律上悬而未决。

它解决什么问题

官方 X 网页端对隐私敏感用户是三重障碍：

1. 必须有 JavaScript 才能用：X 官方端无法在禁用 JS 时加载。
2. 必须登录：2023 年年中起，未登录无法浏览时间线。
3. 追踪面大：即使挂了 VPN 和强力广告拦截，浏览器指纹仍可能被精确识别，而且指纹识别不依赖 JavaScript。

Nitter 的回应是四件事：

• 无 JavaScript、无广告：页面是纯后端渲染的静态 HTML。
• 所有请求走后端：浏览器从不直接与 X 通信，X 看到的是 Nitter 服务器的 IP，不是你的；JS 指纹追踪也随之被隔离在后端之外。
• 体积更轻：README 举例，@nim_lang 账号的推文页 Nitter 约 60KB，官方约 784KB；时间线普遍快 2-4 倍，平均轻约 15 倍。
• 内置 RSS：不需要账号就能订阅任意用户的推文流。注意 RSS 是按实例提供的功能，公共实例常因订阅请求被滥用而将其禁用。

许可是 AGPLv3。它不禁止自建，但要求实例代码保持开源——不允许出现闭源修改后上线的"专有实例"。

技术形态

Nitter 用 Nim 编写（编译型语言，语法接近 Python 但是静态类型，编译出单个原生二进制），依赖 Redis/Valkey 做缓存。它调用的是 X 的非官方 API（无需开发者账号），整体可以理解成一个"反代 + 缓存 + 轻量渲染"的组合：后端负责抓取与缓存，前端只输出静态 HTML。

一次请求的完整路径是这样的：

你打开 nitter.example.org/elonmusk
  → Nitter 后端先查 Redis：这条时间线缓存过吗？
      命中 → 直接渲染 HTML 返回（X 全程不知情）
      未命中 → 后端从 session 池里取一个 X 账号的会话，
               用它调 X 的非官方 API 拉数据
               → 存入 Redis → 渲染静态 HTML 返回

这个路径解释了 Nitter 的两个特征。其一，隐私保护是结构性的：客户端与 X 之间没有任何直接连接，追踪在架构上就不可能发生。其二，session 池是整个系统的软肋——这是 2024 年瘫痪事故的核心，下文时间线会展开。

社区生态有两个配套设施：官方 wiki 维护公共实例清单，社区提供的浏览器扩展可以把 twitter.com/x.com 链接自动重定向到你配置好的 Nitter 实例。

三起两落：一条时间线

理解 Nitter 的现状，必须知道它已经死过一次。

2024 年那次瘫痪值得多看一眼。Nitter 原本靠 guest account——X 发给匿名访客的临时凭证——免登录抓数据，成本几乎为零。X 关闭注册通道后，这条路彻底走死，zedeus 一度认为项目没救了。2025 年的恢复方案本质是换一种姿势面对同样的墙：改用一批真实注册账号的 session token，轮换着去调 API。方案能跑，但账号是稀缺资源，公共实例因此普遍限速，配额用尽就暂时不可用；自建实例也需要自己在 wiki 指南的指引下创建 session token 并填进配置。

停止函之后的事情还没有结论。仓库归档通常意味着停止活跃开发，但"项目将继续存在"的声明说明法律层面的博弈没有结束。Nitter 是否继续存在，最终取决于这场博弈的结果，而不是代码质量。

公共实例现状

实例列表（官方 wiki 维护，2026 年 9 月 11 日版）里，官方实例只剩 nitter.net，另有 7 个第三方公共实例标记在线，包括 xcancel.com、nitter.poast.org、nitter.tiekoetter.com 等，其中 nitter.catsarch.com 还提供 Tor onion 地址，另有实例提供 I2P 接入。

两个实用入口：

• 健康检查：status.d420.de（nitter-status）实时显示各实例的运行状态，挑实例前先看这里，比挨个试快得多。
• Twiiit：twiiit.com 会把访问随机跳转到列表中存活的实例，适合不想记地址的场景。

公共实例被 X 封禁地址是常态，实例清单本身也在频繁变动——这个项目从诞生起就没有"稳定"二字，使用预期要相应放低。

自建实例：路径与代价

公共实例不可靠，自建是隐私敏感用户更可控的选择。代价是要管理 X 账号的 session token，并且自己承担条款风险。

部署有三种方式，依赖相同：Nitter 本体加一个 Redis/Valkey。缓存层推荐 Valkey 而不是 Redis——Redis 主项目 2024 年起不再开源，Valkey 是社区接管的 BSD 分支，默认配置（默认端口、localhost）即可直接使用。

• 编译安装：需要 Nim 工具链，另需 libpcre、libsass。克隆仓库后依次执行 nimble -l build -d:danger --mm:refc、nimble -l scss、nimble -l md（生成二进制、样式与文档），然后复制 nitter.example.conf 为 nitter.conf，填好主机名、端口、HMAC 密钥、https 与 Redis 信息。
• Docker：官方镜像 zedeus/nitter:latest 为多架构，原生支持 amd64 和 arm64；Redis 需单独起容器，也有 docker-compose 方案。一个容易踩的坑：nitter.conf 必须先在宿主机上存在再挂载，否则 Docker 会把它当成目录静默创建，启动即失败且报错不明显。
• systemd：仓库提供 service 文件示例（Type=simple、Restart=always、RestartSec=15），用 systemctl enable --now nitter.service 启用。

两个运维要点：无论哪种方式，README 都建议放在 Nginx/Apache 反向代理后面，一是安全，二是性能；Nitter 的日志目前只输出到 stdout，没有日志文件，排查问题用 journalctl -u nitter.service（systemd）或 docker logs --follow（Docker）。

功能层面，嵌入（embed）已支持，路线图上的账号系统设计给自建者留了想象空间：关注 X 用户、获得干净时间线，而自己不需要 X 账号。

适用边界

适合：想无账号、无 JS 地读公开推文并保留隐私的用户；需要 RSS 订阅 X 内容的自动化场景（自建实例才能保证 RSS 稳定开启）；对"Nim 写高性能反代"感兴趣的开发者——它是 Nim 生态里最有名的项目之一。

不适合：需要官方完整功能（发推、DM、复杂交互）的用户——Nitter 是只读前端；对部署稳定性有硬要求的生产环境——公共实例随时可能被断，自建实例则要持续维护账号池。

正在考虑自建的：把条款风险算进成本。它依赖 X 的非官方 API，本身处于 X 服务条款的灰色地带；停止函说明 X 已经开始用法律手段处理这类前端，自建实例运营者的风险敞口需要自己评估。

结论

Nitter 在技术上是"用最小体积换最大隐私"的范本：无 JavaScript、请求全部走后端、页面轻 15 倍，隐私保护是架构自带的属性，不是功能开关。但它三年的生存史也说明了一件事：依赖非官方 API 的第三方前端，价值与风险始终是一体两面——2024 年被掐一次，2026 年收到停止函，每次都命悬一线。

落到操作上，可以按这个顺序决策：只是偶尔读推文，从 status.d420.de 挑一个健康的公共实例，配合浏览器扩展使用；重度或自动化使用，自建实例加 Valkey，RSS 才能稳定；生产环境则不要把它当关键依赖——归档状态下的项目，任何承诺都给不了。它作为参考实现的价值（架构、Nim 工程实践、隐私前端的完整形态）不会因归档消失，趁仓库还在线，值得读一遍源码。

延伸

• 仓库（已归档，只读）：https://github.com/zedeus/nitter
• 实例列表（wiki）：https://github.com/zedeus/nitter/wiki/Instances
• 实例健康检查：https://status.d420.de
• 同类先例：Invidious——YouTube 的隐私友好替代前端，同为"第三方反代 + 无 JS 前端"模式