Nitter 2026 還能用嗎?X 下架令後的實例現況與替代選擇

X Corp 於 2026 年 8 月 24 號對 Nitter 實例與倉庫發出下架要求,nitter.net 與 xcancel.com 等公開實例已停止服務,GitHub 倉庫同步封存。文章整理 Nitter 的隱私瀏覽架構、事件前的實例生態,以及讀推文、存影片與 RSS 監控的替代選擇。

用 AI 摘要這篇文章:

Nitter 是一個讓你在不碰 Twitter 廣告、不載入 JavaScript 的前提下瀏覽推文的開源前端,你的瀏覽器指紋也留在自己這一端,不交給 X(倉庫 zedeus/nitter,AGPL-3.0 授權)。它的賣點從 2019 年上線到 2026 年都沒變,結局卻來得突然:2026 年 8 月 24 號,X Corp 向 Nitter 實例經營者與專案倉庫寄出 cease and desist 信函,要求永久下架。維護者 zedeus 在 nitter.net 貼出停止服務聲明,GitHub 倉庫同步封存,xcancel.com 等主要公開實例也陸續關站。這篇文章整理 Nitter 的隱私瀏覽架構、事件前的實例生態,以及下架之後你還有哪些選擇;我重新查證過倉庫與各實例的即時頁面,但我沒有自己架一台 Nitter 來跑,所以載入速度、你所在網路能不能連上特定實例、session token 被封多久,這些都得你自己驗證。

若你在意的是把看到的 X 影片存進硬碟,TwitterXDownload 這類下載工具補上了 Nitter 不提供的保存功能,但它只支援公開貼文,且請求會經過站方伺服器。

若你需要的不只是單次瀏覽,而是長期、可查詢的推文資料層,可以看看可自架的 Auto Ski Info Subscribe 推文監控系統,它把抓回來的推文透過 MCP 協議暴露成結構化資料。

伺服器端代理:你從頭到尾不碰 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 頁面,2026 年 8 月中旬頂部還掛著 session token 公告Pin
Nitter GitHub 倉庫(zedeus/nitter),2026 年 8 月中旬的 README 頂部還掛著 session token 公告,倉庫封存後已換成 cease and desist 聲明

所有圖片和影片也走同一條代理管道。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 改變了一切

這是理解 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_tokenct0 兩個值)才能運作。

最直接的後果是,公開實例的經營者現在用自己的 Twitter 帳號替所有人扛流量,一旦 Twitter 偵測到異常並封鎖那個帳號,實例就跟著掛。連帶的是自架門檻的改變:過去裝好就能跑,現在得先有一個能登入的 Twitter 帳號,哪怕是免洗帳號。更深層的影響是這場貓抓老鼠催生了 fork 生態:多數撐下來的公開實例跑的已經不是官方 master 分支,而是經營者各自打的 fork,每個人用自己的 patch 去應對 Twitter 那一端的封鎖變化。這些 fork 生態在下架令後一併停擺:技術上的貓抓老鼠還沒分出勝負,法律行動先終結了整局遊戲。

公開實例的真實健康度

我查的依據是 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 已停止服務,status.d420.de 追蹤器本身也在 8 月 28 號換上告別聲明、撤下實例清單,上面這組數字從「現況」變成「事件前的最後觀察」。

xcancel.com Nitter 公開實例瀏覽 Twitter 帳號頁面(2026 年 8 月中旬截圖),無廣告無 JavaScript 的簡潔介面Pin
xcancel.com 公開實例瀏覽帳號頁面(2026 年 8 月中旬截圖),無廣告無 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_tokenct0。取得方式是登入 Twitter 網頁版後,從瀏覽器的開發者工具裡找 Cookie,把那兩個值複製出來。wiki 同時提醒,經營大型公開實例很困難,少量帳號撐不住。如果你架的是公開實例、流量大,單一帳號的 token 很快會被 Twitter 限速或封鎖,所以大型公開實例的經營者通常準備多個帳號輪替,wiki 提到的 sessions.jsonl 就是為多帳號輪替設計的。自用就簡單得多,一個帳號撐住自己看通常夠了,被封了換一個帳號重新取 token 就行。

官方資料回答不了的事

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

我能從 GitHub API 和倉庫直接確認的是:Nitter 倉庫已經封存(archived:true),最後一次提交停在 2026 年 8 月 26 號,內容是把捐款方式放回 README;星星數在最後幾天漲到 14,048 顆、1,195 個 fork。zedeus 在 nitter.net 的聲明中說自己正在尋求法律意見,開發「暫時停止」。授權是 AGPL-3.0,README 明確寫「不允許專有實例」。它受到 Invidious(YouTube 的同類替代前端)啟發,兩個專案走的是同一條路:用開源代理伺服器把讀者跟平台的追蹤系統隔開。

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

另一個原本的未知是 X 下一步會怎麼出手,2026 年 8 月 24 號有了答案:不是更嚴的技術封鎖,而是律師信。README 那行「Twitter removed the previous methods」記錄的是過去的一次技術變化,這次 X Corp 直接要求永久下架實例與倉庫。往後就算有人想用 fork 在其他網域重開,也得先面對這層法律風險;會不會有實例轉入地下繼續撐,沒有人能保證。這不是 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%,你選哪一個直接決定體驗;下架令之後,這些實例多數已直接停止服務,數字成為事件前的記錄。
  • 大多數公開實例跑的是 fork 而非官方版本。你看到的頁面可能是經營者自己改過的,跟官方 master 分支有出入。
  • 沒有官方保證的隱私效果。Nitter 的設計確實讓你的瀏覽器不直接連 Twitter,但 Nitter 伺服器本身是否記錄你的請求、記多久,取決於經營者。自架是你唯一能完全掌控這一點的方式。

自己五分鐘就能查的事

判斷 Nitter 現在還能不能用,最快的辦法仍是直接打開實例看。先連上 nitter.net 或你還記得的任何一個實例網址:如果看到的是 cease and desist 聲明頁,那個實例已經停止服務;status.d420.de 追蹤器在 8 月 28 號也換上告別聲明。GitHub wiki 上由社群維護的實例清單仍在,但每一筆都可能是下一個收到律師信的目標。把網址裡的 twitter.com 換成實例網址、看推文會不會正常渲染,這個五分鐘檢查法依然有效,只是現在多數實例連第一步都過不了。

想更進一步,打開 zedeus/nitter 倉庫(已封存但內容仍可讀),翻一下 wiki 的自架設定說明,確認你手上有沒有能用的 Twitter 帳號,以及你願不願意在可能收到律師信的風險下繼續。都查完之後,你的判斷會很明確。

事件前,分流很簡單:偶爾看幾個帳號的人挑一個高 uptime 的公開實例,每天都要看、或要拿 RSS 做自動化監控的人走自架,兩條路都通,差別只在「方便」和「掌控」。事件後這個分流失去意義:公開實例接連關站,自架則直接面對 X Corp 的法律行動。更務實的做法是把需求拆開:保存推文影片交給下載工具,長期監控交給可自架的抓取服務,跨平台發文交給同步工具;如果你要的確實是 Nitter 那種不執行 JavaScript 的隱私瀏覽,追著 zedeus 的聲明與倖存 fork 的動向走,是目前僅存的路。

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

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

官方停止服務聲明:https://nitter.net/

Sliven 褚崇名
Sliven 褚崇名

每日分享科技新知、免費資源以及 WordPress、虛擬主機相關主題,任何問題歡迎在科技月球下方留言,或是發送 Email 至 [email protected] 與我聯繫。

文章: 1303

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *


Share to...