ServBayサイトをインターネットに公開する（リバースプロキシ・トンネル・ポート転送）

ローカル開発だけでなく、多くのユーザーがServBayを常時稼働のサーバー（データセンター設置のMac mini、オフィスの専用PC、Windowsサーバー等）に配置し、バックエンドオリジンサーバーとしてウェブサイトをインターネットに公開しています。これは本番環境でも全く問題のない構成で、既に多くのユーザーが安定して運用しています。

ただし、ServBay標準のネットワークの動作仕様を理解しないまま運用すると、プロトコル、証明書、Hostヘッダ、ネットワーク周りで思わぬトラブルに見舞われがちです。「ローカルは正常なのに外部アクセスがエラー」となる典型例です。本記事では、ServBayをバックエンドオリジンサーバーとして活用したい全てのユーザー向けに、まずデフォルトの挙動を明確に解説し、その後「内蔵トンネル → リバースプロキシ（推奨）→ ポート転送」という順で具体的な公開手順を紹介。最後に汎用的なトラブルシュートリストも用意しています。

対応プラットフォーム

本記事は macOS版 ServBay と Windows版 ServBay の両方に対応しています。両プラットフォームともサイトのプロトコルモード、リッスン方法、証明書パスの規則は完全に一致しています（インストール先ディレクトリのみ異なります。macOSは/Applications/ServBay、Windowsは通常C:\ServBayです）。標準Webサーバーは若干異なり、macOSはCaddy、WindowsはNginxが標準ですが、どちらもNginx / Apache / Caddyに切り替え可能です。

まずはServBayの標準ネットワーク挙動を理解する

ほとんどの外部公開トラブルは、以下の標準動作への誤解から発生します：

1. サイト標準プロトコルは HTTP & HTTPS
   このモードでは、HTTP（80）でのアクセスは無条件で301リダイレクトによりHTTPS（443）へ転送されます。これは時代に即したセキュアなデフォルト動作です。基本的にはHTTPSを活用し、平文80番には戻さないでください。
2. HTTPSではSNIでサイトや証明書を選択
   同一のServBay上で複数サイトを運用する場合、TLSハンドシェイク中のSNI（= サイトのドメイン名）で証明書・サイトが選別されます。リバースプロキシがHTTPSでアクセスする際は、必ず正しいSNIを送信してください。そうでなければデフォルトサイト/証明書が返されます。
3. 標準で全てのネットワークインターフェースをリッスン（0.0.0.0）
   デフォルトでHTTP 80／HTTPS 443ポートをすべてのアドレスで受け付け、基本的にアクセス制限を変更する必要はありません。
4. ローカルHTTPS証明書はServBay CAが発行
   ServBayにはローカルCA（キーチェーンでServBay User CA - ECC Rootと表示されます）が組み込まれており、あなたのサイト用に証明書が発行されます。外部からのブラウザはこれをデフォルトで信頼しませんが、リバースプロキシ側で当該CAを信頼（もしくは検証スキップ）すればOK。バックエンド間のリンク用に別途パブリック証明書を発行する必要はありません。

よくある勘違い：HTTP & HTTPS かつ80だけ転送する

WebサイトをHTTP & HTTPSのまま、80だけを外部に転送し、443を扱わない場合：「http://ドメイン」→ ServBayが「301 https://ドメイン」にリダイレクト → クライアントが443へ接続 → 応答無し → アクセス失敗。さらに、ブラウザやHSTSがこの301をキャッシュして原因特定を困難にします。

正解は80（HTTP）へ戻すのではなく、HTTPSを通すことです（下記リバースプロキシ手順参照）。

公開方法を選ぶ基準

方法	概要	適用シーン
内蔵トンネル（frpc / cloudflared など）	ServBay標準搭載。外部へ能動的に接続を張るため、グローバルIPやポート開放不要	グローバルIPなし・家庭/NAT・手早い公開に
前段リバースプロキシ（推奨）	Nginx/HAProxy/Caddy/Traefik等で外部アクセスと証明書管理。HTTPSでServBayへリバースプロキシ	グローバルIPあり、統一エントリ・複数バックエンド・証明書集中管理
ポート転送（NAT）	ルーター等のゲートウェイで外部ポートを直接ServBayに転送	バックエンド1台のみ、動作を熟知している場合

方法1：内蔵トンネル（最も簡単・グローバルIP不要）

グローバルIPアドレスがない、あるいはリバースプロキシや証明書周りの設定で手間をかけたくない場合、ServBay内蔵トンネルサービスが最も簡単です。これらはServBay側から外部に向けて能動的に通信を開始するため、NAT・IPv6・ポート開放・証明書信頼など多くの問題を自然に回避できます：

• Cloudflare Tunnel（cloudflared） — Cloudflareグローバルネットワーク経由でローカルサイトを公開。自動的にパブリックHTTPS証明書を提供し、ポート開放不要。安定した独自ドメインやCDN/WAF用途に最適。
• frp（frpc） — 独自構築のfrpsサーバーに接続。完全に自己管理。
• ngrok / Pinggy — 一時的なパブリックURLを素早く生成。デモやWebhook連携に最適。

多くのケースでは、cloudflaredでトンネルを構築するだけで、ローカルサイトのインターネット公開という目的を十分に果たせます。以降のリバースプロキシやポート転送の解説は、より詳細な運用向けです。

方法2：前段リバースプロキシ＋HTTPSバックエンド（推奨）

本番運用向けに推奨される最良の手法です。前段プロキシがパブリック証明書付きのHTTPSを外部に提供し、バックエンドもHTTPS（HTTP & HTTPSモードのまま）でServBayへプロキシします。エンドツーエンド暗号化を確保可能。

なぜHTTPSバックエンドを推奨するのか？ HTTP80バックエンドはNG？

世に多い古い手法は「オリジン（バックエンド）はHTTPで受ける」というもの。しかし、本記事ではこの旧式手法は非推奨（特殊な理由とリスクを理解している場合は例外です）。

• エンドツーエンド暗号化：前段プロキシからServBayまで、全区間を暗号化。内部ネットワークでもスニッフィングや中間者攻撃を排除できます。
• 最新のプロトコル機能：HTTPSのままなら**HTTP/2（h2）**が使えます。多重化・ヘッダ圧縮・コネクション再利用など現代的な高速化が有効に。HTTP 80のままでは旧世代技術に固定されます。
• ダウングレードによるトラブルを回避：HTTPへ戻すと、HTTP & HTTPSモードの301リダイレクトやHSTSキャッシュ、応用部分でhttpsリンク生成等、問題が山積します。
• ServBay CAの信頼手順はシンプル：ServBayは自己署名CAですが、前段プロキシ側で一度CAを信頼（必要に応じて検証スキップ）設定すれば運用上問題ありません。

明文HTTP 80によるバックエンド運用は方法3を参照。十分な技術的説明とリスク理解前提です。

一般的なポイント

ここからの各プロキシ設定例では、ドメインを example.com、ServBayホストを 192.168.1.115、バックエンドHTTPSポートを 443、サイト設定を HTTP & HTTPSとしています。

1. HTTPSバックエンド接続：リバースプロキシのproxy_passやupstreamはhttps://192.168.1.115:443を指示。
2. 正確なSNIを送る：SNIはServBay上の設定ドメイン（example.com）と一致させる必要あり。SNIが異なると適切な証明書が出ません。
3. ServBay CAを信頼（推奨）または検証スキップ：CAファイルの入手方法は下記参照。
4. Hostヘッダは透過：Host: example.comを維持、ServBayのserver_nameと一致。
5. X-Forwarded-Proto: httpsを送信：アプリ側でhttps判別やリンク生成誤り・リダイレクトループ等を防ぎます。
6. IPv4/IPv6整合性を保つ：IPv4/IPv6の一致を参照。

ServBay CA証明書の取得（プロキシからの信頼用）

ServBayローカルCAの証明書ファイル：

• macOS：/Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
• Windows：C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt（インストール先により異なる）

この.crtファイルをリバースプロキシサーバー（例：/etc/nginx/servbay-ca/）にコピーし、プロキシ設定でバックエンド証明書検証の信頼CAとして指定してください。

証明書チェーンについて

ServBayは「ルートCA ＋ 中間CA」の2階層構造です。プロキシがルート証明書だけを信頼・中間CA分を信頼しない場合は検証に失敗するため、ルート証明書と中間証明書（ServBay-Private-CA-ECC-Intermediate.crt、同ディレクトリ）を1つのCA bundleに結合して信頼させてください。または、まず「検証スキップ」で疎通確認し、後に厳格検証へ切り替えましょう。

Nginxリバースプロキシ（HTTPSバックエンド）

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # IPv6対応の場合
    server_name example.com;

    # 外部向けのパブリック証明書（例：Let's Encrypt）
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # HTTPSバックエンド

        # —— 重要：SNIと証明書検証 ——
        proxy_ssl_server_name on;                             # SNI送信
        proxy_ssl_name        example.com;                    # SNI = ServBay側のドメイン名
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # ServBay CA利用後は検証ON
        proxy_ssl_verify_depth 2;                             # ルート＋中間、2段階
        # シンプル案（CA未指定）：proxy_ssl_verify off;

        # —— 重要：Hostヘッダとプロトコルも透過 ——
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# HTTP→HTTPSリダイレクト（外部側で一元対応）
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxyリバースプロキシ（HTTPSバックエンド）

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # HTTPSバックエンド：ssl + SNI送信 + サーバー証明書検証
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # シンプル案：server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddyリバースプロキシ（HTTPSバックエンド）

Caddyはexample.comのパブリック証明書を自動発行＆更新し、reverse_proxyはデフォルトでHostやX-Forwarded-*を透過します：

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # シンプル案：tls_insecure_skip_verify
        }
    }
}

Traefikリバースプロキシ（HTTPSバックエンド）

file providerによる動的構成例：

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Host透過
        servers:
          - url: "https://192.168.1.115:443" # HTTPSバックエンド
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # シンプル案：insecureSkipVerify: true

方法3：ポート転送（NAT）

バックエンドが1台のみなら、ルーター/ゲートウェイで外部の443ポートを直接ServBayマシン（例えば192.168.1.115）に転送することで公開も可能です。

推奨：443転送でHTTPSを維持

1. ゲートウェイのポート転送設定例：グローバル 443 → 192.168.1.115:443（および、グローバル 80 → 192.168.1.115:80、自動で80→443にリダイレクト）。
2. DNSのAレコードでIPを指す。
3. サイトは HTTP & HTTPSモードのまま。直接ServBayに外部アクセスされるため、該当ドメインにパブリックな信頼可能な証明書を必要とします（後述の証明書説明参照）。さもなくば、訪問者ブラウザで警告となります。
4. IPv4/IPv6の整合も必ず確認（次節参照）。

明文HTTP 80のみ直結（特殊用途限定）

80だけを転送しサイトモードをHTTPにセットする方法は、HTTPSやHTTP/2の利点をすべて捨て去るものであり、かつHSTSやブラウザキャッシュトラブルともなりやすいです。技術的必要性とリスク理解がある場合のみ推奨します。その場合、対象サイトのプロトコルを明示的にHTTPにし（301による443リダイレクト回避）、80のみ転送してください。

IPv4/IPv6の整合性

外部アクセスの不安定化で非常に多い原因です。ドメインにA（IPv4）とAAAA（IPv6）が両方ある場合、クライアントはHappy Eyeballs等でIPv6優先となることがあります。もしIPv4方向しか転送・プロキシ設定していないと、IPv6経由で試行されたリクエストは失敗します。次のいずれかで対応：

• IPv4だけ使う：dig AAAA あなたのドメイン +shortで結果を空に、Aレコードのみ残します。
• IPv6も同時に対応：IPv6でも転送設定、プロキシも[::]でもリッスンさせ、バックエンドへのIPv6疎通も動作確認。

アクセス異常時のトラブルシュートリスト

外部公開時「アクセス不可・タイムアウト・証明書エラー・異なるサイトが表示」等の場合は、次の順にチェックしてください（例：ドメインexample.com、バックエンド192.168.1.115）：

1. 301で未開放の443に飛ばされていないか？

   curl -I http://example.com

   結果に301＋Location: https://...が返り、サービス側で443未対応の場合が原因。HTTPSを開放する（推奨）/ サイトをHTTPに変更。

2. IPv6が問題化していないか？

   curl -4 -I https://example.com     # IPv4でのみ確認
   curl -6 -I https://example.com     # IPv6で確認
   dig A example.com +short
   dig AAAA example.com +short        # AAAAあり・IPv6疎通不可→削除または設定

3. SNI/証明書は正常か？（HTTPSリバースプロキシ時）バックエンドにSNIを付けて直接アクセス：

   curl -I --resolve example.com:443:192.168.1.115 https://example.com \
        --cacert /path/servbay-ca-bundle.crt

   証明書やサイトミスマッチは、SNI違い・CA未信頼が主原因。

4. リクエストは本当にServBayに届いているか？ ServBayホストで該当サイトのWebサーバーログ（ServBay管理画面の「Logファイル表示」）。ログに該当リクエストがない場合はネットワーク・ゲートウェイ・プロキシ段階で停止。

5. Hostヘッダは正常か？（L7リバースプロキシの場合）

   curl -k -I -H "Host: example.com" https://192.168.1.115/

   バックエンド直結時はOKだがプロキシ経由でエラー→Host未透過。

証明書とセキュリティ

• バックエンド接続用：リバースプロキシ→ServBay間をHTTPSで繋ぐ際、プロキシ側でServBay CA（ServBay-Private-CA-ECC-Root.crt、必要に応じ中間CAもバンドル）を信頼設定。これは内部での信頼管理で、一度設定すれば基本メンテ不要。
• 外部向け証明書：インターネット向けには公開され信頼された証明書が必要です。リバースプロキシ型ならプロキシ側で発行・管理（CaddyやTraefikは自動発行/更新対応）。ポート転送で直結の場合は、ServBay上でドメイン用パブリック証明書を発行・配置（ACMEによる証明書発行手順参照）。ServBayの自己署名ServBay User CA証明書はローカル/社内専用であり、外部アクセス時は信頼されません。
• データベースを公開しないこと：Webを公開する際、MySQLやRedis、Memcached等のデータベースポートまで一緒に外部開放しないよう注意。サーバー内LANアクセスについてはLANアクセス安全対策も参考に。
• ファイアウォール：必要最小限のポートだけを公開し、それ以外は全て遮断。

よくある質問（FAQ）

• Q：ローカルは正常だが外部アクセスだけ異常。DNSの問題？
  • A：大抵は「名前解決不能」ではなく、HTTP & HTTPSの301が443未対応にリダイレクト、SNI/証明書の設定ミス、Hostヘッダ未透過、もしくはIPv4/IPv6不整合等が要因です。トラブルシュートリストを順に調べてください。
• Q：どうしてもHTTP 80にしないとプロキシ連携できないのか？
  • A：不要です。HTTP & HTTPSのまま、プロキシからHTTPSでServBay CA（または検証スキップ）を利用すれば、エンドツーエンド暗号化もHTTP/2も両立可能。80に戻す必要はありません。
• Q：プロキシバックエンドで証明書エラーや違うサイト？
  • A：正しいSNI（=ドメイン名）指定とServBay CA信頼設定（必要なら中間CA含む）を確認。まず検証スキップで疎通し、後で厳格モードへ。
• Q：ServBayを本番用サーバーに設置して安定運用できるか？
  • A：可能です。Mac miniやWindowsサーバー等、IDC常駐で公開運用しているユーザー多数。プロトコルモード・SNI・Hostヘッダ・証明書信頼・IPv4/IPv6の整合を必ず取ってください。
• Q：グローバルIPがない場合は？
  • A：方法1：内蔵トンネル（cloudflared / frpc）推奨。グローバルIPやポート転送が不要です。

まとめ

ServBayをバックエンドオリジンサーバーとしてインターネット公開するのは技術的に全く問題ありません。推奨ルートは：「サイトをHTTP & HTTPSモードのまま運用し、前段のリバースプロキシからHTTPSバックエンド接続、SNIを正確に指定してServBay CAを信頼。これでエンドツーエンド暗号化やHTTP/2等の現代的機能が得られます。グローバルIP非保有なら内蔵cloudflared/frpcトンネルが手っ取り早い手段。ポート転送は構成の理解が十分な場合限定。
アクセスに問題が出た場合は本記事のトラブルシュートリストを活用すれば即座に切り分けできます――大抵はプロトコル、SNI/証明書、Hostヘッダ、IPv4/IPv6の設定に集約されます。