443
HTTPS のポート。ただし HTTP/3 以降は UDP のポートでもあるので、TCP だけを見るチェックは「誰も待ち受けていない」と言いながら、実は半分のトラフィックが捌かれている状態を見落とします。
自分の環境の行をそのまま実行してください。ポートを掴んでいるプロセス名と、バインドしているアドレスが出ます。たいていはそれだけで答えが分かります。
sudo lsof -nP -i :443あえてプロトコルを指定せず `-i :443` としているので、TCP と UDP の両方のソケットが出て、HTTP/3 のリスナーも見えます。`-n` と `-P` でホストもポートも数値のまま。プロトコルが書いてあるのは NODE の列で、`TCP` か `UDP` と出ます。TYPE はアドレス族（`IPv4` / `IPv6`）なので、TYPE が同じ IPv4 の行が二つあっても、片方は TCP の待ち受け、もう片方は UDP の HTTP/3 ということが普通にあります。NAME の列がバインドアドレスで、`127.0.0.1:443` はこのマシン専用、`*:443` は全インターフェイスです。TCP の行は `(LISTEN)` で終わり、UDP の行に状態はありませんが、これが正常です。確立済みのクライアント接続を除きたいときだけ `-sTCP:LISTEN` を足してください。ただしそれを付けると UDP も丸ごと隠れます。`sudo` なしでは root 所有のプロキシは一切出てきません。
sudo ss -tulnp 'sport = :443'`-t` と `-u` で TCP と UDP、`-l` で待ち受けソケットのみ、`-n` でポートを数値のまま、`-p` で持ち主を出します。同じポートに 2 行出るのは HTTP/3 を有効にしたサーバーの正常な姿で、衝突ではありません。あとはアドレスの列がすべてを決めます。`0.0.0.0:443` は全 IPv4 インターフェイス、`[::]:443` は IPv6 のワイルドカードでたいてい IPv4 も受け、`127.0.0.1:443` は SSH トンネル越しでしか見られないサイトの理由そのものです。プロセス名は `users:(("nginx",pid=1042,fd=8))` の形で出ますが、`sudo` なしだと自分の所有でないものは空欄です。
sudo netstat -tulnp | grep ':443 'コンテナや古いイメージ向けの net-tools 版です。フラグの意味は同じで、PID/Program name の列は自分の所有でないソケットには特権が要ります。man ページ自身がこの値は信用できないと付け加えています。パターン末尾の空白は消さないでください。ないと `:443` が、ローカルの TLS テストで非常によく使われる `:4433` や `:44300` にも当たります。
netstat -ano | findstr :443`-a` で TCP・UDP どちらの待ち受けポートも含め、`-n` で数値のまま、`-o` で所有 PID が付き、`tasklist /FI "PID eq 1234"` で名前になります。PID が 4 なら、IIS か別の登録済みアプリケーションのためにカーネルの HTTP.sys ドライバがポートを握っています。kill しようとせず `netsh http show servicestate` で調べてください。`findstr` は部分一致なので `:443` は `:4433` や `:44300` にも当たります。Local Address がきっちり `:443` で終わっているか確かめてください。
`nmap -Pn -p 443 --reason example.com` は TCP 側をカバーします。`open` はハンドシェイクが成立、`closed` はリセットが返ってきた、つまり到達はできるが誰も待ち受けていない、`filtered` はパケットがファイアウォールに吸い込まれたということです。`--reason` は推測ではなく実際に観測されたのがどれかを出しますし、`-sV` を付ければ nmap が TLS をネゴシエートしてサーバーと証明書の情報まで報告します。HTTP/3 を見るなら `nmap -Pn -sU -p 443 example.com` を別に走らせてください。結果は `open|filtered` になるはずです。UDP の沈黙は本質的に曖昧なので、nmap は推測を拒みます。ポートが開いているのに何かが失敗するなら、スキャンをやめて `openssl s_client -connect example.com:443 -servername example.com` を実行してください。証明書チェーンとネゴシエートされたプロトコルバージョン、そしてハンドシェイクがどこで壊れるかがそのまま出ます。スキャンは自分が責任を持つホストにだけ。
| 出ているもの | 意味 |
|---|---|
curl: (60) SSL certificate problem: unable to get local issuer certificate | 接続もハンドシェイクもチェーンの検証まで到達しているので、ポートもネットワークも問題ありません。サーバーが、送るべき中間証明書を送っていません。ブラウザは他のサイトで拾った中間証明書をキャッシュしているのでこれをよく隠してしまい、だから API クライアントや CI ジョブで先に表面化します。検証を飛ばすフラグを足すのではなく、サーバーが提示するチェーンのほうを直してください。 |
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com' | 443 番のサーバーには届いていて、別の名前の証明書が返ってきました。たいていは SNI です。クライアントがホスト名を送っていないか、その名前が設定されていないのでリクエストが既定のバーチャルホストに落ちています。`openssl s_client -connect <ip>:443 -servername example.com` と、`-servername` なしの同じコマンドを見比べれば正確に再現できます。 |
curl: (35) error:0A000410:SSL routines::sslv3 alert handshake failure | TCP は成功し、TLS は失敗しました。両者に共通して使えるプロトコルバージョンか暗号スイートがありません。典型的なのは、TLS 1.0 と 1.1 を無効にしたサーバーに古いクライアントが当たったケースか、提示されなかったクライアント証明書をサーバーが要求しているケースです。直すべきはポートではなくネゴシエーションの条件です。 |
curl: (7) Failed to connect to example.com port 443: Connection refused | リセットが即座に返ってきた、つまりホストは生きていて 443 番は誰も持っていません。Web サーバーかロードバランサーが停止しているか、80 番でしか待ち受けていないか、ループバックにバインドしています。ファイアウォールを疑う前に、サーバー側で自分の環境のコマンドを実行してバインドアドレスを読んでください。 |
The browser hangs and finally shows ERR_CONNECTION_TIMED_OUT | 何も答えていないので、フィルタが拒否ではなく破棄をしています。クラウドのセキュリティグループ、ホスト上のファイアウォール、あるいはネットワーク ACL です。長い待ち時間が目印で、拒否なら即座に返ります。ルールはクライアント側の方向からも確認してください。自分側の送信ルールは、相手側の受信ルールが欠けているのとまったく同じ症状を出します。 |
listen EADDRINUSE :::443, or EACCES permission denied on 443 | 見た目が似ているだけの、別々の二つの問題です。EADDRINUSE は別のプロセスがポートを持っているということなので、コマンドを実行してバインドアドレスを読んでください。ワイルドカードのリスナーがいると、どの具体アドレスへの bind も塞がれます。EACCES はポートが特権側だということ。443 番は 1024 未満なので、特権のないプロセスはポートの空きを調べてもらう前に断られます。 |
The site loads but HTTP/3 never engages, or QUIC connections stall and fall back | TCP の 443 番は届くのに UDP の 443 番が届いていません。ファイアウォールやセキュリティグループのルールは TCP しか書かれていないことが多く、その場合ブラウザは QUIC を試し、待たされ、TCP にフォールバックします。原因不明の遅さに見えるのはそのコストです。Linux なら `-u` を、macOS ならプロトコル指定なしでプローブして、UDP 443 を許可するか塞ぐかを意識的に決めてください。 |
IANA は 443 番を TCP・UDP 両方で `https` として登録していて、説明は「TLS/SSL 上の http プロトコル」、根拠は RFC 9110 です。TCP 側は見慣れたほう、つまり TCP 上の TLS で HTTP/1.1 や HTTP/2 を運びます。UDP 側は HTTP/3 が使うもので、QUIC は UDP 上で動き、同じ番号で終端します。ここから実務的な落とし穴が生まれます。サーバーは 443 番で二重に待ち受けられる——トランスポートごとに一つずつ——ので、TCP に絞ったプローブでは半分しか見えません。ブラウザには HTTP/3 で応答が返っているのに `ss -tlnp` の出力が物足りないなら、`-u` を足してください。トランスポートの上、443 番は TLS が行われる場所（TLS 1.3 は RFC 8446）で、現場の混乱をいちばん生む拡張が SNI（RFC 6066）です。クライアントはハンドシェイクの中で目的のホスト名を名乗るので、一つの IP アドレスと一つのポートが、多数の証明書を持つ多数のサイトを提供できます。ネットワーク的には接続に成功しているのに違う証明書が返ってくるのはこのためです。正しいソケットには届いていて、バーチャルホストを外しています。暗号化された DNS も DNS over HTTPS としてここに住んでいますが、これは意図的で、通常の Web トラフィックと区別がつかないことが狙いです。このポートで最良の単一の診断はスキャンではなく `openssl s_client -connect example.com:443 -servername example.com` です。本物のハンドシェイクを最後まで行い、サーバーが実際に送ってきたチェーンを表示します。
ここは出すことが前提のポートなので、セキュリティの論点はどこかに消えるのではなく、レイヤーの上に移ります。受信側のリスクは、その後ろに何がいるかです。期限切れや名前の合わない証明書、同じバーチャルホストの下に公開されている管理画面、TLS を終端して完全には信頼していないネットワークセグメントに平文を流すプロキシ、そして 80 番でも別途到達できてそこでも応答するオリジンサーバー。証明書チェーンは完全に保ってください。中間証明書が欠けていてもキャッシュを持つブラウザでは動き、ブラウザ以外のクライアントでは全部失敗するので、API を壊す手口としてはかなり厄介な部類です。ポリシーが取りこぼしがちなのは送信側です。443 番はどこでも許可されているので、トンネルや VPN、SSH over TLS の既定の抜け道になります。宛先を問わず 443 番を許す送信ルールは、事実上すべてを許すルールです。重要なところでは送信の 443 番も宛先で絞り、脅威モデル上必要なら検査してください。最後に、TCP と UDP の 443 番はどちらも意識的に許可するか、意識的に塞ぐかにしてください。UDP 443 を中途半端に開けておくと、クライアントは HTTP/3 を試して失敗し、誰にも説明できない遅延を抱えたまま黙ってフォールバックします。
どれもブラウザ内で完結します。アップロードは発生しません。
443 を調べているとき、ついでに確認することになりがちなポートです。
ほぼ権限の問題です。lsof や ss はソケット自体は出しますが、他ユーザーのプロセスは所有者の列を伏せるので、システムアカウントやコンテナランタイム、launchd が起動したサーバーは sudo を付け直すまで持ち主不明のリスナーに見えます。Windows は逆で、netstat には何も出ないのに bind だけ失敗します。これは Hyper-V や WSL2、Docker Desktop が起動時に予約したポート帯に当たっている状態です。
何なのかを先に見てください。取り残された開発サーバーなら問題ありませんが、書き込み中のデータベースは別ですし、他が依存しているシステムサービスも同様です。持ち主がコンテナならコンテナごと停止してください。ホストから見えるプロセスを kill してもランタイムが再起動するだけです。どうしても止められないものなら、自分のサービスを別のポートへ移すほうが早く片付きます。
0.0.0.0 ではなく 127.0.0.1 にバインドしているからです。各ページのコマンドがプロセス名と並べてバインド先アドレスを出しているのはこのためで、ループバックにバインドしたものはファイアウォールの設定に関係なく自分のマシンからしか届きません。最近は意図的にそれを既定にしているフレームワークも多いので、たいていはバグではなくフラグの問題です。すでに 0.0.0.0 なのに届かないなら、次に疑うのはホストのファイアウォールかクラウドのセキュリティグループです。
ほとんどなりません。インターネット全体を舐めるスキャナーはポート範囲を丸ごと走査し続けているので、稼げるのは数時間であって安全ではなく、代わりに関係者全員がその番号を覚える羽目になります。既定ポートを狙う無差別スキャンのログが減るという効果は確かにありますが、それだけです。結果を変えるのは認証と、送信元アドレスを絞ったファイアウォールと、そもそも外に出さないことです。
ポート 443 でまだ詰まっていますか。ポート一覧をすべて見る。あるいは上に戻って、実際に出たエラー文から追ってください。