2026年9月25日
2026年9月25日
ポート 8080 がブロックされて接続できないときの原因と対処|URL の書き方・待ち受けアドレス・ファイアウォール・企業ネットワークの遮断
ポート 8080 に接続できない原因は、ほとんどが 「URL に :8080 を付けていない」「アプリが 127.0.0.1 だけで待ち受けている」「ファイアウォールが 8080 を閉じている」「会社や学校のネットワークが 8080 を止めている」の 4 つです。サーバーに入って ss -tlnp を見れば、最初の 3 つはすぐに見分けられます。
結論を先にまとめます。
- 8080 は HTTP(80)の代替ポートで、Tomcat・開発サーバー・プロキシソフトが既定で使います。ブラウザーは
http://example.com:8080/のようにポート番号を書かないと 80 につなぎに行きます。 - アプリケーションが
127.0.0.1:8080で待ち受けていると、同じサーバーの中からしかつながりません。外から使うには0.0.0.0にするか、前に Nginx / Apache を置いて 80 / 443 で受けます。 - OS のファイアウォール(ufw / firewalld)とクラウドのセキュリティグループの両方で 8080 が許可されている必要があります。
- 会社・学校・公衆 Wi-Fi は 80 と 443 以外を止めていることがあります。この場合はサーバー側では直せません。
- 8080 のアプリを 80 / 443 で公開する方法は「ポート 8080 で動くアプリを 80 / 443 で公開する方法」に分けています。
ポート 8080 とは
ポート 8080 とは、TCP の 8080 番ポートで、管理者権限が無くても使える HTTP の代替ポートとして広く使われています。1024 未満のポート(80 や 443)を使うには root 権限が必要なため、一般ユーザーで動くアプリケーションサーバーや開発用サーバーは 8080 を既定にしていることが多いです。HTTP の代替が 8080、HTTPS の代替が 8443 という組み合わせで覚えると分かりやすいです。
| 8080 を既定で使うものの例 | 備考 |
|---|---|
| Apache Tomcat | server.xml の HTTP コネクター |
| Jenkins、各種 Java 製アプリ | 組み込みサーブレットコンテナー |
| 開発用サーバー(Node.js、Python、PHP の組み込みサーバーなど) | 設定や環境変数で変えられる |
| HTTP プロキシ(Squid など) | 旧来の既定が 8080 だったことから |
Docker コンテナーのポート公開(-p 8080:80) |
ホスト側 8080 → コンテナー 80 の対応付け |
原因 1: URL にポート番号を書いていない
一番多い原因です。ブラウザーに example.com とだけ入れると、http://example.com/(80 番)につなぎます。8080 で動いているサービスには、ポート番号を明示します。
http://example.com:8080/
http://192.0.2.10:8080/
https://example.com:8080/ のように https:// を付けると、平文の HTTP しか話せない 8080 では「安全な接続ができませんでした」のようなエラーになります。8080 で動くものはたいてい HTTP なので http:// で開きます。
原因 2: アプリが 127.0.0.1 だけで待ち受けている
サーバーで待ち受け状態を確認します。
sudo ss -tlnp | grep 8080
| 表示 | 意味 | 対処 |
|---|---|---|
0.0.0.0:8080 / *:8080 / [::]:8080 |
すべてのアドレスで待ち受け | 外からつながる。次の原因へ |
127.0.0.1:8080 |
ループバックだけ | アプリの bind 設定を変えるか、前にリバースプロキシを置く |
| 何も出ない | 8080 で動いていない | アプリの起動状態とログ、ポート設定を確認 |
開発用サーバーは安全のために既定で 127.0.0.1(または localhost)だけで待ち受けるものが多く、外から使うには起動オプションで 0.0.0.0 を指定します。ただし、認証の無い開発サーバーをそのまま外に向けるのは避け、実際には Nginx / Apache の後ろに置いて公開するのが基本です。
サーバー自身から確認するには次のようにします。
curl -I http://127.0.0.1:8080/ --connect-timeout 5
ここで応答があるのに外からつながらないなら、原因は 3 以降です。
原因 3: 別のプロセスが 8080 を使っている
アプリの起動ログに Address already in use と出ているときは、別のプロセスがすでに 8080 を使っています。何が使っているかを調べます。
sudo ss -tlnp | grep 8080
users:(("java",pid=1234,fd=56)) のように表示されるプロセス名と PID から、競合している相手が分かります。不要なものなら止め、必要なものなら片方のポートを変えます。Docker で -p 8080:80 を複数のコンテナーに指定したときにもこの状態になります。
原因 4: ファイアウォールが 8080 を閉じている
OS のファイアウォールとクラウドのセキュリティグループの 2 層を確認します。
# Ubuntu / Debian
sudo ufw status verbose
# RHEL 系
sudo firewall-cmd --list-all
一覧に 8080/tcp が無ければ閉じています。許可の追加は次のとおりです。
# ufw
sudo ufw allow 8080/tcp
# firewalld
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
クラウド(AWS のセキュリティグループ、Azure の NSG、Google Cloud の VPC ファイアウォール、国内 VPS のパケットフィルター)では、受信(インバウンド)で TCP 8080 を許可するルールが別に必要です。許可する送信元は、公開するものでなければ自分の拠点の IP に絞ります。
原因 5: 閲覧者側のネットワークが 8080 を止めている
サーバー側がすべて正常でも、会社・学校・公衆 Wi-Fi などの出口が 80 と 443 以外の通信を止めている場合、8080 にはつながりません。見分け方は別の回線から試すことです。スマートフォンのテザリングで開けるのに社内から開けないなら、この原因です。
Windows の PowerShell で TCP の到達性だけを確認できます。
Test-NetConnection example.com -Port 8080
Linux / macOS では nc -zv example.com 8080 です。TcpTestSucceeded : False や Connection refused / timed out なら、その端末からは TCP の接続が通っていません。
この原因はサーバー側では直せないため、対処は 2 つです。
- ネットワーク管理者に 8080 の許可を申請する。
- サービスを 80 / 443 で提供する(Nginx / Apache のリバースプロキシで 8080 のアプリを 443 に載せる)。公開サービスなら 2 が基本です。
WordPress の観点
WordPress で 8080 が登場するのは、主に次の 2 つの場面です。
- Docker や開発環境: 公式の WordPress イメージを
-p 8080:80で起動し、http://localhost:8080/で開く構成。別の PC から開けないのは、Docker のポート公開が127.0.0.1に限定されているか、PC のファイアウォールが原因です。 - リバースプロキシの後ろ: Nginx が 443 で受け、後ろの Apache + WordPress が 8080 で動く構成。この場合、閲覧者が 8080 に直接つなぐ必要はなく、むしろ 8080 は外から閉じておきます。WordPress の「サイトアドレス(URL)」は 443 側の URL にし、
X-Forwarded-Protoで HTTPS を判定させます。ここを間違えるとリダイレクトループになります。
WordPress の URL 設定を誤って管理画面に入れなくなったときは、wp-config.php に WP_HOME と WP_SITEURL を一時的に書いて復旧できます。詳しくは「localhost でログインできないときの対処」を参照してください。
よくある質問
localhost:8080 は開けるのに IP アドレス:8080 では開けません
アプリが 127.0.0.1 だけで待ち受けている状態です。ss -tlnp で 127.0.0.1:8080 と出ていればそれが原因で、アプリの bind アドレスを 0.0.0.0 にするか、Nginx / Apache を前に置きます。
8080 は危険なポートですか
ポート番号に危険はありません。そこで動くサービスに認証が無い、開発用のまま公開されている、といった状態が危険です。公開する必要が無ければ閉じ、公開するなら 443 で TLS をかけて出します。
8080 を開けたのに「接続が拒否されました」と出ます
Connection refused は「サーバーには届いたが、そのポートで誰も待ち受けていない」ときの応答です。ファイアウォールではなく、アプリが起動していないか別のポートで動いています。ss -tlnp で確認してください。timed out ならファイアウォールか経路の問題です。
https://example.com:8080 でエラーになります
8080 で動いているのが平文の HTTP なら http:// で開きます。HTTPS で出したいなら、8443 で TLS を設定するか、Nginx / Apache で 443 に載せます。
まとめ
- 8080 に接続できないときは、URL の
:8080、ss -tlnpの待ち受けアドレス、ポートの競合、OS とクラウドのファイアウォール、閲覧者側のネットワーク、の順に確認します。 Connection refusedは待ち受けの問題、timed outはファイアウォールか経路の問題、と応答の違いで原因を絞れます。- 公開サービスは 80 / 443 で提供し、8080 はサーバー内部やリバースプロキシの後ろに留めると、閲覧者側の遮断の問題を避けられます。
関連記事
- ポート 8080 で動くアプリを 80 / 443 で公開する方法|ポート番号の変更とリバースプロキシ
- ポート 8443 とは|HTTPS の代替ポートの用途と、ブロックされてつながらないときの切り分け手順
- localhost でログインできないときの対処
- Apache と Nginx の違いと使い分け
参考: ss(8) – iproute2、ufw – Ubuntu Server documentation、Docker – Publishing and exposing ports、Test-NetConnection – Microsoft Learn
更新履歴: 2026-11-09 全面改訂(定型の手順を、接続できない原因 5 つの切り分けに置き換え、Connection refused と timed out の違い、WordPress の Docker・リバースプロキシ構成での注意を追加)。この記事はワードプレス博士(ライトセンド株式会社)が運営しています。