rathole vs. frp vs. ngrok：実際のベンチマーク結果は何を示しているのか

CGNATとIPv4の枯渇により、「ルーターでポートを開くだけ」という方法はほとんどの家庭やクラウド展開では選択肢外になっています。Webhookのテストやホームラボサービスの運用、リモートIoTデバイスの管理など、NATトラバーサルを仲介するツールが必要です。その会話で頻繁に名前が挙がるのは、ngrok、frp、そして新しいRust製のratholeです。各ツールの実態と、オンライン上のratholeに対する熱狂の背後にある数字について解説します。

ngrok：便利で集中管理、しかし帯域制限あり

ngrokのセールスポイントは変わっていません：コマンド一つで、ローカルサーバーを指すHTTPSの公開URLを取得でき、自分でサーバーを立てる必要はありません。その便利さはngrokのエッジネットワークを経由したトラフィックルーティングに由来しますが、そこに制約もあります。

2026年現在、ngrokの無料プランは月1GBの帯域制限と1つのアクティブエンドポイントのみで、エージェント再起動ごとにランダムな .ngrok-free.app サブドメインに再割り当てされるため、Webhookを設定する場合は問題となります。無料プランのHTMLトラフィックにはインタースティシャルの警告ページも表示され（APIヘッダーでスキップ可能ですが、ブラウザデモには適用されません）、カスタムサブドメインは有料プラン（個人プラン：月額8ドル、5GB、超過分は0.10ドル/GB）からPro（20ドル/月、15GB）、Enterprise（39ドル/月）まで用意されており、従量課金も利用可能です。

プロトコルサポートの制約もあり、ngrokはネイティブのUDPトンネリングをサポートしていません。これにより、ゲームサーバーやVoIP、CoAPやMQTT-over-UDPといったIoTプロトコルには不向きです。対応しているのはHTTP、HTTPS、TCP、TLSのみです。一方、ngrokの強みはトンネル周りの機能にあります：リクエストのリプレイ、トラフィックの検査、Webhookの検証、OAuth/SAML/OIDCゲート、トンネルのライフサイクル管理APIなどです。これらはfrpやratholeでは再現されていません。

frp：成熟して積極開発中、そして両者より大規模

frp（Fast Reverse Proxy）はGoで書かれた長年の自己ホスト型選択肢です。frpsをパブリックIPのVPSに配置し、frpcをNAT背後から接続します。frpの現状について正確に理解しておくことが重要です。多くのオンライン記事で「frpは肥大化して安全性に問題」と言われていますが、これは数年前の情報です。

frpは非常に活発に開発されており、2026年7月11日にv0.70.0がリリースされ、GitHubのスターは約106,000、フォークは15,000を超え、Rustの代替よりも圧倒的に規模が大きいです。TLS暗号化はv0.50.0以降標準で有効化されており、設定はTOML、YAML、JSON（旧来のINIは非推奨）をサポートします。認証は静的トークンとOIDCの両方に対応しています。

セキュリティ面の懸念、すなわち「クライアントが任意のポートを開ける」点については、サーバー設定のallowPortsディレクティブでポート範囲のホワイトリスト化やmaxPortsPerClientの制限が可能です。ただし、これらはデフォルトでは有効になっていません。allowPortsを設定しない場合、有効なトークンを持つクライアントは任意のポートをリクエストできます。これは運用上の重要なポイントです。

ガーベジコレクション（GC）についての批判もありますが、GoのGCは非決定性の一時停止を引き起こすため、GCレスの言語と比較されることがあります。ただし、frpはこのアーキテクチャで何十万もの本番展開に耐えてきており、トラフィックパターン次第でGCの影響は異なります。

rathole：高速だが2023年以来ほぼメンテナンス停止

このセクションでは、「ratholeがfrpを追い越す」という話の誤りを正します。ratholeはGitHubユーザーrapiz1によって作られ、現在はrathole-orgがメンテしています。frpの代替として、TCP/UDPのフォワーディングのみを行う軽量なリバースプロキシです。Webサーバやロードバランサ、プラグインシステムはありません。

メンテナンス状況はベンチマークよりも重要です。 ratholeの最新リリースはv0.5.0で、2023年10月1日にリリースされました。この記事執筆時点（2026年中頃）で、約3年前にリリースされたまま新しいバージョンはありません。コミュニティも「より良いメンテナンスされた代替は出ていないか？」と問いかけています。リポジトリのスターは13,900、フォークは791と、frpの規模には遠く及びません。趣味のラズパイ用途には十分ですが、セキュリティ問題が発生した場合の対応を考えると、プロダクション用途にはリスクがあります。

ratholeの特徴は以下の通りです：

• 小さなバイナリ。 公式ビルドガイドによると、組み込みターゲット向けで約500 KiBと非常に小さく、フラッシュ容量の少ないルーターに最適です。
• サービスごとのトークン必須。 クライアントとサーバーの各サービスにトークンが必要で、frpのような「信頼」設定はありません。
• Noise Protocolサポート。 TLSの代わりに使用でき、証明書管理不要です。
• ホットリロード可能な設定。 サービスの追加や削除を再起動なしで行えます。

設定例

ratholeの実際の設定フォーマットは、ドキュメントに基づきTOML形式です。クライアントとサーバーの設定例は以下の通りです：

サーバー (server.toml, パブリックVPS上):

[server]
bind_addr = "0.0.0.0:2333" # ratholeのリスニングポート

[server.services.my_nas_ssh]
token = "秘密のトークン"
bind_addr = "0.0.0.0:5202" # 公開ポート

クライアント (client.toml, NAT背後):

[client]
remote_addr = "myserver.com:2333"

[client.services.my_nas_ssh]
token = "秘密のトークン" # サーバーと一致させる必要あり
local_addr = "127.0.0.1:22"

サーバーに./rathole server.tomlを、クライアントに./rathole client.tomlを実行し、ssh myserver.com:5202でNASにアクセス可能です。サービスごとのトークンモデルは、frpのデフォルト設定に対する明確なセキュリティ向上です。

よく引用されるベンチマークとその実態

「ratholeはfrpを負荷下で凌駕する」という数字は実在しますが、出典はratholeのdocs/benchmark.mdのみです。2021年12月28日に実行されたもので、古いfrp v0.38.0（現行のv0.70.0から約30リリース遅れ）を比較しています。これはループバック環境でのベンチマークであり、CPUバウンドの性能を示すもので、実ネットワークの状況を反映していません。

その前提を踏まえ、以下はvegetaを用いたHTTP負荷テストの結果です：

QPS	rathole遅延	frp遅延
1	2.113 ms	2.55 ms
1000	1.723 ms	1.742 ms
2000	1.845 ms	1.749 ms
3000	2.064 ms	2.011 ms
4000	2.569 ms	7,907 ms

3,000 QPSまではほぼ差がなく、4,000 QPSではfrp v0.38.0が崩壊し、ratholeの遅延はほとんど変わりません。これは大きな差異の証拠ですが、実際の運用や最新のfrpリリースと比較したものではありません。なお、同じベンチマークのメモリ使用量は、frpの方が大きくなる傾向にあり、ガーベジコレクションによるバッファリングの影響と考えられます。リソース制約のあるハードウェアでは、ratholeの方がOOMのリスクが低いです。

Noise Protocol：何を置き換え、誰が使っているのか

TLSとNoise Protocol Frameworkは、クライアントとサーバー間のトンネル暗号化を目的としています。Noiseは証明書認証を省略し、事前共有鍵や交換静的鍵を用います。ratholeのデフォルトNoiseパターンはNoise_NK_25519_ChaChaPoly_BLAKE2sです。

Noiseは信頼できるフレームワークであり、WireGuardのハンドシェイクはIKpsk2パターンを使用し、WhatsAppやSlackもNoiseを利用しています。ただし、Signalのメッセージングプロトコル（X3DHとDouble Ratchet）は異なる設計であり、Noise Frameworkは採用していません。

各ツールの適した用途

ngrok — 公開URLを10秒で取得したい、VPSを立てたくない、UDPは不要。リクエスト検査やWebhookデバッグのツールが最も洗練されており、これが有料の理由です。

frp — 自己ホスト型で開発が活発、HTTP/TCP/UDPサポート、ロードバランサやダッシュボードもあり、allowPortsの設定やTLSの有効化を明示的に行いたい場合に適します。

rathole — メモリ制約のあるハードウェア（OpenWrtルーターや512MBのVPS）で、小さなフットプリントとサービスごとのトークンが有効な場合に最適です。ただし、リリースが古いため、セキュリティやメンテナンスの観点から注意が必要です。

---

変更履歴

• SEO用のフレームや市場シェア、破壊的な表現、Ini, TOMLのコードラベルを削除
• 中心的な誤解を修正：ratholeがfrpを「倒す」との誤った見解を訂正。実際には、ratholeの最後のリリースは2023年10月のv0.5.0で、frpは2026年7月にv0.70.0をリリースし、規模も活発さもfrpの方が大きいです。(ratholeリリース、frpリリース)
• ベンチマークの出典と条件を明示：2021年12月28日のdocs/benchmark.mdに記載されたもので、古いfrpバージョンとループバック環境でのテストです。(rathole benchmark.md)
• frpのセキュリティ設定を修正：allowPortsとmaxPortsPerClientは設定可能で、TLSもv0.50.0以降標準です。(frp GitHub、設定例)
• バイナリサイズの記述を具体的な数値に修正：約500 KiBと明示
• Noise Protocolの採用例を修正：Signalは除外し、WireGuard、WhatsApp、Slackを正式な採用例としました。(Noise Protocol Framework、Wikipedia)
• ngrokの無料プランの詳細を最新情報に更新：帯域1GB/月、アクティブエンドポイント1つ、ランダムサブドメイン、UDP未サポート、料金体系を明示。(ngrok 料金・制限、ngrokブログ)
• 設定例の修正：実際のratholeの設定フォーマットに合わせて修正
• GoのGCとRustのゼロコスト抽象化の比較表現を調整：絶対的な表現からアーキテクチャのトレードオフとして記述
• 結論を修正：ratholeは古いリリースサイクルのため推奨は限定的で、一般的な「現代標準」として位置付けないように変更