仕組み

Proxerには2つの側があります。公開サーバーはブラウザーやreverse proxyから届く場所で待ち受けます。クライアントはプライベートなサービスの近くで動き、公開サーバーへ先に接続します。アプリのために、内側のネットワークへ入るファイアウォール規則を開ける必要はありません。

1つのリスナーと予約パス

公開サーバーは1つのHTTP/WebSocketリスナーを使います。次のパスはProxerが予約しています。

/__proxer__/control
/__proxer__/health/live
/__proxer__/health/ready

--control-pathオプションはありません。クライアントにはwss://proxy.example.comのようなbase URLだけを渡します。Proxerが内部で/__proxer__/controlを付けます。

制御接続

proxer httpは/__proxer__/controlへWebSocket接続を開きます。トークン認証のあと、指定したサブドメイン経路、明示的なルート経路、またはサーバーが割り当てたランダムなサブドメイン経路を登録します。

公開リクエストが来ると、サーバーはトンネルストリームを作り、すでに開いている制御接続上へリクエストフレームを送ります。クライアントはそのフレームを127.0.0.1:<port>へのリクエストに変換し、レスポンスヘッダーと本文チャンクを同じストリームで返します。

各ストリームには固有のstreamIdがあるので、複数の公開リクエストが1つの制御接続を共有できます。

リクエストの流れ

1. ブラウザーまたはreverse proxyが公開Proxerサーバーへリクエストを送ります。
2. サーバーは有効なホスト名を読み、一致するルートまたはサブドメイン経路を探します。
3. サーバーは登録済みクライアントの制御接続上にトンネルストリームを開きます。
4. クライアントはリクエストを127.0.0.1:<port>へ転送します。
5. レスポンスヘッダーと本文チャンクが同じトンネルストリームで戻ります。
6. 公開サーバーは元の呼び出し元へレスポンスを書き込みます。

HTTPストリーミングとServer-Sent Eventsは、レスポンス全体をため込まずチャンクとして転送されます。WebSocketアップグレードも同じホストルーティングを通り、その後は双方向のトンネルストリームになります。

再接続

確立済みの制御接続が切れた場合、クライアントはアクティブなストリームを片付けて再接続を試みます。同じURLでサーバーに届けば、もう一度認証して経路を登録します。

初回起動はもう少し厳しめです。サーバーが落ちている状態でクライアントを起動すると、再接続ループに入る前にコマンドが失敗することがあります。先にサーバーを起動してください。

Proxerがしないこと

接続中のクライアントが1つだけという理由で、リクエストを自動転送しません。ホスト名がルートドメイン経路または登録済みサブドメイン経路と一致する必要があります。同じトンネルサーバーを複数人や複数サービスで使う場合、このほうが原因を追いやすくなります。