zedeus/nitter とは何ですか？

zedeus/nitterのREADMEをもとに、バックエンド経由の閲覧、Nim・Redis・リバースプロキシ構成、AGPL-3.0の条件を確認する。

zedeus/nitter は商用利用できますか？

厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。

zedeus/nitter は今もメンテナンスされていますか？

されていません。所有者が GitHub でリポジトリをアーカイブしており、読み取り専用で今後は更新されません。

zedeus/nitter はどのプログラミング言語で書かれていますか？

主に Nim です（GitHub の言語統計による）。

NitterはJavaScriptなしの閲覧経路をどう組み立てるか

ひと目でわかる

これは何？: zedeus/nitterのREADMEをもとに、バックエンド経由の閲覧、Nim・Redis・リバースプロキシ構成、AGPL-3.0の条件を確認する。
誰に向いている？: Nitterは、JavaScriptや広告を含む元サービスの閲覧を避けたい人が、自分でインスタンスと依存サービスを管理できる場合に向く。一方、2026年8月24日のREADME注記とアーカイブ状態を踏まえると、新規の公開サービス基盤として無条件に選ぶ対象ではない。
商用利用できる？: 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
今もメンテナンスされている？: されていません。所有者が GitHub でリポジトリをアーカイブしており、読み取り専用で今後は更新されません。
何の言語で書かれている？: 主に Nim です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年8月4日 · zedeus/nitter

nitterのREADMEが定義する対象

zedeus/nitter の README はプロジェクトを「Alternative Twitter front-end」と説明しています。ここではリポジトリで確認できる事実だけを整理します。star 数やバッジは注目度の手掛かりであり、品質の証明ではありません。「Nitter」には次の説明があります。> [!NOTE] > Running a Nitter instance now requires real accounts, since Twitter removed the previous methods. \ > This does not affect users. \ > For instructions on how to obtain session tokens, see Creating session tokens.。これは範囲の説明であり、本番検証の結果ではありません。

nitterの向いている用途

README の「Nitter」にある内容から、用途が合うかを先に判断できます。Prevents Twitter from tracking your IP or JavaScript fingerprint。目的が違うなら、人気だけで採用する理由にはなりません。プロジェクト名やコマンドは原文のまま残し、一次資料へ戻って用語を確認できるようにしています。 README には次の確認可能な項目もあります。All requests go through the backend, client never talks to Twitter。初回テストの材料にはなりますが、実際の環境での確認を省略する理由にはなりません。

nitterの動作の考え方

動作の説明は「Nitter」など複数の箇所に分かれています。確認できる情報は次の通りです。Liberapay: https://liberapay.com/zedeus Patreon: https://patreon.com/nitter BTC: bc1qpqpzjkcpgluhzf7x9yqe7jfe8gpfm5v08mdr55 ETH: 0x24a0DB59A923B588c7A5EBd0dBDFDD1bCe9c4460 XMR:。書かれていない構成、性能、セキュリティを推測で補いません。導入時はディレクトリ、設定ファイル、release 履歴を確認してください。

nitterのインストールと初回起動

初回導入は README の入口から始めます。確認できるコマンドは次の通りです。

# useradd -m nitter # su nitter $ git clone https://github.com/zedeus/nitter $ cd nitter $ nimble -l build -d:danger --mm:refc $ nimble -l scss $ nimble -l md $ cp nitter.example.conf nitter.conf

実行可能なコマンドがない場合は手順を作らず、「Roadmap」で依存関係、待受ポート、初回設定を確認します。

nitterの設定と日常運用

日常運用は公式文書の範囲に限ります。「Resources」にはThe wiki contains a list of instances maintained by the community.とあります。設定、環境変数、権限、データ保存先は明記されたものだけを扱います。未記載の既定値は隔離環境で確認し、戻せる設定を保存してください。同じ資料にはUses Twitter's unofficial API (no developer account required)ともあります。

nitterのREADME で確認できる制約

制約も確認が必要です。現在の資料からは、zedeus/nitter の互換表、性能基準、サービス保証、長期サポートを確認できません。README の記載は「It's impossible to use Twitter without JavaScript enabled, and as of 2024 you need to sign up. For privacy-minded folks, preventing JavaScript analytics and IP-based tracking is important, but apart from using a VPN and uBlock/uMatrix,」です。不明点は採用記録の検証項目として残し、断定に変えないでください。

nitterのセキュリティ・プライバシー・ライセンス

ライセンスはメタデータと LICENSE に基づき、SPDX は AGPL-3.0 です。再配布や改変の条件を確認する情報であり、安全審査の代わりではありません。認証情報、公開範囲、ログ、依存ライブラリの扱いは別途確認が必要です。

nitterの保守とアップグレード

保守判断の材料は、既定ブランチ master、13391 stars、749 forks、168 件の open issue です。「Why?」にはUsing an instance of Nitter (hosted on a VPS for example), you can browse Twitter without JavaScript while retaining your privacy. In addition to respecting your privacy, Nitter is on average around 15 times lighter than Twitter, and inとあります。更新計画の参考にはなりますが、実際の upgrade テストは省略できません。保守時は README の「Why?」も確認します。In the future a simple account system will be added that lets you follow Twitter users, allowing you to have a clean chronological timeline without needing a Twitter account.。

導入時に見るべき境界は、ブラウザからXへ直接接続させず、Nitterのバックエンドが非公式APIを呼び出す点にある。`nitter.conf`ではホスト名、ポート、HMACキー、HTTPS、Redis情報を設定し、Cookieの前提と待受範囲を確認する。Dockerを使う場合も、ホスト側に先に設定ファイルを作り、`redisHost`をcompose構成に合わせる必要がある。ログはREADMEの説明ではstdout中心で、本格的なログ機構は実装されていない。公開インスタンスの一覧はコミュニティWikiに置かれるため、自分で管理するインスタンスと第三者のインスタンスを同じ信頼境界として扱わない。

READMEには、Redisをキャッシュと将来のアカウント情報に使うとあり、2024年時点でRedisの代替としてValkeyを推奨している。UbuntuやDebianでは`libsass-dev`を用意し、Nimbleでビルド、SCSS、Markdown生成を順に実行する。NginxまたはApacheのWiki設定を参照してTLS終端とバックエンドの公開範囲を分ける。systemdの例では`nitter`ユーザー、作業ディレクトリ、`Restart=always`が示されるが、サービス化しただけで障害時のデータ整合性が確保されるわけではない。アーカイブ済みリポジトリであること、READMEの法的注記が更新されていることも、導入判断の前提として記録する。

初回の確認では、トップページ、ユーザーのタイムライン、検索、RSS、レスポンシブ表示を同じインスタンスで試し、ブラウザの開発者ツールにX向けの直接リクエストが出ていないかを見る。キャッシュを有効にした場合は、Redis停止時の応答、古い内容が残る時間、再起動後の復旧を区別して記録する。READMEが平均15倍軽量、タイムラインが2〜4倍速いと述べる数値はプロジェクト側の説明であり、ネットワーク、ページ、広告状態を揃えた比較なしに再利用しない。将来計画に挙げられた埋め込み、アカウント、アーカイブ、開発者APIは、現行機能の一覧へ混ぜない。

セッションやCookieを扱う場合は、秘密情報を設定例へ書き戻さず、失効と再発行の手順を別に確認する。バックアップには設定ファイルとセッション情報を含めるか分け、公開ログに値が出ないことを確認する。障害時の復旧順序も記録する。設定変更後は再起動前後の挙動を比較する。

編集部の結論

Nitterは、JavaScriptや広告を含む元サービスの閲覧を避けたい人が、自分でインスタンスと依存サービスを管理できる場合に向く。一方、2026年8月24日のREADME注記とアーカイブ状態を踏まえると、新規の公開サービス基盤として無条件に選ぶ対象ではない。先に公式リポジトリの状態、利用可能なセッション方式、Nimのビルド、ValkeyまたはRedis、HTTPS付きリバースプロキシ、AGPL-3.0の配布条件を隔離環境で確認する。

公式情報源

コミュニティノート