nitter不是安装而是部署，必须通过docker、源码编译或预编译二进制启动；推荐docker compose方式，执行docker-compose up -d后需检查docker服务状态、docker-compose.yml存在性、nitter.conf权限及redishost配置，并确保hostname设为实际访问域名、sessions.jsonl文件正确生成并挂载。
直接上结论：Nitter 不是「安装」而是「部署」，它没有传统意义上的 deb/rpm 包，必须通过 Docker、源码编译或预编译二进制三种方式之一启动服务。选 Docker Compose 是最省事、最不容易出错的路径。
docker-compose up -d 启动失败？检查这三件事
很多人执行 docker-compose up -d 后访问 localhost:8080 一片空白或报 connection refused，问题通常不在 Nitter 本身：
- 确认
docker和docker-compose已正确安装且 daemon 正在运行：sudo systemctl status docker - 检查项目根目录下是否存在
docker-compose.yml—— 新版 Nitter 默认不自带该文件，需从仓库docker/子目录手动复制或使用社区维护的模板 -
nitter.conf文件权限是否为当前用户可读（尤其用sudo切换过用户后）；若配置中redisHost指向localhost，而 Redis 运行在容器内，应改为redis（即 compose 中服务名）
hostname 和 port 配置不对，前端资源 404
Nitter 的静态资源路径（CSS/JS）由 hostname 和 port 共同决定。如果你用反向代理（如 Nginx），但 nitter.conf 里仍写 hostname = "localhost"，浏览器会尝试从 http://localhost:8080/static/ 加载资源，必然失败。
- 生产环境务必设为你的域名，例如
hostname = "nitter.example.com"，即使没配 HTTPS，也要匹配你实际访问的地址 - 如果走反向代理且监听 80 端口，
port应保持默认8080（Nitter 内部监听），但 Nginx 的proxy_pass必须指向http://127.0.0.1:8080 - 修改
nitter.conf后必须重启服务：docker-compose restart或sudo systemctl restart nitter
session.jsonl 缺失导致无法加载推文
Nitter 本身不调用 Twitter API，而是复用浏览器端已登录的 Twitter 会话 Cookie。但自 2023 年起 Twitter 加强反爬后，Nitter 必须依赖有效的 sessions.jsonl 文件才能获取数据，否则主页能打开，但所有时间线、用户页都显示 “Something went wrong”。
- 这个文件不能手动生成，必须用项目
tools/目录下的get_session.py或create_session_curl.py抓取（需你自己的 Twitter 账号凭据） - 生成后放到 Nitter 根目录，确保文件名完全为
sessions.jsonl（不是sessions.json或带多余后缀） - Docker 部署时，需在
docker-compose.yml中用volumes映射该文件，例如：- ./sessions.jsonl:/app/sessions.jsonl:ro
真正卡住人的地方从来不是编译或拉镜像，而是 session 获取和 hostname 配置这两环——它们不报错，但让整个服务看起来“正常启动却无法使用”。动手前先确认你有可用的 Twitter 账号，并预留 10 分钟跑通 session 抓取流程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
