Nitter 開源 Twitter 前端：2026 年還能用嗎，公開實例與自架的真實狀態

Facebook Line Messenger Telegram

Nitter 是一個讓你在不碰 Twitter 廣告、不載入 JavaScript 的前提下瀏覽推文的開源前端，你的瀏覽器指紋也留在自己這一端，不交給 X（倉庫 zedeus/nitter，AGPL-3.0 授權）。它的賣點從 2019 年成立至今沒變，但 2026 年的運作方式已經和早期完全不同。這篇文章給的是認識加上第三方狀態觀察，不是評測。我查過 GitHub 倉庫的即時資料和一份追蹤公開實例健康度的儀表板，但我沒有自己架一台 Nitter 來跑，所以載入速度、你所在網路能不能連上特定實例、session token 被封多久，這些都得你自己驗證。

伺服器端代理：你從頭到尾不碰 Twitter

Nitter 的核心架構是一台伺服器代替你向 Twitter 拉資料。你的瀏覽器只跟 Nitter 溝通，Nitter 再用 Twitter 的非官方 API 把推文、圖片、個人檔案抓回來，渲染成不帶 JavaScript 的輕量頁面送給你。Twitter 看到的是 Nitter 伺服器的 IP 和它持有的帳號 token，看不到你的 IP 或瀏覽器指紋。官方 README 用一個數字標示輕量化程度：以 @nim_lang 這個帳號的個人頁為例，Nitter 回傳約 60KB，Twitter 原生約 784KB。這是作者自己量的數字，不是我的獨立量測，但它描繪的方向跟「砍掉 JavaScript 和廣告」的設計目標是一致的。

Nitter GitHub 倉庫 zedeus/nitter 的 README 頁面，頂部可見 session token 公告 — Nitter GitHub 倉庫（zedeus/nitter），README 頂部掛著 session token 公告

所有圖片和影片也走同一條代理管道。Twitter 的圖片網址本來長得像 pbs.twimg.com 開頭，Nitter 會把它換成自己伺服器的網址重新代理一次。你打開一張圖，請求是發給 Nitter，不是發給 Twitter 的 CDN。這代表 Twitter 無法透過圖片載入請求追蹤你的 IP，但也代表 Nitter 伺服器要扛所有流量的頻寬成本，這也是為什麼公開實例的經營者負擔不輕。

Nitter 還提供主題切換（深色、淺色、自訂），以及行動版響應式設計。README 功能列提到的這些都是前端呈現層的東西，不涉及額外的 Twitter API 呼叫。Nitter 頁面也不執行任何 JavaScript，所以理論上比 Twitter 原生頁面更難被植入惡意腳本，但代價是一些互動元素（如無限滾動載入更多推文）會用傳統的分頁取代。

這套架構的代價是，Nitter 本質上是一個唯讀的瀏覽器。你能做的是看推文、圖片、搜尋、訂閱 RSS；發推、回覆、按讚這些互動一概沒有。如果你需要的是完整的 Twitter 互動，像那些把發文和跨平台同步做在一起的Twitter 跨平台工具，Nitter 幫不上忙。它的位置是「我只想看，不想被看」。

session token 改變了一切

這是理解 2026 年 Nitter 最關鍵的一段。README 頂部掛著一行公告：「Running a Nitter instance now requires real accounts, since Twitter removed the previous methods.」意思是，Twitter 砍掉了過去讓 Nitter 免登入拉資料的管道，現在每一台 Nitter 實例都得拿一個真實 Twitter 帳號的 session token（README 指向 wiki 說明怎麼從瀏覽器 Cookie 裡取出 auth_token 和 ct0 兩個值）才能運作。

最直接的後果是，公開實例的經營者現在用自己的 Twitter 帳號替所有人扛流量，一旦 Twitter 偵測到異常並封鎖那個帳號，實例就跟著掛。連帶的是自架門檻的改變：過去裝好就能跑，現在得先有一個能登入的 Twitter 帳號，哪怕是免洗帳號。更深層的影響是這場貓抓老鼠催生了 fork 生態：多數撐下來的公開實例跑的已經不是官方 master 分支，而是經營者各自打的 fork，每個人用自己的 patch 去應對 Twitter 那一端的封鎖變化。

公開實例的真實健康度

我查的依據是 status.d420.de 這份第三方實例健康追蹤器（它在頁面上註明「不要拿這些實例來爬資料，請自己架」）。我在 2026 年 8 月 10 號看到的快照長這樣：十個被追蹤的實例裡，九個標為健康，一個（nitter.privacyredirect.com）離線。但「健康」這個標籤背後的穩定度差距很大，全部時間正常運行比例從 48% 排到 97%。

最穩的幾個是 xcancel.com（97%）、nitter.space 和 nitter.net（各 95%）。最不穩的 nitter.tiekoetter.com 只有 48%，等於一年有一半時間連不上。版本欄透露了另一層資訊：只有 catsarch.com 和 tiekoetter.com 跑的是官方最新版（2026.07.11），其餘都不是官方最新版。連 nitter.net 這個最老牌的網址跑的也是 fork（版本號 2026.07.19，比官方還新，顯示是經營者自己加了東西）。

fork 現象本身不一定是壞事。經營者在官方版本之上加的多半是帳號輪替邏輯、速率限制管理、以及 Twitter 封鎖時的自動重試。這些修改正是讓 fork 實例有時比跑官方版本的實例更穩的原因。但代價是你得多信任一層：你不只信任 Nitter 的官方程式碼，還信任那個經營者加的 patch 沒有夾帶別的東西。自架跑官方 master 分支就沒有這層不確定性，雖然你得自己面對 Twitter 封鎖時的維護。

把這些數字翻譯成你會遇到的狀況：如果你想找一個直接打開就能用的公開實例，xcancel.com 目前最穩，但沒有人保證它明天還在。公開實例的生死完全取決於經營者的帳號什麼時候被 Twitter 封，以及他願不願意繼續換帳號扛下去。

xcancel.com Nitter 公開實例瀏覽 Twitter 帳號頁面，無廣告無 JavaScript 的簡潔介面 — xcancel.com 公開實例瀏覽帳號頁面，無廣告無 JavaScript

自架需要什麼

如果你決定自己架一台，官方支援 Docker 和從原始碼編譯兩條路。Docker 路線最省事，README 提供多架構映像檔（amd64 和 arm64），拉下來改一下 nitter.conf 設定檔就能跑。這個設定檔控制的是 Nitter 的行為參數：網站標題、主題、快取時效、HmacKey（用來產生 RSS feed 的安全雜湊），以及最關鍵的 session token 檔案路徑。README 還建議在 Nitter 前面加一層反向代理（Nginx 或 Apache），處理 HTTPS 憑證和流量管理。從原始碼編譯則需要 Nim 語言編譯器、libpcre、libsass，加上一個快取服務，門檻高一些但能改的東西更多。

快取服務方面，README 建議用 Valkey 而不是 Redis，理由是 Redis 從 2024 年起把授權從 BSD 換成了雙重 RSALv2 和 SSPLv1，不再被 OSI 認可為開源軟體。Valkey 是 Linux Foundation 託管的 Redis 開源分支，Nitter 選它等於在相依性上也守住開源底線。這對自架者的實際影響不大，兩者用起來幾乎一樣，但它反映了這個專案對授權純度的態度，跟它選 AGPL-3.0 而非更寬鬆的 MIT 或 Apache 是同一條線。AGPL 特別之處在於，如果你把修改後的 Nitter 提供給網路使用者，你也有義務公開你改過的原始碼，這條條款直接堵死了「拿 Nitter 去開一個閉源的商業 Twitter 閱讀器」這條路。

不管走哪條路，你都需要準備一個 Twitter 帳號的 session token，寫進 sessions.jsonl 檔案。wiki 說明得很直白：每行放一個帳號的 auth_token 和 ct0。取得方式是登入 Twitter 網頁版後，從瀏覽器的開發者工具裡找 Cookie，把那兩個值複製出來。wiki 同時提醒，經營大型公開實例很困難，少量帳號撐不住。如果你架的是公開實例、流量大，單一帳號的 token 很快會被 Twitter 限速或封鎖，所以大型公開實例的經營者通常準備多個帳號輪替，wiki 提到的 sessions.jsonl 就是為多帳號輪替設計的。自用就簡單得多，一個帳號撐住自己看通常夠了，被封了換一個帳號重新取 token 就行。

官方資料回答不了的事

把能證明的和不能證明的分清楚，對這類隱私工具尤其重要。

我能從 GitHub API 和倉庫直接確認的是：Nitter 沒有被歸檔（archived:false），最後一次提交在 2026 年 7 月 11 號，當週還在加搜尋分類功能，13,418 顆星、753 個 fork。專案是活的，維護者 zedeus 持續在跟 Twitter 的介面變化賽跑。授權是 AGPL-3.0，README 明確寫「不允許專有實例」。它受到 Invidious（YouTube 的同類替代前端）啟發，兩個專案走的是同一條路：用開源代理伺服器把讀者跟平台的追蹤系統隔開。

我不能替它背書的是你實際用起來的體驗。我沒有自架 Nitter，所以它在你那台機器上裝好要多久、跑起來載入推文順不順、session token 多久會被 Twitter 封掉，這些我沒有資料。60KB 那個數字是作者量給的，不是我的獨立量測。公開實例的 uptime 是第三方儀表板回報的快照，隨時會變，你連上去的那一刻可能跟我在頁面上看到的已經不同。

另一個誠實的未知是 Twitter 下一步會怎麼封。README 那行「Twitter removed the previous methods」記錄的是過去的一次變化，但 Twitter 的反爬蟲策略一直在演進。今天能用的 session token 機制，明天可能又被堵住，屆時 Nitter 社群能不能跟上、要多久才能跟上，沒有人能保證。這不是 Nitter 獨有的問題，所有依賴第三方平台非官方 API 的工具都活在這種不確定性底下，但你在採用前應該知道這個風險的真實形狀。

還有一個 README 沒明說但會影響你判斷的事：Nitter 的 RSS 功能確實存在（README 功能列有寫），它讓你可以用RSS 閱讀器訂閱某個帳號的推文更新，不需要打開瀏覽器。用法很直接：在實例網址後面加上帳號名稱再加 /rss，例如 xcancel.com/elonmusk/rss 就是那個帳號推文的 feed。你也可以訂閱搜尋結果的 RSS，把搜尋關鍵字的推文持續收進閱讀器。但 RSS feed 的即時性和完整性取決於實例跟 Twitter 之間的連線狀態，實例不穩，feed 就會斷斷續續。如果你打算拿 Nitter 當穩定的監控資料源，最好自架而不是靠公開實例。

會改變你決定的幾個限制

你需要一個 Twitter 帳號的 token。不管自架還是依賴公開實例，這個 token 隨時可能被 Twitter 封鎖。公開實例的經營者扛的是所有人的風險，自架者扛的是自己的。
Nitter 是唯讀的。看推文、搜尋、RSS 都行，發推、回覆、互動不行。如果你需要完整的 Twitter 體驗，Nitter 只是閱讀端，不是替代品。
公開實例的穩定度差異極大。從 48% 到 97%，你選哪一個直接決定體驗。而即使是 97% 的那個，也隨時可能因為經營者的帳號被封而下線。
大多數公開實例跑的是 fork 而非官方版本。你看到的頁面可能是經營者自己改過的，跟官方 master 分支有出入。
沒有官方保證的隱私效果。Nitter 的設計確實讓你的瀏覽器不直接連 Twitter，但 Nitter 伺服器本身是否記錄你的請求、記多久，取決於經營者。自架是你唯一能完全掌控這一點的方式。

自己五分鐘就能查的事

不用架起來也能判斷 Nitter 在 2026 年適不適合你。先打開 status.d420.de 看一眼哪些實例現在是綠燈、各自 uptime 多少。挑一個標健康的，找一個你平常看的 Twitter 帳號，把網址裡的 twitter.com 換成那個實例的網址，直接打開。如果頁面秒開、推文完整、圖片載入正常，那它對你來說就是活的。如果連不上或一直轉圈，換一個實例再試，或者這就是告訴你該考慮自架了。

想更進一步，打開 zedeus/nitter 倉庫，翻一下 README 頂部那行 session token 公告和 wiki 的設定說明，確認你手上有沒有能用的 Twitter 帳號。都查完之後，你的判斷會很明確。

簡單的分流是這樣的：如果你只是偶爾想看幾個帳號、不在意哪天突然連不上，挑一個高 uptime 的公開實例（目前 xcancel.com 最穩）就夠了，代價是接受它隨時可能掛的風險。如果你每天都要看、或者要拿 RSS 做自動化監控，穩定度不能靠運氣，那就走自架：拉 Docker 映像檔、餵一個 token 進去、架一台完全屬於自己的 Nitter。兩條路都通，差別只在「方便」和「掌控」你要哪一邊。

GitHub 倉庫：https://github.com/zedeus/nitter

實例健康追蹤器：https://status.d420.de/