TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南

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

所有圖片和影片也走同一條代理管道。Twitter 的圖片網址本來長得像 pbs.twimg.com 開頭,Nitter 會把它換成自己伺服器的網址重新代理一次。你打開一張圖,請求是發給 Nitter,不是發給 Twitter 的 CDN。這代表 Twitter 無法透過圖片載入請求追蹤你的 IP,但也代表 Nitter 伺服器要扛所有流量的頻寬成本,這也是為什麼公開實例的經營者負擔不輕。
Nitter 還提供主題切換(深色、淺色、自訂),以及行動版響應式設計。README 功能列提到的這些都是前端呈現層的東西,不涉及額外的 Twitter API 呼叫。Nitter 頁面也不執行任何 JavaScript,所以理論上比 Twitter 原生頁面更難被植入惡意腳本,但代價是一些互動元素(如無限滾動載入更多推文)會用傳統的分頁取代。
這套架構的代價是,Nitter 本質上是一個唯讀的瀏覽器。你能做的是看推文、圖片、搜尋、訂閱 RSS;發推、回覆、按讚這些互動一概沒有。如果你需要的是完整的 Twitter 互動,像那些把發文和跨平台同步做在一起的Twitter 跨平台工具,Nitter 幫不上忙。它的位置是「我只想看,不想被看」。
這是理解 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 那一端的封鎖變化。這些 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 號換上告別聲明、撤下實例清單,上面這組數字從「現況」變成「事件前的最後觀察」。

如果你決定自己架一台,官方支援 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: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 當穩定的監控資料源,過去的建議是自架而不是靠公開實例,但在下架令把「實例」本身列為取締對象之後,自架已不再是單純的技術選擇,多了一層法律風險要自己衡量。
判斷 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/