HTTP ポート ガイド: ポート 80 の Web トラフィック

HTTP は、ブラウザ、API、Webhook、ヘルスチェック、および多くの内部サービスで使用される要求および応答プロトコルです。ポート 80 では、クライアントは TCP 経由で接続し、HTTP 要求を送信し、最初に TLS ハンドシェイクを行わずにヘッダーと応答本文を受信します。

トラフィックは暗号化されていないため、アプリケーションが独自の保護を追加しない限り、ネットワーク パスを監視できる人は誰でも URL、Cookie、ヘッダー、フォーム データ、および応答コンテンツを見ることができます。パブリック Web サイトおよび認証されたアプリケーションの場合、通常、ポート 80 はプライベート コンテンツを直接提供するのではなく、HTTPS にリダイレクトする必要があります。

ポート 80 はプレーン HTTP です。ポート 443 は HTTPS であり、TLS 暗号化セッション内で伝送される HTTP を意味します。ブラウザーでのユーザー エクスペリエンスは似ているように見えますが、セキュリティ モデルは異なります。HTTPS はサーバー証明書を検証し、転送中のトラフィックを暗号化します。

ほとんどの実稼働サイトでは、両方のポートを一緒に使用します。ポート 80 は、古いリンク、証明書チャレンジ、および初回のブラウザー要求を受け入れ、301 または 308 リダイレクトを 443 の HTTPS URL に送信します。その後、HSTS はブラウザーに HTTPS を自動的に優先するように指示できます。

HTTP から HTTPS へのリダイレクト、Let's Encrypt HTTP-01 チャレンジ、ロード バランサーのヘルス チェック、CDN オリジン チェック、単純な内部ステータス エンドポイント、または HTTPS で直接起動できない古いシステムとの互換性が必要な場合は、ポート 80 を開いたままにしてください。

サービスがプライベートである場合、すべてのクライアントが制御されて HTTPS を直接使用できる場合、またはプレーン HTTP が不必要な露出を引き起こす場合には、ポート 80 を閉じるか制限します。オープンなままにする場合は、アプリケーションへの完全なアクセスではなく、リダイレクト、チャレンジ、またはヘルス チェックなど、動作を限定的かつ予測可能なものにしてください。

TCP 80 を開く前に、目的の Web サーバー、リバース プロキシ、イングレス コントローラー、CDN オリジン、またはロード バランサーが正しいインターフェイスでリッスンしていることを確認してください。ポート 80 がコンテンツを提供するか、443 にリダイレクトするか、ヘルスチェックに応答するか、証明書検証パスのみに応答するかを決定します。

ポート チェッカーはネットワークの到達可能性を確認しますが、リダイレクト チェーン、キャッシュ ヘッダー、仮想ホスト ルーティング、または証明書の自動化が正しいかどうかは示しません。ブラウザ、curl、およびサーバー ログを使用して、TCP パスと HTTP 動作の両方をテストします。

Windows Server で、IIS、Nginx、Apache、Caddy、または別の Web サーバーを実行し、サイトを TCP 80 にバインドし、Windows Defender ファイアウォールで受信 HTTP トラフィックを許可します。クラウド サーバーには、一致するクラウド ファイアウォールまたはセキュリティ グループ ルールも必要です。

Linux では、Nginx、Apache、Caddy、コンテナー ポート パブリッシュ、またはイングレス コントローラーを 80 でリッスンするように構成し、ufw、firewalld、nftables、iptables、またはプロバイダー ファイアウォールで TCP 80 を許可します。コンテナーと Kubernetes サービスは、ホスト、ロード バランサー、またはイングレス層でポートを公開またはルーティングする必要があります。

macOS では、ポート 80 はローカル開発またはラボ サービスに最もよく使用されます。特権ポートには昇格されたアクセス許可が必要な場合がありますが、他のマシンがサービスにアクセスできるかどうかはローカルのファイアウォールまたはルーターのルールによって決まります。

パブリック ホスト名または IP アドレスとポート 80 に対する外部ポート チェックから開始します。結果がオープンであれば、リモート クライアントは TCP 接続を確立できます。次に、curl -I http://example.com を実行して、ステータス コード、リダイレクト、サーバー ヘッダー、およびキャッシュの動作を検査します。

サーバー上で、ss -tlnp、netstat、lsof、または PowerShell を使用してリスナーを確認します。リバース プロキシとクラウド デプロイメントの場合は、どのレイヤーでも HTTP がブロックされたり、誤ってルーティングされたりする可能性があるため、ホスト ファイアウォール ルール、クラウド セキュリティ グループ、ロード バランサー リスナー、コンテナー ポート マッピング、およびアプリケーション ログを比較します。

ポート 80 が閉じていると表示される場合は、Web サーバーが停止しているか、別のポートを使用してローカルホストのみでリッスンしているか、ホストのファイアウォールによってブロックされている可能性があります。タイムアウトになると、クラウド ファイアウォール、ルーター NAT ルール、ISP フィルター、CDN 設定、またはアップストリーム セキュリティ ポリシーによってパケットがドロップされる可能性があります。

ポート 80 は開いているが、ページが間違っている場合は、仮想ホストの順序、ホスト ヘッダーのルーティング、デフォルトのサーバー ブロック、プロキシ アップストリーム、コンテナ マッピング、および DNS レコードを検査します。リダイレクトがループする場合は、HTTP 仮想ホストと HTTPS 仮想ホストを比較し、プロキシが元のスキームを正しく渡すことを確認します。

意図的にポート 80 を使用します。アプリケーション トラフィックを HTTPS にリダイレクトし、プレーン HTTP 上の資格情報や機密データを回避し、到達可能な状態を維持する必要があるエンドポイントのみを保持します。パブリック サイトの場合は、HTTPS が安定していることを確認した後、リダイレクトを 443 および HSTS 上の有効な証明書と組み合わせます。

ポート 80 へのリクエストをログに記録し、予期しないパスを監視し、プレーン HTTP が不要になったレガシー エンドポイントを削除します。ポート 80 が ACME またはヘルス チェック専用の場合は、サービスの推論と監視が容易になるように、それらのパスへの応答を制限します。