セルフホスト型サービス
fatedier/frp avatar
fatedier/frp

frpでNATの内側にあるサービスを外部へ中継する

NAT またはファイアウォールの背後にあるローカル サーバーをインターネットに公開するのに役立つ高速リバース プロキシ。

スター 109,449フォーク 15,214GoApache-2.0
GitHub

ひと目でわかる

これは何?
fatedier/frpは、公開側のfrpsと内側のfrpcでトンネルを構成し、TCP、UDP、HTTP、HTTPSの通信をローカルサービスへ転送するGo製リバースプロキシです。
誰に向いている?
frpは、NATやファイアウォールの内側にあるSSH、Web、DNSなどを、公開側のfrpsを経由して到達させたい運用者向けです。READMEはfrpsとfrpcの役割、複数の転送方式、認証、TLS、ポート制限、ヘルスチェックを具体的に示していますが、公開設定を安全に設計する責任は利用者に残ります。
商用利用できる?
できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 1 日前です。
何の言語で書かれている?
主に Go です(GitHub の言語統計による)。

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

オープンソース詳細解説

frpsとfrpcで外向き接続を利用する

frpは、公開IPを持つサーバーとNATまたはファイアウォール内のマシンをつなぐGo製リバースプロキシです。frpsはサーバー側で待ち受け、frpcは内側からfrpsへ外向き接続を確立します。公開側で受けた通信は、その接続を通ってクライアント側のローカルサービスへ転送されます。

READMEはfrpを高速と表現していますが、素材にベンチマーク結果はありません。スターやフォークの多さも転送性能の証拠にはなりません。採用時は、公開側のポート、内側の宛先、接続断時の挙動、ログに残る情報を実測し、形容詞ではなく自分の通信条件で判断してください。

TCPからP2Pまで用途で方式を選ぶ

READMEによると、frpはTCP、UDP、HTTP、HTTPSに対応し、HTTPとHTTPSではドメイン名で内部サービスへリクエストを転送できます。LAN内のSSH、カスタムドメインのWeb、DNS問い合わせ、Unixドメインソケット、静的ファイル配信など、複数の例が用意されています。stcpは共有鍵を持つクライアントだけへ非公開でサービスを見せる方式です。

xtcpはP2P接続モードで、調整のためのfrpsを残しながらクライアント間の直接転送を試みます。READMEはすべてのNAT機器で動くとは限らず、失敗時はstcpへのフォールバックを提案しています。P2Pを選べば必ず経路が短くなるとは考えず、remotePortを使わない設定とbindAddr、bindPortの関係をテストしてください。

TOML、YAML、JSONへ移行する設定面

v0.52.0以降、frpはTOML、YAML、JSONの設定ファイルを受け付けます。INIは非推奨で、将来の版で削除予定とREADMEにあります。サンプルはTOML中心で、Goテンプレート構文を使い、.Envsプレフィックスから環境変数を参照できます。プロキシ定義を別ファイルへ分け、メイン設定のincludesで取り込む構成も示されています。

READMEのfrpsとfrpcの完全な例は参考用で、直接実行するものではないと注意されています。設定を流用するなら、公開ポート、認証、TLS、allowPorts、ログ出力、管理画面を自分の環境へ置き換え、verifyで確認できる経路を作ってください。秘密値を設定ファイルやリポジトリへ平文で保存しないことも、方式選択と同じくらい重要です。

認証、TLS、公開ポートを三段で絞る

frpcとfrpsの認証には、標準のtoken方式とOIDCのClient Credentials Grantが使えます。追加スコープを設定すれば、ハートビートや新しいワーク接続ごとに認証を適用できます。TLSはv0.50.0以降デフォルトで有効で、frpsのtransport.tls.forceをtrueにするとTLS接続だけを受け付けます。

プロキシ単位の暗号化と圧縮は利用できますが、デフォルトではオフです。HTTPサービスはhttpUserとhttpPasswordでBasic Authを要求でき、サーバー側のallowPortsで公開可能なポートを制限できます。認証があるから公開範囲も安全だとは限らないため、到達元、管理画面、バックエンドの認証を別々に点検してください。

多重化、KCP、QUIC、負荷分散の選択

frpsとfrpc間のチャネルはTCP、KCP、QUICから選べます。READMEはKCPについて、平均レイテンシが30から40パーセント減り、最大遅延が三分の一になる一方、TCPより帯域を10から20パーセント多く使うというトレードオフを記載しています。これはREADMEの説明であり、利用環境での測定値ではありません。

TCPストリーム多重化、コネクションプール、ロードバランシング、TCPまたはHTTPのヘルスチェックも用意されています。短い接続が多い場合はプールが候補になりますが、障害時にどのプロキシへ振られるか、失敗回数でいつ除外されるかを確認してください。方式を増やすほど設定の組み合わせも増えるため、必要な機能だけを有効にする方が切り分けやすくなります。

管理画面、メトリクス、実験機能を分離する

frpsは設定したポートでダッシュボードを公開し、状態とプロキシ統計を表示できます。frpcには管理UIとStoreによる動的プロキシ管理があり、Web UIやAPIで作ったプロキシとビジターをファイルへ保存して再起動後に復元できます。Prometheusを有効にすると、ダッシュボードポートのmetricsパスでメトリクスを提供します。

frpcのreloadとverifyは、設定のホットリロードと検証に使えます。フィーチャーゲートにはALPHA段階のVirtualNetがあり、TUNインターフェースでIPレベルのルーティングを行います。v0.53.0のSSHトンネルゲートウェイもREADMEに登場します。管理面や実験機能をインターネットへ無防備に置かず、運用ネットワークと転送先を分けて確認してください。

開発中のv1と互換性のないv2

素材のメタデータでは、既定ブランチはdev、スターは109084、フォークは15214、オープンIssueは52件です。READMEはmasterを最新リリース、devを開発中の版として説明し、v2は大きなリファクタリングとして計画されています。v2はv1と互換性がなく、開発時間の制約から現行版の改善を続ける方針も示されています。

ライセンスはApache-2.0で、複製、派生物の作成、配布に関する権利を認めます。ライセンス本文はサポートや保証、セキュリティ更新の義務を約束しません。編集部の判断では、frpは細かいネットワーク要件を自分で管理できる運用者向けです。採用前に設定をバージョン管理し、v1の更新、ロールバック、将来の非互換移行を別々の計画として記録してください。

編集部の結論

frpは、NATやファイアウォールの内側にあるSSH、Web、DNSなどを、公開側のfrpsを経由して到達させたい運用者向けです。READMEはfrpsとfrpcの役割、複数の転送方式、認証、TLS、ポート制限、ヘルスチェックを具体的に示していますが、公開設定を安全に設計する責任は利用者に残ります。まず許可ポートと認証を絞った小さなサービスで試し、設定の検証、ログ、停止手順、v1から将来のv2への非互換性を確認してください。

公式情報源

  1. Official README
  2. Project repository
  3. Release notes
コミュニティノート

コミュニティノート