frp v0.70、API v2移行完了と互換性戦略を正式化

小衆ソフトウェア の 青小蛙 の報道によると、オープンソースの内網穿透（NAT越え）ツール「frp」がv0.70へアップデートされた。本バージョンではfrps（サーバー側）のDashboard API v2移行が完了し、WebSocket/WSSの互換性向上やProxy Protocolのバグ修正が行われている。また、v0.69で初めて規定されたバージョン互換性ポリシーも併せて公開されており、長期運用を視野に入れた安定化の方向性が明確になった。

v0.70の主要更新

本リリースの最大のトピックは、frps Dashboard APIのv2への完全移行である。具体的には、クライアント概要、プロキシ一覧、サーバー概要、クライアント詳細、プロキシ詳細といった各モジュールが新規追加または改善された。ページネーション・検索・プロキシタイプによるフィルタリングに加え、プロキシトラフィック履歴やサーバーシステム情報の取得にも対応している。これにより、frpの運用管理を外部ツールやAPI経由で行うための基盤が整った。

WebSocket/WSSに関しては、Binary Frame送信方式に変更された。小衆ソフトウェアの記事では、CloudflareやNginxなどリバースプロキシ背後での互換性が向上し、UTF-8チェックによる予期せぬ接続切断が防止されたと説明されている。プロキシ環境下でfrpを利用するユーザーにとって実用上の改善となる。

Proxy Protocolについては、tls2rawプラグインにおいてProxy Protocol有効時にヘッダーが正しく書き込まれない問題が修正された。また、設定チェックの強化として、同一設定内に重複するProxy名やVisitor名が存在する場合、従来は黙って上書きされていた動作がエラー出力に変更されている。これは設定ミスを早期に検出できるようにするための仕様変更であり、誤動作を未然に防ぐ効果が期待される。

互換性ポリシーの新設

v0.69で導入された互換性ポリシーは、frpの長期運用を支える重要な枠組みである。公式は、特定バージョンのfrpcとfrpsの間で相互互換を保証する範囲を明示した。例えば、frpc v0.69はv0.61からv0.77までのfrpsと相互互換であり、逆も同様とされる。この範囲を超えた場合、互換性は保証されないものの多くのケースでは正常に動作する可能性があるとされている。

ハイブリッドバージョン環境でアップグレードを行う場合は、frps（サーバー側）を先にアップグレードし、その後frpc（クライアント側）をアップグレードする手順が推奨されている。これにより、サーバーが新しいクライアントのプロトコル動作を事前にサポートできるようになり、アップグレードプロセスがよりスムーズになると説明されている。frpはサーバーとクライアントが別個に更新されることが多いツールであり、このポリシーは実運用において大きな意味を持つ。

永続ストレージとAPI機能

v0.68で導入された永続ストレージ機能は、frpcクライアント設定に [store] セクションを追加することで有効になる。設定内容が db.json ファイルに保存され、frpcの再起動後も状態が維持される。ただし、webServer も同時に有効にしないとAPI機能は利用できない点に注意が必要だ。

API機能を活用すると、curlコマンドなどで動的にプロキシの追加・変更・削除が可能になり、frpcの再起動を必要としない。小衆ソフトウェアの青小蛙は、このAPI機能を「AI向けに用意された」と表現しており、エージェントによる動的なトンネル管理を想定していることがうかがえる。

具体的な使用例として、以下のようなcurlコマンドが紹介されている。ターミナルからプロキシを追加する場合：

curl -u appinn:appinnadmin http://192.168.1.111:7500/api/store/proxies \
-H "Content-Type: application/json" \
-d '{ "name": "openclaw", "type": "tcp", "tcp": { "localPort": 17321, "remotePort": 47321 } }'

プロキシの変更はPUTメソッド、削除はDELETEメソッドで行う。全プロキシの照会はGETメソッドで行える。これらAPI操作により、frpの動的な設定管理が実現されている。

tokenSourceとセキュリティ強化

v0.64.0では、認証トークンをファイルから読み込む tokenSource 機能が追加された。従来のように設定ファイルに平文でトークンを記述する必要がなくなり、設定ファイルの露出リスクを低減できる。具体的な設定例として、frps.toml 内で以下のように記述する：

auth.tokenSource.type = "file"
auth.tokenSource.file.path = "/etc/frp/token"

トークンファイルにはカスタムキーを記述し、frp同士の接続認証に利用する。この変更により、Gitなどで設定ファイルを管理する際に認証情報を誤って公開するリスクが軽減される。

編集部の見解

短期的な影響として、v0.70のDashboard API v2移行完了により、frpの運用管理を外部からのAPI経由で行う基盤が整った点が挙げられる。既存の監視ツールやCI/CDパイプラインとの統合が容易になり、特に複数のfrpノードを管理する組織にとって実務上の負担軽減につながると見る。また、WebSocket/WSSの互換性向上は、CloudflareやNginxといったリバースプロキシ背面での導入を促進する可能性がある。 長期的な視点では、公式が互換性ポリシーを明文化したことはfrpのエンタープライズ導入において重要な一歩と評価できる。バージョン間の動作保証範囲が明確になったことで、アップグレード計画を立てやすくなり、長期運用が求められるプロダクション環境での採用が進む可能性がある。また、永続ストレージとAPI機能の拡充は、frpを単なるトンネリングツールから設定管理プラットフォームへと進化させる方向性を示している。AIエージェントとの統合を意識した設計は、今後のネットワーク自動化の流れと合致していると言えそうだ。

参考

• 「frp v0.70：开源内网穿透工具教程，完善 API、规定兼容性策略」, by 青小蛙 — 小众软件, 2026-07-12T08:50:38.000Z (ARR)
• 元記事URL: https://www.appinn.com/frp/