ポート 8443 につながらないときは、「閲覧者側（社内ネットワークやプロキシ）で遮断されている」か「サーバー側で 8443 を待ち受けていない、またはファイアウォールで閉じている」のどちらかです。別の回線（スマートフォンのテザリングなど）から試して結果が変わるなら前者、どこからでもつながらないなら後者で、サーバーに入って ss -tlnp と curl -vk を見れば数分で見分けられます。
結論を先にまとめます。
- 8443 は IANA の登録名では pcsync-https ですが、実際には HTTPS の代替ポートとして広く使われています。Tomcat の TLS、各種機器の管理コンソール、リバースプロキシの管理画面などが既定で使うことが多いポートです。
- 会社や学校のネットワークは 80 と 443 以外の外向き通信を止めている場合があり、その環境では 8443 は「サーバーが正常でも」つながりません。
- サーバー側は、プロセスが 8443 を待ち受けているか（
ss）、OS のファイアウォール（ufw / firewalld）とクラウドのセキュリティグループが 8443 を許可しているか、の 2 点で決まります。 - 開放の具体的な手順は別記事「ポート 8443 を開放する手順」に分けています。この記事は「どこで止まっているか」を見つける手順です。
ポート 8443 とは
ポート 8443 とは、TCP の 8443 番ポートのことで、HTTPS の標準ポート 443 を使えない、または使いたくない場面で代わりに HTTPS を提供するポートとして慣例的に使われています。1024 未満のポートは管理者権限が必要なため、一般ユーザー権限で動くアプリケーションサーバーが TLS を扱うときに 8443 を選ぶのが典型です（HTTP の代替が 8080、HTTPS の代替が 8443、という組み合わせです）。
| 用途の例 | 既定で 8443 を使う理由 |
|---|---|
| Apache Tomcat の HTTPS コネクター | 設定例が 8443 で書かれている（8080 の TLS 版） |
| ネットワーク機器・NAS・UPS などの管理コンソール | 443 を他のサービスに空けておくため |
| リバースプロキシやコンテナー基盤の管理画面 | 公開サイト（443）と管理用（8443）を分けるため |
| 開発環境・ステージング環境 | 本番の 443 と並べて動かすため |
ブラウザーで開くときは https://example.com:8443/ のように URL にポート番号を書きます。443 と違って省略できません。
切り分け手順の全体像
| 手順 | 見るもの | 使うコマンド | 結果の意味 |
|---|---|---|---|
| 1 | 別の回線からつながるか | ブラウザー、curl |
つながれば閲覧者側のネットワークの問題 |
| 2 | サーバーが 8443 を待ち受けているか | ss -tlnp |
出てこなければアプリ側の設定 |
| 3 | OS のファイアウォール | ufw status / firewall-cmd --list-all |
8443/tcp が無ければ閉じている |
| 4 | クラウドのセキュリティグループ | 各クラウドの管理画面 | インバウンドに 8443 が無ければ閉じている |
| 5 | TLS の応答 | openssl s_client、curl -vk |
証明書やプロトコルの不一致を見つける |
手順 1: 閲覧者側の遮断かどうかを見分ける
まず、サーバーをいじる前に接続元を変えて試します。
- スマートフォンのテザリングや自宅の回線など、別のネットワークから同じ URL を開く。
- 社内のプロキシを経由しない端末があれば、そこからも試す。
別の回線でつながるなら、サーバーは正常で、元のネットワーク側（ファイアウォール、プロキシ、フィルタリング）が 8443 を止めています。この場合、サーバー側で直せることはなく、ネットワーク管理者への申請か、サービスを 443 で提供する構成への変更が解決策になります。
Windows の PowerShell なら、閲覧者側の端末から TCP の到達性だけを確認できます。
Test-NetConnection example.com -Port 8443TcpTestSucceeded : False なら、その端末からは TCP の接続自体が通っていません。Linux / macOS では nc（netcat）で同じことができます。
nc -zv example.com 8443手順 2: サーバーが 8443 を待ち受けているか
サーバーに SSH で入り、待ち受け中の TCP ポートを一覧します。
sudo ss -tlnp | grep 8443何も出なければ、アプリケーションが 8443 で起動していません。アプリケーションのログと設定（Tomcat なら server.xml の Connector、Nginx なら listen 行）を確認します。
出てきた場合は、どのアドレスで待ち受けているかを見ます。
| 表示 | 意味 |
|---|---|
0.0.0.0:8443 または *:8443 |
すべてのアドレスで待ち受け（外部から到達できる） |
[::]:8443 |
IPv6 のすべてのアドレス（多くの環境では IPv4 も受ける） |
127.0.0.1:8443 |
ループバックだけ。外部からはつながらない |
127.0.0.1:8443 の場合は、アプリケーションの bind アドレスの設定か、前にリバースプロキシを置いて 443 で受ける構成にします。
サーバー自身からの接続も確認しておきます。
curl -vk https://127.0.0.1:8443/ --connect-timeout 5ここで応答があれば、アプリケーションは動いていて、残る原因はファイアウォールかネットワークです。
手順 3: OS のファイアウォールを確認する
Ubuntu / Debian の ufw と、RHEL 系（AlmaLinux / Rocky Linux）の firewalld で、現在のルールを表示します。
# ufw
sudo ufw status verbose
# firewalld
sudo firewall-cmd --list-all一覧に 8443/tcp が無ければ閉じています。nftables を直接使っている環境では sudo nft list ruleset で確認します。許可の追加は「ポート 8443 を開放する手順」を参照してください。
手順 4: クラウドのセキュリティグループを確認する
VPS やクラウドでは、OS のファイアウォールの外側にもう一層の制御があります。OS 側で開けても、ここが閉じていれば届きません。
| サービス | 確認する場所 |
|---|---|
| AWS EC2 / Lightsail | セキュリティグループ（Lightsail はネットワーキングのファイアウォール）のインバウンドルール |
| Azure | ネットワークセキュリティグループ（NSG）の受信セキュリティ規則 |
| Google Cloud | VPC ファイアウォールルール（上り、対象タグ） |
| 国内の VPS | コントロールパネルのパケットフィルター |
いずれも「TCP 8443、送信元 0.0.0.0/0（または許可したい IP）」の受信ルールがあるかを見ます。
手順 5: TLS の応答を確認する
TCP ではつながるのにブラウザーでエラーになる場合は、TLS の層の問題です。
openssl s_client -connect example.com:8443 -servername example.com </dev/null 2>/dev/null | head -20Verify return code: 0 (ok)以外なら、証明書の期限切れ・ホスト名不一致・自己署名などです。管理コンソールの自己署名証明書はブラウザーの警告を承諾して進む運用が多いですが、公開するサービスなら正規の証明書を入れます。wrong version numberのようなエラーは、8443 で HTTP（平文）が動いているのにhttps://で開いている場合に出ます。逆にhttp://example.com:8443/で開いて文字化けのような応答が返るなら、TLS が動いているのにhttp://で開いています。
WordPress の観点
WordPress の公開サイトは 443 で提供するのが基本で、8443 を使うのは次のような場面に限られます。
- サーバーのコントロールパネルが 8443 で管理画面を出している（Plesk の管理画面が代表例です）。
- 開発用やステージング用の WordPress を、本番と同じサーバーで
https://example.com:8443/として動かしている。 - リバースプロキシの後ろにいる WordPress の「素の」待ち受けが 8443 になっている。
この最後の構成では、WordPress の「サイトアドレス（URL）」は閲覧者が使う 443 の URL（https://example.com）にしておき、プロキシから X-Forwarded-Proto を渡して HTTPS 判定させます。8443 を直接サイトアドレスにすると、ポートを閉じたときにサイト全体がリダイレクトで壊れます。管理画面に入れなくなったときの復旧は「管理画面だけ白くなるときの直し方」も参照してください。
よくある質問
ポート 8443 は危険ですか
ポート番号そのものに危険はありません。問題は、そこで動いているサービス（管理コンソールなど）が外部に公開されていてよいかどうかです。管理用途なら、送信元 IP を絞るか VPN 越しに限定し、公開する必要が無ければ閉じるのが基本です。
社内から 8443 につながらないのに自宅からはつながります
社内ネットワークの出口（ファイアウォールやプロキシ）が 80 と 443 以外を止めている状態です。サーバー側では直せないので、ネットワーク管理者に 8443 の許可を申請するか、サービスを 443 で出す構成に変えます。
サーバーでは 8443 が LISTEN なのに外からつながりません
127.0.0.1:8443 で待ち受けている（外部向けではない）、OS のファイアウォールが閉じている、クラウドのセキュリティグループが閉じている、の 3 つを順に確認します。1 つ目はアプリ側の設定、2 つ目と 3 つ目は許可ルールの追加で解決します。
8443 と 443 の両方で同じサービスを出せますか
出せます。Nginx や Apache で両方の listen を書くか、443 のリバースプロキシから 8443 のアプリケーションへ転送します。閲覧者には 443 の URL を案内し、8443 は内部向けに留めるのが扱いやすい形です。
まとめ
- 8443 は HTTPS の代替ポートで、管理コンソールやアプリケーションサーバーが既定で使うことが多いポートです。
- つながらないときは、別の回線で試して閲覧者側かサーバー側かを決め、サーバー側なら
ss -tlnp→ OS のファイアウォール → クラウドのセキュリティグループ → TLS の応答、の順に見ます。 - 公開サービスは 443 で提供し、8443 は内部向けや管理用に留めると、閲覧者側の遮断の問題を避けられます。
関連記事
- ポート 8443 を開放する手順｜ufw・firewalld・クラウドのセキュリティグループと Nginx / Apache の設定
- ポート 8080 がブロックされて接続できないときの原因と対処
- Nginx のインストール方法と初期設定
- WordPress に Cloudflare を設定する完全ガイド
参考: IANA Service Name and Transport Protocol Port Number Registry、ss(8) – iproute2、Test-NetConnection – Microsoft Learn
更新履歴: 2026-11-09 全面改訂（定型の手順を、閲覧者側とサーバー側を見分ける切り分け手順に置き換え、8443 の用途と WordPress での使われ方を追加）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。