8443
443 の非特権版。一般ユーザーでも bind できるポートで TLS を話すという位置づけで、Tomcat やアプライアンスの管理画面が真っ先に選ぶ番号です。
自分の環境の行をそのまま実行してください。ポートを掴んでいるプロセス名と、バインドしているアドレスが出ます。たいていはそれだけで答えが分かります。
sudo lsof -nP -iTCP:8443 -sTCP:LISTEN`-n` と `-P` でホストもポートも数値のまま、`-iTCP:8443` でポートを選び、`-sTCP:LISTEN` で待ち受け状態に絞ります——この組み合わせは lsof のマニュアル自身が例に使っているものです。PID は二列目、バインドアドレスは最後の列で、`127.0.0.1:8443 (LISTEN)` や `*:8443 (LISTEN)` と出ます。ループバックへの bind は、自分には見えているコンソールに同僚が届かない、いつもの理由です。COMMAND の列が `java` なら、まず間違いなく Tomcat か別のアプリケーションサーバーを見ています。可能ならプロセスではなくサービスとして止めてください。`sudo` を付けないと自分のユーザーが所有するリスナーしか見えませんし、ポートが空いていれば lsof は何も出さずに終了コード 1 で終わります。
sudo ss -tlnp 'sport = :8443'ss(8) のマニュアルによれば、`-t` は TCP ソケットを表示、`-l` は待ち受けのみ、`-n` はサービス名を解決しない、`-p` は所有プロセスを表示です。`sport = :8443` は文書化されたポートフィルタの形式です。Local Address:Port の列が「なぜ他の誰も届かないのか」への答えになります。`127.0.0.1:8443` はこのマシンだけ、`0.0.0.0:8443` は全 IPv4 アドレス、`[::]:8443` は IPv6 のワイルドカードでたいてい IPv4 も覆います。プロセスは `users:(("java",pid=4310,fd=52))` と出ます。`ss` がなければ `netstat -tlnp` が同じ列を出しますし、どちらも自分の所有でないプロセスを名指しするには root が必要です。
openssl s_client -connect host.example.com:8443 -servername host.example.comこちらは別の問いに答えるプローブです。誰がポートを持っているかではなく、それが本当に TLS なのか。`-connect host:port` で相手を選び、`-servername` で SNI 拡張を送ります。バーチャルホストのサーバーは、これがないと正しい証明書を出してくれません。成功すると証明書チェーンとネゴシエートされたプロトコル・暗号スイートが表示され、そのまま入力待ちになります。ハンドシェイクが即座に失敗するなら、リスナーは別のものを話しています。`curl -v http://host.example.com:8443/` で平文の HTTP が答えるか試してください。どの中間証明書が欠けているかを突き止めたいときは `-showcerts` を足します。
netstat -ano | findstr :8443Microsoft は `-a` をすべてのアクティブな接続とコンピューターが待ち受けているポートの表示、`-n` をアドレスとポートの数値表現、`-o` を各接続のプロセス ID を含めること、と説明しています。Local Address の列でバインドアドレスを、State の列で LISTENING を、最後の列で PID を読み、その PID を `tasklist /fi "PID eq 4310"` で解決してください。文書化された `PID` フィルタとその `eq` 演算子を使います。`findstr` は行のどこにあっても部分文字列に一致するので、別のホストの 8443 への確立済みの外向き接続も同じ出力に出てきます。二つを分けるのは State の列です。
Get-NetTCPConnection -LocalPort 8443 | Select-Object LocalAddress,LocalPort,State,OwningProcessPowerShell 版はポートを文字列ではなく数値として一致させるので、行のどこかにたまたま現れた `:8443` を拾うことがありません。`OwningProcess` の値に `Get-Process -Id` をかければ実行ファイルが分かります。これが何も返さないのにサーバーが bind できないなら、占有ではなく予約です。`netsh interface ipv4 show excludedportrange protocol=tcp` が Hyper-V・WSL2・Docker Desktop が起動時に確保する範囲を一覧し、その中のポートは持ち主が見つからないまま bind に失敗します。
`nmap -Pn -p 8443 app.example.com` は、ホストの外側からそのポートがどう見えるかを教えてくれます。ホストの内側から見た姿とは正反対なことがよくあります。`-Pn` はホスト探索を飛ばして対象をオンライン扱いし、`-p` はスキャンをその 1 ポートに限定します。`open` はハンドシェイクが成立して何かが待ち受けているということ。`closed` はホストがリセットを返した、つまり到達はできて誰もポートを持っていないということで、TLS のコネクタのコメントを外し忘れたときに見る状態です。`filtered` はプローブが答えなく消えたということで、ファイアウォールかセキュリティグループが捨てています。どれだったかは `--reason` が出します——open なら `syn-ack`、closed なら `conn-refused`。`-sV` は開いているポートを探ってサービスとバージョンを判定するので、8443 にいるものが本当に TLS を話しているのか、それとも思わせぶりな番号で平文の HTTP を話しているだけなのかを、いちばん早く知る方法になります。スキャンは自分が責任を持つホストにだけ。
| 出ているもの | 意味 |
|---|---|
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version | curl の終了コード 35 は TLS ハンドシェイクの失敗で、その後ろの文言は curl がどの TLS ライブラリでビルドされたかによって変わります。OpenSSL ビルドは同じ事象を別の行で報告します。原因はほぼ必ず、`https://` を要求したのに 8443 のリスナーが平文の HTTP を話していることです。代わりに `http://host:8443/` を取ってみてください。ページが返るならポートは正常で、間違っていたのはスキームです。 |
The browser shows ERR_SSL_PROTOCOL_ERROR | ネットワークエラー -107、`SSL_PROTOCOL_ERROR` に対する Chromium の名前で、上の失敗のブラウザ側の姿です。何かは応答したが、ブラウザが完了できる TLS ハンドシェイクではありませんでした。同じ URL を `http://` で試してください。平文の HTTP で動くなら、番号が何を匂わせていようと、そのサービスはこのポートで TLS を設定していません。 |
NET::ERR_CERT_AUTHORITY_INVALID | Chromium のエラー -202、`CERT_AUTHORITY_INVALID` です。ポートについては朗報で、TLS は動いていて証明書も提示されました。ただそれが、このマシンが信頼するルートまでチェーンしていないだけです——自己署名証明書か、インストールされていないプライベート CA。ネットワークに直すところはありません。証明書をデコードして、その発行者を信頼するかどうかを決めてください。 |
Connection refused on 8443 while 8080 on the same host works | Tomcat の典型的な形です。同梱の `server.xml` は 8443 の TLS コネクタをコメントアウトしたまま、稼働中の 8080 のコネクタに `redirectPort="8443"` を広告させ続けるので、セキュアなチャネルを必須と印を付けたものはすべて、誰も待ち受けていないポートへブラウザを飛ばします。TLS コネクタのコメントを外して設定するか、`redirectPort` を変えてください。 |
Error: listen EADDRINUSE: address already in use 0.0.0.0:8443 | 別のプロセスが既にポートを持っています。8443 は管理インターフェイスを引き寄せるので、居座っているのは自分で起動したものではなく、インストール済みの何かであることが多いです——アプライアンスのエージェント、同じサーバーの前回の実行、まだポートを公開しているコンテナ。何かを kill する前に、自分の環境のコマンドで持ち主を見つけてください。 |
It works on the server itself but times out from anywhere else | 候補は二つで、コマンドの出力が 1 行で分けてくれます。リスナーが経路のあるアドレスではなく `127.0.0.1` に bind しているなら、ローカルアドレスの列がそう言っています。ファイアウォールが SYN を捨てているなら、nmap がそのポートを `closed` ではなく `filtered` と報告します。タイムアウトは破棄、拒否は即座です。 |
8443 は割り当てではなく慣習です。IANA のレジストリにこの番号は載っていますが、相手は `pcsync-https`、つまり「PCsync HTTPS」で、世の中の実際の使われ方とは何の関係もありません。だから 8443 を「登録された HTTPS の代替」と呼ぶのは、レジストリの言い分に照らしても間違いです。この番号が定着した理由は、8080 が定着した理由と同じ算数です。Unix 系では 1024 未満が特権ポートなので、root にならずに TLS を話したいサーバーは 443 に 8000 を足します。いちばん分かりやすいのが Apache Tomcat です。同梱の `server.xml` は、8080 で待ち受ける平文のコネクタに `redirectPort="8443"` を設定し、同じファイルの中に 8443 用の TLS コネクタを——コメントアウトした状態でサンプルのキーストアつきで——抱えています。つまり `https://host:8443/` に飛ばしてくる Tomcat は、誰かがそのリスナーのコメントを外したかどうかに関係なく、既定の設定どおりに動いているだけです。番号そのものが暗号化を意味することはありません。ブラウザが TLS を話すかどうかを決めるのはポートではなく URL のスキームなので、`https://host:8443/` は珍しい番号への普通の HTTPS リクエストで、`http://host:8443/` は普通の平文リクエストです。このポートで最もよくある失敗が、スキームとリスナーの食い違いであるのはこのためです。
「8443 は安全か」の裏には、別々の二つの問いが隠れています。一つ目は、そもそも本当に TLS がいるのか。番号は何も約束しません。8443 で平文の HTTP を返しているサービスは、8080 のものとまったく同じくらい通信路上で丸見えです。決めつけずに確かめてください。`openssl s_client -connect host:8443 -servername host` はハンドシェイクを完了して証明書チェーンを表示するか、即座に失敗してリスナーが TLS を話していないことを教えてくれます。二つ目は、その後ろに何がいるか。このポートが評判を得たのはここです。非特権の HTTPS ポートに落ち着くものは管理系の面が不釣り合いに多く——アプリケーションサーバーのコンソール、アプライアンスの Web UI、ビルドサーバー、監視やサイドカーのエンドポイント——どれも運用者しか見つけないという前提で書かれています。スキャナーは 8443 を 443 とまったく同じように舐めるので、珍しい番号による目くらましは一切効きません。公開するつもりのサービスなら、本物の証明書を持つプロキシで 443 に一度だけ TLS を終端させてください。管理インターフェイスならインターネットから経路を通さないこと。プライベートアドレスに bind し、VPN かアイデンティティ認識型プロキシの後ろに置き、ファイアウォールで送信元アドレスを絞ってください。このポートは内部向けであることが多いぶん自己署名証明書もよく出てきますが、その証明書を検証するのか警告をクリックして通り過ぎるのかは意識して決めてください。通り過ぎる動作は、傍受を通り過ぎる動作と見分けがつきません。
どれもブラウザ内で完結します。アップロードは発生しません。
8443 を調べているとき、ついでに確認することになりがちなポートです。
ほぼ権限の問題です。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 なのに届かないなら、次に疑うのはホストのファイアウォールかクラウドのセキュリティグループです。
ほとんどなりません。インターネット全体を舐めるスキャナーはポート範囲を丸ごと走査し続けているので、稼げるのは数時間であって安全ではなく、代わりに関係者全員がその番号を覚える羽目になります。既定ポートを狙う無差別スキャンのログが減るという効果は確かにありますが、それだけです。結果を変えるのは認証と、送信元アドレスを絞ったファイアウォールと、そもそも外に出さないことです。
ポート 8443 でまだ詰まっていますか。ポート一覧をすべて見る。あるいは上に戻って、実際に出たエラー文から追ってください。