how to create a reverse proxy

概要

本当のオリジンIPを隠し、パフォーマンスを向上させ、サードパーティからアプリを保護するために、VPS上でHAProxyを使用してリバースプロキシを設定する方法について説明します。本当のオリジンサーバIPを隠すためにHAProxyでリバースプロキシを作成する方法

リバースプロキシとは何ですか？

リバースプロキシはクライアントとサーバーの間に位置します。リクエストを受信し、送信先を決定し、レスポンスを返します。また、複数のバックエンド間の負荷分散、セキュリティヘッダーの追加、不正なクライアントのレート制限、TLS (HTTPS) 終端の一元管理も可能である。

リバースプロキシは

スマートな用心棒のようなものだと考えてほしい。

つまり、リバースプロキシは、オリジンがプライベートに保たれている間、すべてを円滑に動かす静かな働き者なのである。

HAProxyによるリバースプロキシ：どのように動作するか

HAProxyは強力なL4/L7プロキシとロードバランサです。クライアントのリクエストはまずHAProxyにヒットします：

  • TLS (HTTPS) を終了することができます。
  • ATP_NOTR_13_CODE_TAG_NOTR_ATP###、##ATP_NOTR_14_CODE_TAG_NOTR_ATP###、##ATP_NOTR_15_CODE_TAG_NOTR_ATP###などのヘッダーが追加されます。
  • トラフィックは、ホスト名、パス、またはカスタムルールによってバックエンドにルーティングされます。
  • ヘルスチェック、自動フェイルオーバー、レート制限、圧縮、軽いキャッシュ、WebSocket、gRPCパススルーが利用可能です。
  • 詳細なログとライブ統計ページが観測可能性を提供します。

結論：HAProxyはアーキテクチャを簡素化し、セキュリティとパフォーマンスを向上させ、スケーリングを容易にする。

HAProxyの長所と短所

長所（HAProxyが輝く理由）

  • 高いパフォーマンスと低いオーバーヘッド（イベントドリブン、マルチスレッド）。
  • L4 + L7のスマートさ（TCP/SNIパススルーまたは完全なHTTPルーティング/リライト）。
  • 堅牢なロードバランシングとヘルスチェック（ラウンドロビン、leastconn、ハッシュ、アクティブチェック、フェイルオーバー）。
  • セキュリティ機能（TLS終端、HSTS、ACL、スティックテーブルによるレート制限、IP許可/拒否）。
  • 観測可能性（豊富なログ、ライブ統計ソケット/ページ、Prometheusエクスポータが利用可能）。
  • 信頼性（ダウンタイムがほぼゼロに近いグレースフル・リロード。）
  • フットプリントが小さい（Linux/BSD/コンテナなど、事実上どこでも動作）。

短所（トレードオフ）

  • 学習曲線（強力だが冗長な設定）。
  • 証明書の自動化が組み込まれていない（Certbot/legoまたはData Plane APIと組み合わせる）。
  • デフォルトでは手動でのサービス検出（動的バックエンドにはテンプレート/APIが必要）。
  • 組み込みのキャッシュ/静的サービングに制限がある（必要に応じてCDN/Varnish/Nginxを使用）。
  • ネイティブのコミュニティWAFがない（別のWAFかHAProxy Enterpriseを使う）。
  • 複雑な書き換えをすると、言葉が多くなることがある。
  • Windowsのサポートは限定的（Linux/BSDがベスト）。

必要なもの

  • HAProxy（リバースプロキシ）用のVPS/パブリックサーバ。
  • オリジンサーバー(10.0.0.10:8080など)。
  • HAProxyサーバーのパブリックIPを指すDNS A/AAAの ドメイン（例：##ATP_NOTR_17_CODE_TAG_NOTR_ATP###）。

プライバシーのヒント：オリジンIPを本当に隠すには、オリジンが一般に到達可能でないことを確認し、HAProxyサーバからのトラフィックのみを受け入れるようにファイアウォールを設定し、オリジンを明らかにするDNSレコードを避ける。

ステップ1 – HAProxyのインストール

Ubuntu/Debian

###atp_notr_1_code_tag_notr_atp##をインストールします。

RHEL/Alma/Rocky

#atp_notr_2_code_tag_notr_atp###

ステップ2 – TLS証明書を取得する（Let’s Encrypt）

Certbotに証明書を取得させ、HAProxy用にバンドルする。

certbotをインストールし、証明書を取得する。

###atp_notr_3_code_tag_notr_atp###。

HAProxyのPEMバンドルを作成(fullchain + privkey)

HAProxy の PEM バンドルを作成する (fullchain + privkey) ###atp_notr_4_code_tag_notr_atp###

更新時にHAProxyを自動で再バンドル＆リロードする

###atp_notr_5_code_tag_notr_atp###

ステップ 3 – 最小限の本番用 HAProxy 設定 (HTTPS + リダイレクト)

ATP_NOTR_18_CODE_TAG_NOTR_ATP##とバックエンドのIP/ポートを置き換える。

  • HAProxyは##ATP_NOTR_19_CODE_TAG_NOTR_ATP##でTLSを終了し、##ATP_NOTR_20_CODE_TAG_NOTR_ATP##にリダイレクトします。
  • 通常のトラフィックは、##ATP_NOTR_21_CODE_TAG_NOTR_ATP##のオリジンに流れます。
  • 更新時には、/.well-known/acme-challenge/* のみが、Certbot が実行する小さなローカル Web サーバーにルーティングされます。

ステップ 4 – 起動、リロード、検証

###atp_notr_7_code_tag_notr_atp###

ステップ 5 – ハンズオフ更新

HAProxy が :80/:443 を開いている間、Certbot を :8081 に短時間バインドさせます：
###更新中、Certbot はポート 8081 でチャレンジに答えますが、HAProxy はすでにそのパスを 127.0.0.1:8081 にルーティングしています。

バリエーション（必要なものを選んでください）

A) ホスト名による複数のオリジン

A) ホスト名による複数のオリジン

# Add in frontend:
acl host_api hdr(host) -i api.example.com
use_backend be_api if host_api

# Define an API backend:
backend be_api
  balance roundrobin
  option httpchk GET /healthz
  server api1 10.0.0.21:9000 check
  server api2 10.0.0.22:9000 check

B) TLSパススルー（オリジンがTLS/mTLSを処理する）

SNIルーティングでTCPモードを使用する。ここではヘッダーの書き換えやL7機能は使用しない。

frontend fe_tcp
  mode tcp
  bind :443
  tcp-request inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }
  use_backend be_tls_app if { req_ssl_sni -i example.com }

backend be_tls_app
  mode tcp
  server app_tls 10.0.0.10:443 check

C)最小限のHTTPのみのリバースプロキシ(TLSなし)

内部/テスト専用。本番では HTTPS を使用すること。

global
  log /dev/log local0

defaults
  mode http
  log global
  option httplog
  timeout connect 5s
  timeout client  60s
  timeout server  60s

frontend public_http
  bind :80
  option forwardfor
  default_backend app

backend app
  server app1 10.0.0.10:8080 check

簡単なチェックとトラブルシューティング

###ファイアウォールのヒント：

  • オリジンをロックして、HAProxy サーバーからのトラフィックのみを受け入れるようにします（ufw、firewalld、またはクラウドセキュリティグループを使用するなど）。
  • オプションとして、プロバイダー・レベルでオリジンIPへの直接パブリック・アクセスをブロックします。

最終的な注意事項

  • ワークロードに適したタイムアウトを維持してください（WebSocket/gRPC はより高いタイムアウトが必要な場合があります）。
  • アプリで /health のエンドポイントを公開してください。
  • ゼロダウンタイムのデプロイを計画する：デプロイ中にサーバー (disabled) を停止し、その後再度有効にします。

重要事項サーバーの正しい設定方法が不明な場合は、専門家に依頼して設定を完了することを強くお勧めします。ファイアウォールのポートを確認し、ポートブロックがないことを確認することを含め、すべての設定が正確に行われていることを確認することが重要です。 設定プロセスを効果的にナビゲートするためには、少なくともファイアウォールとLinuxコマンドの基本的な理解を持っていることが重要です。 設定プロセスで発生する可能性のある損害や問題については、弊社では責任を負いかねますのでご了承ください。ここで提供されるすべての情報は、技術的な知識と学習のみを目的としています。 ご理解のほど、よろしくお願いいたします。