FRP
0.61.0
お読みください | 中文档
frp はオープンソース プロジェクトであり、継続的な開発はすべて素晴らしいスポンサーのサポートによって可能になっています。参加したい方は、frpの開発スポンサーになることをご検討ください。
frp は、NAT またはファイアウォールの背後にあるローカル サーバーをインターネットに公開できる高速リバース プロキシです。現在、 TCPおよびUDPに加えてHTTPおよびHTTPSプロトコルもサポートされており、ドメイン名を介してリクエストを内部サービスに転送できるようになります。
frp は P2P 接続モードも提供します。
開発状況
V2について
建築
使用例
SSH経由でLANネットワーク内のコンピュータにアクセスします
同じポートを共有する複数の SSH サービス
LAN 内のカスタム ドメインを使用した内部 Web サービスへのアクセス
DNSクエリリクエストを転送する
Unix ドメインソケットの転送
単純な HTTP ファイル サーバーを公開する
ローカル HTTP(S) サービスの HTTPS を有効にする
サービスをプライベートに公開する
P2Pモード
特徴
HTTP X-Forwarded-For
プロキシプロトコル
プロキシごとに
TLS
トークン認証
OIDC認証
プロメテウス
設定ファイル
環境変数の使用
構成を異なるファイルに分割する
サーバーダッシュボード
クライアント管理UI
モニター
クライアントの認証
暗号化と圧縮
frpc 設定のホットリロード
クライアントからプロキシステータスを取得する
サーバー上の特定のポートのみを許可する
ポートの再利用
帯域幅制限
TCPストリーム多重化
KCPプロトコルをサポート
QUICプロトコルをサポート
接続プーリング
負荷分散
サービスヘルスチェック
HTTPホストヘッダーの書き換え
その他のHTTPヘッダーの設定
本物のIPを取得する
Web サービスに HTTP 基本認証 (パスワード) を要求する
カスタムサブドメイン名
URLルーティング
TCPポート多重化
PROXY 経由で FRPS に接続する
ポート範囲マッピング
クライアントプラグイン
サーバー管理プラグイン
SSHトンネルゲートウェイ
関連プロジェクト
貢献する
寄付
GitHub スポンサー
ペイパル
FRPは現在開発中です。 masterブランチで最新リリース バージョンを試すことも、 devブランチを使用して現在開発中のバージョンにアクセスすることもできます。
現在、バージョン 2 に取り組んでおり、コードのリファクタリングと改善を試みています。ただし、バージョン1とは互換性がありませんのでご注意ください。
適切な時期にバージョン 0 からバージョン 1 に移行し、大きな機能のリクエストではなく、バグの修正と改善のみを受け付けます。
v2 バージョンの複雑さと難易度は予想よりもはるかに高くなっています。断片的な時間帯でしか開発に取り組むことができず、頻繁に中断されると生産性が大幅に低下します。この状況を考慮して、メジャー バージョンのオーバーホールを進めるための自由な時間ができるまで、現在のバージョンの最適化と反復を継続します。
v2 の背後にあるコンセプトは、クラウド ネイティブ ドメイン、特に K8s と ServiceMesh における私の長年の経験と考察に基づいています。そのコアは、envoy に似た、最新化された 4 層および 7 層のプロキシです。このプロキシ自体は拡張性が高く、イントラネット侵入の機能を実装できるだけでなく、他のさまざまなドメインにも適用できます。この拡張性の高いコアを基盤として、frp v1 のすべての機能を実装するとともに、以前は達成できなかった、または実装が困難だった機能にもエレガントな方法で対処することを目指しています。さらに、効率的な開発と反復能力を維持します。
さらに、K8s をベースにさまざまな拡張機能を提供できるように、frp 自体が拡張性の高いシステムおよびプラットフォームになることを想像しています。 K8sでは、CRD、コントローラーモード、Webhook、CSI、CNIなどの機能を活用し、企業のニーズに合わせて開発をカスタマイズできます。 frp v1 では、サーバー プラグインの概念を導入し、いくつかの基本的な拡張性を実装しました。ただし、単純な HTTP プロトコルに依存しているため、ユーザーは独立したプロセスを開始して独自に管理する必要があります。このアプローチは柔軟性や便利とは程遠く、実際の需要は大きく異なります。少数の個人によって維持されている非営利のオープンソース プロジェクトが全員のニーズを満たすことを期待するのは非現実的です。
最後に、構成管理、権限検証、証明書管理、API 管理などのモジュールの現在の設計が十分に最新ではないことを認めます。 v1 バージョンではいくつかの最適化を実行する可能性がありますが、互換性の確保は依然として困難な問題であり、対処するには多大な労力が必要です。
今後ともfrpをよろしくお願いいたします。
まず、リリース ページからオペレーティング システムとアーキテクチャに対応した最新のプログラムをダウンロードします。
次に、 frpsバイナリとサーバー構成ファイルを、パブリック IP アドレスを持つサーバー A に配置します。
最後に、 frpcバイナリとクライアント構成ファイルをサーバー B に配置します。サーバー B は、パブリック インターネットから直接アクセスできない LAN 上にあります。
一部のウイルス対策ソフトは、frpc を不正にマルウェアとしてマークし、削除します。これは、frp がリバース プロキシを作成できるネットワーク ツールであるためです。ウイルス対策ソフトは、ファイアウォールのポート制限をバイパスする機能があるため、リバース プロキシにフラグを立てることがあります。ウイルス対策を使用している場合は、誤って隔離/削除されないように、ウイルス対策設定で frpc をホワイトリストに登録/除外する必要がある場合があります。詳細については、問題 3637 を参照してください。
frp クライアントの接続先のbindPort設定して、サーバー A のfrps.toml変更します。
# frps.tomlbindPort = 7000
サーバー A でfrps開始します。
./frps -c ./frps.toml
サーバー B のfrpc.toml変更し、 serverAddrフィールドを frps サーバーのパブリック IP アドレスに設定します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
localPort (クライアント上でリッスンされる) とremotePort (サーバー上で公開される) は FRP システムに出入りするトラフィックに使用され、 serverPortは FRPS と FRPC 間の通信に使用されることに注意してください。
サーバー B でfrpc開始します。
./frpc -c ./frpc.toml
SSH 経由でサーバー A を介して別のマシンからサーバー B にアクセスするには (ユーザー名がtestあると仮定します)、次のコマンドを使用します。
ssh -oPort=6000 test@xxxx
この例では、tcpmux タイプのプロキシを使用して、同じポートを介して公開される複数の SSH サービスを実装します。同様に、クライアントが HTTP Connect プロキシ接続方法をサポートしている限り、この方法でポートの再利用を実現できます。
パブリック IP を持つマシンに frps を展開し、frps.toml ファイルを変更します。簡略化した構成は次のとおりです。
バインドポート = 7000tcpmuxHTTPConnectポート = 5002
次の構成で内部マシン A に frpc をデプロイします。
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh1"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-a.example.com"]localIP = "127.0.0.1"localPort = 22
次の構成で別の frpc を内部マシン B にデプロイします。
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh2"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-b.example.com"]localIP = "127.0.0.1"localPort = 22
ユーザー名が「test」であると仮定して、SSH ProxyCommand を使用して内部マシン A にアクセスするには、次のようにします。
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
内部マシン B にアクセスするには、ユーザー名が「test」であると仮定すると、唯一の違いはドメイン名です。
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
場合によっては、テスト目的で独自のドメイン名を使用して、NAT ネットワークの背後にあるローカル Web サービスを他のユーザーに公開する必要があります。
残念ながら、ドメイン名をローカル IP に解決することはできません。ただし、frp を使用して HTTP(S) サービスを公開することはできます。
frps.toml変更し、vhost の HTTP ポートを 8080 に設定します。
# frps.tomlbindPort = 7000vhostHTTPPort = 8080
https プロキシを設定する場合は、 vhostHTTPSPort設定する必要があります。
frpsを開始します。
./frps -c ./frps.toml
frpc.toml変更し、 serverAddrリモート frps サーバーの IP アドレスに設定します。 Web サービスのlocalPort指定します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["www.example.com"]
frpcを開始します。
./frpc -c ./frpc.toml
www.example.comの A レコードを、リモート frps サーバーのパブリック IP または元のドメインを指す CNAME レコードにマッピングします。
URL http://www.example.com:8080を使用してローカル Web サービスにアクセスします。
frps.tomlを変更します。
# frps.tomlbindPort = 7000
frpsを開始します。
./frps -c ./frps.toml
frpc.toml変更し、 serverAddrリモート frps サーバーの IP アドレスに設定します。 DNS クエリ リクエストを Google パブリック DNS サーバー8.8.8.8:53に転送します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "dns"type = "udp"localIP = "8.8.8.8"localPort = 53remotePort = 6000
frpc を開始します。
./frpc -c ./frpc.toml
digコマンドを使用して DNS 解決をテストします。
dig @xxxx -p 6000 www.google.com
Unix ドメイン ソケット (Docker デーモン ソケットなど) を TCP として公開します。
上記のようにfrpsを設定します。
次の構成でfrpc開始します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "unix_domain_socket"type = "tcp"remotePort = 6000[proxies.plugin]type = "unix_domain_socket"unixPath = "/var/run/docker.sock 」
curl使用して Docker バージョンを取得し、構成をテストします。
curl http://xxxx:6000/version
シンプルな HTTP ファイル サーバーを公開して、パブリック インターネットから LAN に保存されているファイルにアクセスします。
上記のようにfrpsを設定し、次のようにします。
次の構成でfrpc開始します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "test_static_file"type = "tcp"remotePort = 6000[proxies.plugin]type = "static_file"localPath = "/tmp/files"stripPrefix = " static"httpUser = "abc"httpPassword = "abc"
ブラウザからhttp://xxxx:6000/static/にアクセスし、正しいユーザー名とパスワードを指定して、 frpcマシン上の/tmp/files内のファイルを表示します。
プラグインをhttps2httpsに置き換えて、 localAddr HTTPS エンドポイントを指すようにすることもできます。
次の構成でfrpc開始します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "test_https2http"type = "https"customDomains = ["test.example.com"] [proxies.plugin]type = "https2http"localAddr = "127.0.0.1:80"crtPath = "./server.crt"keyPath = "./server.key"hostHeaderRewrite = "127.0.0.1"requestHeaders.set.x-どこから = "FRP"
https://test.example.comにアクセスしてください。
特定のサービスをパブリック ネットワークに直接公開することに関連するリスクを軽減するために、STCP (シークレット TCP) モードでは、他のクライアントからサービスへのアクセスに事前共有キーを使用する必要があります。
上記と同じようにfrpsを設定します。
次の構成を使用してマシン B でfrpc開始します。この例は SSH サービス (ポート 22) を公開するためのもので、事前共有キーのsecretKeyフィールドと、 remotePortフィールドがここで削除されていることに注意してください。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "secret_ssh"type = "stcp"secretKey = "abcdefg"localIP = "127.0.0.1"localPort = 22
次の構成を使用して別のfrpc (通常は別のマシン C) を起動し、セキュリティ キー ( secretKeyフィールド) を使用して SSH サービスにアクセスします。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[visitors]]name = "secret_ssh_visitor"type = "stcp"serverName = "secret_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000
マシン C で、次のコマンドを使用してマシン B の SSH に接続します。
ssh -oPort=6000 127.0.0.1
xtcpは、クライアント間で大量のデータを直接送信するように設計されています。ここでの P2P は実際のデータ送信のみを指すため、frps サーバーは依然として必要です。
すべてのタイプの NAT デバイスで動作するとは限らないことに注意してください。 xtcp が機能しない場合は、stcp にフォールバックすることもできます。
マシン B でfrpc起動し、SSH ポートを公開します。 remotePortフィールドが削除されていることに注意してください。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# デフォルトのサーバーが利用できない場合は、新しいスタンサーバーをセットアップします。# natHoleStunServer = "xxx"[[proxies]]name = "p2p_ssh"type = "xtcp"secretKey = " abcdefg"localIP = "127.0.0.1"localPort = 22
P2P モードを使用して SSH に接続する構成で別のfrpc (通常は別のマシン C) を起動します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# デフォルトのサーバーが利用できない場合は、新しいスタンサーバーをセットアップします。# natHoleStunServer = "xxx"[[visitors]]name = "p2p_ssh_visitor"type = "xtcp"serverName = " p2p_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000# 自動トンネル永続化が必要な場合は、truekeepTunnelOpen = false に設定します。
マシン C で、次のコマンドを使用してマシン B の SSH に接続します。
ssh -oPort=6000 127.0.0.1
v0.52.0 以降、構成用に TOML、YAML、および JSON がサポートされています。 INI は非推奨であり、将来のリリースでは削除される予定であることに注意してください。新機能は TOML、YAML、または JSON でのみ使用できます。これらの新機能を必要とするユーザーは、それに応じて設定形式を切り替える必要があります。
ここで説明されていないさらに多くの機能については、構成ファイルの完全な例を読んでください。
例では TOML 形式を使用していますが、YAML または JSON も使用できます。
これらの構成ファイルは参照のみを目的としています。さまざまな問題が発生する可能性があるため、この構成を直接使用してプログラムを実行しないでください。
frps の完全な設定ファイル (サーバー)
frpc (クライアント) の完全な構成ファイル
環境変数は、Go の標準形式を使用して構成ファイル内で参照できます。
# frpc.tomlserverAddr = "{{ .Envs.FRP_SERVER_ADDR }}"serverPort = 7000[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = "{{ .Envs. FRP_SSH_REMOTE_PORT }}"上記の設定を使用すると、次のように変数をfrpcプログラムに渡すことができます。
export FRP_SERVER_ADDR=x.x.x.x export FRP_SSH_REMOTE_PORT=6000 ./frpc -c ./frpc.toml
frpc OS 環境変数を使用して構成ファイル テンプレートをレンダリングします。参照の前に.Envsを付けることを忘れないでください。
複数のプロキシ構成を異なるファイルに分割し、メイン ファイルに含めることができます。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000includes = ["./confd/*.toml"]
# ./confd/test.toml[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
FRPのステータスやプロキシの統計情報をダッシュボードで確認できます。
この機能を有効にするには、ダッシュボードのポートを構成します。
# デフォルト値は 127.0.0.1 です。パブリック ネットワークからアクセスする場合は、0.0.0.0 に変更します。webServer.addr = "0.0.0.0"webServer.port = 7500# ダッシュボードのユーザー名とパスワードは両方ともオプションですwebServer.user = "admin"webServer.password = "管理者」
次に、 http://[serverAddr]:7500にアクセスしてダッシュボードを表示します。ユーザー名とパスワードは両方ともadminです。
さらに、ドメインのワイルドカードまたは通常の SSL 証明書を使用して HTTPS ポートを使用できます。
webServer.port = 7500# ダッシュボードのユーザー名とパスワードは両方ともオプションですwebServer.user = "admin"webServer.password = "admin"webServer.tls.certFile = "server.crt"webServer.tls.keyFile = "server.key"
次に、 https://[serverAddr]:7500にアクセスして、安全な HTTPS 接続でダッシュボードを表示します。ユーザー名とパスワードは両方ともadminです。
クライアント管理 UI は、frpc の設定を確認および管理するのに役立ちます。
この機能を有効にするには、管理 UI のアドレスを構成します。
webServer.addr = "127.0.0.1"webServer.port = 7400webServer.user = "admin"webServer.password = "admin"
次に、 http://127.0.0.1:7400にアクセスして、ユーザー名とパスワードが両方ともadminである管理 UI を表示します。
Web サーバーが有効になっている場合、frps はモニター データを 7 日間キャッシュに保存します。プロセスの再起動後にクリアされます。
プロメテウスもサポートされています。
まずダッシュボードを有効にしてから、 frps.tomlでenablePrometheus = trueを構成します。
http://{dashboard_addr}/metrics prometheus モニター データを提供します。
frpsでfrpcを認証するには2つの認証方法があります。
どちらを使用するかを決定するには、 frpc.tomlおよびfrps.tomlでauth.methodを構成します。デフォルトのメソッドは token です。
auth.additionalScopes = ["HeartBeats"]を設定すると、設定された認証方法を使用して、frpc と frps の間のすべてのハートビートで認証を追加および検証します。
auth.additionalScopes = ["NewWorkConns"]を設定すると、frpc と frps の間のすべての新しい作業接続に対して同じことが行われます。
frpc.tomlおよびfrps.tomlでauth.method = "token"を指定すると、トークンベースの認証が使用されます。
frps 検証に合格するには、frpc のfrps.tomlとfrpc.tomlで同じauth.tokenを指定してください。
frpc.tomlおよびfrps.tomlでauth.method = "oidc"を指定すると、OIDC ベースの認証が使用されます。
OIDC は OpenID Connect の略で、使用されるフローは Client Credentials Grant と呼ばれます。
この認証タイプを使用するには、 frpc.tomlとfrps.tomlを次のように構成します。
# frps.tomlauth.method = "oidc"auth.oidc.issuer = "https://example-oidc-issuer.com/"auth.oidc.audience = "https://oidc-audience.com/.default"
# frpc.tomlauth.method = "oidc"auth.oidc.clientID = "98692467-37de-409a-9fac-bb2585826f18" # OIDC クライアント IDauth.oidc.clientSecret = "oidc_secret"auth.oidc.audience = "https: //oidc-audience.com/.default"auth.oidc.tokenEndpointURL = "https://example-oidc-endpoint.com/oauth2/v2.0/token"
この機能はデフォルトではオフになっています。暗号化や圧縮をオンにできます。
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.useEncryption = truetransport.useCompression = true
v0.50.0 以降、 transport.tls.enableおよびtransport.tls.disableCustomTLSFirstByteのデフォルト値が true に変更され、tls はデフォルトで有効になります。
ポート多重化の場合、frp は最初のバイト0x17を送信して TLS 接続をダイヤルします。これは、 transport.tls.disableCustomTLSFirstByte false に設定した場合にのみ有効になります。
frps TLS 接続のみを受け入れるように強制するには、 frps.tomlでtransport.tls.force = trueを構成します。これはオプションです。
frpc TLS 設定:
Transport.tls.enable = truetransport.tls.certFile = "certificate.crt"transport.tls.keyFile = "certificate.key"transport.tls.trustedCaFile = "ca.crt"
frps TLS 設定:
Transport.tls.force = truetransport.tls.certFile = "certificate.crt"transport.tls.keyFile = "certificate.key"transport.tls.trustedCaFile = "ca.crt"
ルート CA 証明書と少なくとも 1 つの SSL/TLS 証明書が必要です。自己署名または通常の証明書 (Let's Encrypt または別の SSL/TLS 証明書プロバイダーなど) を使用できます。
ホスト名ではなく IP アドレス経由でfrp使用する場合は、SSL/TLS 証明書を生成するときに、必ずサブジェクト代替名 (SAN) 領域に適切な IP アドレスを設定してください。
例を挙げてみましょう:
openssl設定ファイルを準備します。これは、Linux システムでは/etc/pki/tls/openssl.cnfでは/System/Library/OpenSSL/openssl.cnfに存在し、 cp /etc/pki/tls/openssl.cnf ./my-openssl.cnf 。そうでない場合は、次のように自分で構築できます。
cat > my-openssl.cnf << EOF [ ca ] default_ca = CA_default [ CA_default ] x509_extensions = usr_cert [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = utf8only [ req_distinguished_name ] [ req_attributes ] [ usr_cert ] basicConstraints = CA:FALSE nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:true EOF
ca 証明書を構築します。
openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=example.ca.com" -days 5000 -out ca.crt
FRPS 証明書を構築します。
openssl genrsa -out server.key 2048 openssl req -new -sha256 -key server.key -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=server.com" -reqexts SAN -config <(cat my-openssl.cnf <(printf "n[SAN]nsubjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com")) -out server.csr openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com") -out server.crt
frpc 証明書を構築する：
openssl genrsa -out client.key 2048 openssl req -new -sha256 -key client.key -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=client.com" -reqexts SAN -config <(cat my-openssl.cnf <(printf "n[SAN]nsubjectAltName=DNS:client.com,DNS:example.client.com")) -out client.csr openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile <(printf "subjectAltName=DNS:client.com,DNS:example.client.com") -out client.crt
HTTP API を有効にするには、 webServerフィールドが必要です。
# frpc.tomlwebServer.addr = "127.0.0.1"webServer.port = 7400
次に、コマンドfrpc reload -c ./frpc.tomlを実行し、 frpcプロキシを作成、更新、または削除するまで約 10 秒待ちます。
グローバル クライアント パラメータは「start」以外は変更されないことに注意してください。
リロードする前にコマンドfrpc verify -c ./frpc.toml実行して、構成エラーがあるかどうかを確認できます。
すべてのプロキシのステータスを取得するには、 frpc status -c ./frpc.tomlを使用します。 webServerフィールドは、HTTP API を有効にするために必要です。
frps.tomlのallowPorts 、ポートの乱用を避けるために使用されます。
# frps.tomlallowPorts = [
{ 開始 = 2000、終了 = 3000 }、
{ シングル = 3001 }、
{ シングル = 3003 }、
{ 開始 = 4000、終了 = 50000 }
】frps のvhostHTTPPortとvhostHTTPSPortは、 bindPortで同じポートを使用できます。 frps は接続のプロトコルを検出し、それに応じて処理します。
注意する必要があるのは、 vhostHTTPSPortとbindPort同じポートに設定する場合は、最初にtransport.tls.disableCustomTLSFirstByte false に設定する必要があることです。
将来的には、複数のプロキシが異なるプロトコルを使用して同じリモート ポートをバインドできるようにしたいと考えています。
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.bandwidthLimit = "1MB"
この機能を有効にするには、各プロキシの設定でtransport.bandwidthLimit設定します。サポートされている単位はMBとKBです。
クライアントまたはサーバー側で帯域幅を制限するには、 transport.bandwidthLimitMode clientまたはserverに設定します。デフォルトはclientです。
frp は v0.10.0 以降、HTTP2 多重化と同様に tcp ストリーム多重化をサポートしています。この場合、同じ frpc へのすべてのロジック接続は同じ TCP 接続に多重化されます。
この機能を無効にするには、 frps.tomlとfrpc.toml変更します。
# frps.toml と frpc.toml は同じである必要がありますtransport.tcpMux = false
KCP は、10% ～ 20% 多くの帯域幅を浪費しながら、平均遅延を 30% ～ 40% 削減し、最大遅延を 3 分の 1 に削減するという送信効果を達成できる、高速で信頼性の高いプロトコルです。 TCPよりも。
KCP モードは、基礎となるトランスポートとして UDP を使用します。 FRP での KCP の使用:
FRPS で KCP を有効にします。
# frps.tomlbindPort = 7000# KCP.kcpBindPort = 7000 の UDP ポートを指定します
bindPortフィールドは TCP ポートを指定するため、 kcpBindPort番号はbindPortと同じ番号にすることができます。
KCP を使用して frps に接続するようにfrpc.tomlを構成します。
# frpc.tomlserverAddr = "xxxx"# frps.tomlserverPort = 7000transport.protocol = "kcp" の 'kcpBindPort' と同じ
QUIC は、UDP 上に構築された新しい多重化トランスポートです。
FRP での QUIC の使用:
FRPS で QUIC を有効にする:
# frps.tomlbindPort = 7000# QUIC.quicBindPort = 7000 の UDP ポートを指定します
bindPortフィールドは TCP ポートを指定するため、 quicBindPort番号はbindPortと同じ番号にすることができます。
QUIC を使用して frps に接続するようにfrpc.tomlを構成します。
# frpc.tomlserverAddr = "xxxx"# frps.tomlserverPort = 7000transport.protocol = "quic" の 'quicBindPort' と同じ
デフォルトでは、frps はユーザーの要求に応じてバックエンド サービスへの新しい frpc 接続を作成します。接続プーリングを使用すると、frps は事前に確立された一定数の接続を保持し、接続の確立に必要な時間を短縮します。
この機能は、多数の短い接続に適しています。
各プロキシが使用できるプール数の制限をfrps.tomlで構成します。
# frps.tomltransport.maxPoolCount = 5
接続プールの数を有効にして指定します。
# frpc.tomltransport.poolCount = 1
負荷分散はgroupによってサポートされています。
この機能は現在、タイプtcp 、 http 、 tcpmuxでのみ使用できます。
# frpc.toml[[proxies]]name = "test1"type = "tcp"localPort = 8080remotePort = 80loadBalancer.group = "web"loadBalancer.groupKey = "123"[[proxies]]name = "test2"type = " tcp"localPort = 8081remotePort = 80loadBalancer.group = "web"loadBalancer.groupKey = "123"
認証にはloadBalancer.groupKeyが使用されます。
ポート 80 への接続は、同じグループ内のプロキシにランダムにディスパッチされます。
タイプtcpの場合、同じグループ内のremotePort同じである必要があります。
タイプhttp 、 customDomains 、 subdomainの場合、 locations同じである必要があります。
ヘルスチェック機能は、負荷分散による高可用性の実現に役立ちます。
healthCheck.type = "tcp"またはhealthCheck.type = "http"を追加してヘルスチェックを有効にします。
ヘルスチェックのタイプがtcpの場合、サービス ポートは ping (TCPing) されます。
# frpc.toml[[proxies]]name = "test1"type = "tcp"localPort = 22remotePort = 6000# TCP ヘルス チェックを有効にするhealthCheck.type = "tcp"# TCPing timeout minuteshealthCheck.timeoutSeconds = 3# ヘルス チェックが 3 回失敗した場合連続すると、プロキシは frpshealthCheck.maxFailed = 3# 10 秒ごとのヘルス チェックから削除されますhealthCheck.intervalSeconds = 10
ヘルスチェックタイプがhttpの場合、HTTP リクエストがサービスに送信され、HTTP 2xx OK 応答が期待されます。
# frpc.toml[[proxies]]name = "web"type = "http"localIP = "127.0.0.1"localPort = 80customDomains = ["test.example.com"]# HTTP ヘルス チェックを有効にするhealthCheck.type = "http" # frpc は GET リクエストを '/status' # に送信し、HTTP 2xx OK レスポンスを期待しますhealthCheck.path = "/status"healthCheck.timeoutSeconds = 3healthCheck.maxFailed = 3healthCheck.intervalSeconds = 10
デフォルトでは、frp はバイトごとのコピーであるため、トンネリングされた HTTP リクエストをまったく変更しません。
ただし、Web サーバーと HTTP リクエストに関して言えば、Web サーバーは、アクセスする Web サイトを決定するためにHost HTTP ヘッダーに依存する場合があります。 frp は、HTTP リクエストを転送するときに、 hostHeaderRewriteフィールドを使用してHostヘッダーを書き換えることができます。
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]hostHeaderRewrite = "dev.example.com"
HTTP リクエストは、実際の Web サーバーに到達するとHostヘッダーがHost: dev.example.comに書き換えられますが、ブラウザからのリクエストにはおそらくHost: test.example.comが含まれます。
Hostと同様に、他の HTTP リクエストおよびレスポンス ヘッダーをプロキシ タイプhttpでオーバーライドできます。
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]hostHeaderRewrite = "dev.example.com"requestHeaders.set.x-from-where = "frp"responseHeaders.set.foo = "バー"
この例では、HTTP リクエストにヘッダーx-from-where: frpを設定し、HTTP レスポンスにfoo: bar設定します。
この機能は、 httpプロキシ、またはhttps2httpおよびhttps2httpsプラグインが有効になっているプロキシ用です。
ユーザーの実際の IP は、HTTP リクエスト ヘッダーX-Forwarded-Forから取得できます。
frp は、ユーザーの実際の IP をローカル サービスに送信するためのプロキシ プロトコルをサポートしています。 UDP を除くすべてのタイプをサポートします。
https サービスの例を次に示します。
# frpc.toml[[proxies]]name = "web"type = "https"localPort = 443customDomains = ["test.example.com"]# v1 と v2 がサポートされるようになりましたtransport.proxyProtocolVersion = "v2"
nginx でプロキシ プロトコルのサポートを有効にして、HTTP ヘッダーX-Real-IPでユーザーの実際の IP を公開し、Web サービスで実際の IP のX-Real-IPヘッダーを読み取ることができます。
パスワードで保護しない限り、トンネル URL を推測できる人は誰でもローカル Web サーバーにアクセスできます。
これにより、frpc の構成ファイルで指定されたユーザー名とパスワードを使用して、すべてのリクエストに HTTP 基本認証が強制されます。
プロキシ タイプが http の場合にのみ有効にできます。
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]httpUser = "abc"httpPassword = "abc"
ブラウザでhttp://test.example.comにアクセスすると、ユーザー名とパスワードの入力を求められます。
多くの人が1つのFRPSサーバーを共有する場合、httpおよびhttpsタイプのsubdomain configureを使用すると便利です。
# frps.tomlsubDomainHost = "frps.com"
*.frps.com frps サーバーの IP に解決します。これは通常、ワイルドカード DNS レコードと呼ばれます。
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80subdomain = "test"
これで、 test.frps.comの Web サービスにアクセスできるようになります。
subdomainHostが空でない場合、 customDomains subdomainHostのサブドメインにすることはできないことに注意してください。
frp は、URL ルーティングによるさまざまなバックエンド Web サービスへの HTTP リクエストの転送をサポートしています。
locationsルーティングに使用される URL のプレフィックスを指定します。 frps は、リストされた順序に関係なく、リテラル文字列によって指定された最も具体的なプレフィックスの場所を最初に検索します。
# frpc.toml[[proxies]]name = "web01"type = "http"localPort = 80customDomains = ["web.example.com"]locations = ["/"] [[proxies]]name = "web02"type = "http"localPort = 81customDomains = ["web.example.com"]locations = ["/news", "/about"]
URL プレフィックス/newsまたは/aboutを持つ HTTP リクエストはweb02に転送され、その他のリクエストはweb01に転送されます。
frp は、 vhostHTTPPortおよびvhostHTTPSPortと同様に、frps の単一ポート上の異なるプロキシに向けられた TCP ソケットの受信をサポートします。
現時点でサポートされている唯一の TCP ポート多重化方式はhttpconnect (HTTP CONNECT トンネル) です。
frps でtcpmuxHTTPConnectPort 0 以外に設定すると、frps はこのポートで HTTP CONNECT リクエストをリッスンします。
HTTP CONNECT リクエストのホストは、FRPS でプロキシと照合するために使用されます。 multiplexer = "httpconnect"の場合、 tcpmuxプロキシの下にcustomDomainsおよび/またはsubdomainを構成することで、frpc でプロキシ ホストを構成できます。
例えば：
# frps.tomlbindPort = 7000tcpmuxHTTPConnectPort = 1337
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "proxy1"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["test1"]localPort = 80[[proxies]]name = "proxy2 "type = "tcpmux"multiplexer = "httpconnect"customDomains = ["test2"]localPort = 8080
上記の構成では、次のような HTTP CONNECT ヘッダーを使用してポート 1337 で frps に接続できます。
CONNECT test1 HTTP/1.1rnrn
接続はproxy1にルーティングされます。
OS 環境変数HTTP_PROXYを設定している場合、または frpc.toml ファイルにtransport.proxyURLが設定されている場合、frpc はプロキシ経由で frps に接続できます。
プロトコルが tcp の場合にのみ機能します。
# frpc.tomlserverAddr = "xxxx"serverPort = 7000transport.proxyURL = "http://user:[email protected]:8080"
v0.56.0で追加されました
Go テンプレートの範囲構文を組み込みのparseNumberRangePair関数と組み合わせて使用して、ポート範囲マッピングを実現できます。
次の例を実行すると、 test-6000, test-6001 ... test-6007という名前の 8 つのプロキシが作成され、それぞれがリモート ポートをローカル ポートにマッピングします。
{{- range $_, $v := parseNumberRangePair "6000-6006,6007" "6000-6006,6007" }}
[[proxies]]
name = "tcp-{{ $v.First }}"
type = "tcp"
localPort = {{ $v.First }}
remotePort = {{ $v.Second }}
{{- end }}frpc は、デフォルトではリクエストをローカル TCP ポートまたは UDP ポートにのみ転送します。
プラグインは豊富な機能を提供するために使用されます。 unix_domain_socket 、 http_proxy 、 socks5 、 static_file 、 http2https 、 https2http 、 https2httpsなどの組み込みプラグインがあり、使用例を確認できます。
プラグインhttp_proxyを使用する:
# frpc.toml[[proxies]]name = "http_proxy"type = "tcp"remotePort = 6000[proxies.plugin]type = "http_proxy"httpUser = "abc"httpPassword = "abc"
httpUserおよびhttpPassword 、 http_proxyプラグインで使用される構成パラメーターです。
文書を読んでください。
gofrp/plugin でその他のプラグインを見つけます。
v0.53.0で追加されました
frp は、frps 側で SSH ポートのリッスンをサポートし、frpc に依存せずに、SSH -R プロトコルを介して TCP プロトコル プロキシを実現します。
# frps.tomlsshTunnelGateway.bindPort = 2200
./frps -c frps.tomlを実行すると、 .autogen_ssh_keyという名前の秘密キー ファイルが現在の作業ディレクトリに自動的に作成されます。この生成された秘密キー ファイルは、frps の SSH サーバーによって使用されます。
コマンドの実行
ssh -R :80:127.0.0.1:8080 v0@{frp アドレス} -p 2200 tcp --proxy_name "test-tcp" --remote_port 9090ローカル 8080 サービスをポート 9090 に転送するプロキシを frps に設定します。
frp (SSH 経由) (終了するには Ctrl+C) ユーザー： プロキシ名: test-tcp タイプ: tcp リモートアドレス: :9090
これは次と同等です。
frpc tcp --proxy_name "test-tcp" --local_ip 127.0.0.1 --local_port 8080 --remote_port 9090
詳細については、このドキュメントを参照してください。
gofrp/plugin - frp 拡張メカニズムに基づいて実装されたさまざまなプラグインを含む frp プラグインのリポジトリで、さまざまなシナリオのカスタマイズ ニーズに対応します。
gofrp/tiny-frpc - ssh プロトコルを使用して実装された frp クライアントの軽量バージョン (最小約 3.5 MB) で、最も一般的に使用される機能のいくつかをサポートしており、リソースが限られているデバイスに適しています。
参加することに興味がありますか?ぜひお手伝いさせていただきたいと思います！
問題リストを見て、開発ブランチにプル リクエストを送信することを検討してください。
新しい機能を追加する場合は、まず問題を作成して、新しい機能と実装アプローチを説明してください。提案が受け入れられたら、新しい機能の実装を作成し、プル リクエストとして送信します。
私の下手な英語でごめんなさい。このドキュメントの改善は、いくつかのタイプミスの修正も含めて歓迎されます。
素晴らしいアイデアがある場合は、[email protected] にメールを送信してください。
注: 同じ質問を持つ他の人がすぐに検索でき、何度も回答する必要がないように、問題についてアドバイスを提供していただくことを推奨します。
frp が大いに役立つ場合は、次の方法でサポートしていただけます。
Github スポンサーによってサポートしてください。
このプロジェクトの README ファイルに会社のロゴを配置することができます。
PayPal で私のアカウント[email protected]に寄付してください。
