ポート 8080 で動くアプリを 80 / 443 で公開する方法｜ポート番号の変更とリバースプロキシの使い分け

ポート 8080 で動くアプリを http://example.com:8080/ ではなく https://example.com/ で開けるようにするには、アプリのポート番号を 80 に変えるか、Nginx / Apache をリバースプロキシにして 80 / 443 で受けて 8080 へ転送するかの 2 択です。公開するサービスなら後者が基本で、TLS の終端・証明書の更新・複数アプリの同居がまとめて解決します。

結論を先にまとめます。

• 80 や 443 は特権ポート（1024 未満）なので、一般ユーザーで動くアプリが直接使うには root 権限か CAP_NET_BIND_SERVICE が必要です。アプリを root で動かすのは避けたいので、直接 80 に変えるのは単純な構成に限ります。
• リバースプロキシ構成では、アプリは 8080 のまま 127.0.0.1 だけで待ち受け、Nginx / Apache が 443 で TLS を終端して proxy_pass http://127.0.0.1:8080; で転送します。
• Docker なら、ポートの対応付け（-p 80:8080）を変えるだけで、コンテナー内のアプリは触らずに済みます。
• どちらの方法でも、最後に 8080 を外から閉じて、入口を 80 / 443 に一本化します。
• 8080 に接続できない原因の切り分けは「ポート 8080 がブロックされて接続できないときの原因と対処」に分けています。

2 つの方法の比較

方法 1: アプリのポート番号を変える

Tomcat

conf/server.xml の HTTP コネクターの port を変えます。

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

port="8080" を使いたい番号に変えて Tomcat を再起動します。80 にする場合は、次の「特権ポート」の対処が必要です。

Node.js などの環境変数で決まるアプリ

多くのアプリは環境変数 PORT や起動オプションでポートを決めます。systemd で動かしているなら、ユニットファイルの Environment= に書きます。

[Service]
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/app/server.js

アプリごとに決め方が違うので、そのアプリのドキュメントで確認します。

Docker

コンテナー内のアプリは 8080 のままにして、ホスト側のポートだけ変えます。-p ホスト:コンテナー の順です。

docker run -d -p 80:8080 my-app

Docker Compose なら ports: - "80:8080" です。ホスト側を 127.0.0.1:8080:8080 のように書くと、ホストの中からしかつながらなくなり、前に Nginx を置く構成に向きます。

特権ポート（1024 未満）の扱い

root 以外のユーザーが 80 や 443 で待ち受けるには、実行ファイルに capability を付けます。

sudo setcap 'cap_net_bind_service=+ep' /usr/bin/node

これはその実行ファイルで動くすべてのプロセスに特権ポートの使用を許すため、影響範囲を理解したうえで使います。Java のように起動時にラッパースクリプトを経由するものでは効きにくく、結局リバースプロキシのほうが扱いやすいことが多いです。

方法 2: Nginx / Apache をリバースプロキシにする

構成の考え方

閲覧者 ─ 443 ─▶ Nginx / Apache（TLS 終端） ─ 8080 ─▶ アプリ（127.0.0.1 だけで待ち受け）

アプリ側は 127.0.0.1:8080 で待ち受けるように設定し、外からは 8080 に直接つなげない状態にします。

Nginx の設定例

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

http2 on; は Nginx 1.25.1 以降の書き方です（それより前は listen 443 ssl http2;。2026年11月現在、主要ディストリビューションの Nginx は新しい書き方に対応しています）。sudo nginx -t で確認し、sudo systemctl reload nginx で反映します。

Apache の設定例

mod_proxy と mod_proxy_http を有効にします（Debian 系は sudo a2enmod proxy proxy_http ssl）。

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    ProxyPreserveHost On
    ProxyPass        "/" "http://127.0.0.1:8080/"
    ProxyPassReverse "/" "http://127.0.0.1:8080/"
    RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>

RequestHeader には mod_headers が必要です。sudo apachectl configtest で確認して sudo systemctl reload apache2 で反映します。

アプリ側で必要な設定

リバースプロキシの後ろでは、アプリが「自分は HTTP の 8080 で動いている」と思い込み、生成するリンクやリダイレクトが http://example.com:8080/... になることがあります。アプリ側で「プロキシのヘッダーを信頼する」設定（Tomcat の RemoteIpValve、各フレームワークの trusted proxies 設定など）を入れ、X-Forwarded-Proto と X-Forwarded-For を読ませます。

手順: 8080 を外から閉じる

入口を 80 / 443 に一本化したら、8080 への直接アクセスを止めます。

1. アプリの待ち受けを 127.0.0.1 にする（できるアプリなら最も確実です）。
2. OS のファイアウォールで 8080 の許可を外す。

# ufw
sudo ufw delete allow 8080/tcp

# firewalld
sudo firewall-cmd --permanent --remove-port=8080/tcp
sudo firewall-cmd --reload

1. クラウドのセキュリティグループからも TCP 8080 の受信ルールを削除する。
2. 外から nc -zv example.com 8080 を実行し、つながらないことを確認する。

WordPress の観点

WordPress は PHP で動くため、ここで言う「8080 のアプリ」になるのは次の構成です。

• Nginx（443）→ Apache + PHP（8080）: .htaccess を使うプラグインを活かしつつ、Nginx の静的配信やキャッシュを前に置く構成。WordPress には「サイトアドレス（URL）」を https://example.com にし、wp-config.php で X-Forwarded-Proto を見て $_SERVER['HTTPS'] を立てる処理を入れないと、管理画面がリダイレクトループになります。
• Docker の WordPress（-p 8080:80）: 開発用途ならそのまま、公開するなら上の Nginx 構成の後ろに置きます。

WordPress 単体なら、Apache か Nginx で PHP-FPM を直接動かすほうが層が少なく、トラブルも少ないです。両者の違いは「Apache と Nginx の違いと使い分け」にまとめています。

よくある質問

アプリのポートを 80 にしたら「Permission denied」で起動しません

1024 未満のポートは特権ポートで、一般ユーザーでは待ち受けられません。setcap で capability を付けるか、root で動かすか、リバースプロキシで受けるかのいずれかです。公開サービスならリバースプロキシを選びます。

リバースプロキシの後ろでリンクが http://example.com:8080 になります

アプリが自分の URL を待ち受けポートから組み立てているためです。X-Forwarded-Proto と X-Forwarded-Host をプロキシから渡し、アプリ側でそれを信頼する設定を入れます。アプリに「公開 URL」を直接設定できる項目があれば、そこに https://example.com を書きます。

8080 を閉じると管理用に使えなくなりませんか

サーバーの中からは 127.0.0.1:8080 で引き続き使えます。外から管理用に使いたいときは、SSH のポートフォワーディング（ssh -L 8080:127.0.0.1:8080 user@example.com）で自分の PC の 8080 に引き込むと、公開せずに使えます。

Docker で -p 80:8080 にしたら「port is already allocated」と出ます

ホストの 80 を別のプロセス（Nginx や Apache など）がすでに使っています。その場合はコンテナーは 8080 のままにして、ホストの Nginx からコンテナーへ転送する構成にします。

まとめ

• 8080 のアプリをポート番号無しで公開するには、アプリのポートを 80 に変えるか、Nginx / Apache で 443 を受けて 8080 へ転送します。公開サービスは後者が基本です。
• リバースプロキシ構成では、アプリを 127.0.0.1:8080 に限定し、X-Forwarded-Proto などのヘッダーをアプリに信頼させます。
• 最後に OS とクラウドの両方で 8080 を閉じ、入口を 80 / 443 に一本化します。

関連記事

• ポート 8080 がブロックされて接続できないときの原因と対処
• ポート 8443 を開放する手順
• Caddy でリバースプロキシを設定する方法
• Apache と Nginx の違いと使い分け

参考: Nginx – ngx_http_proxy_module、Apache – Reverse Proxy Guide、Docker – Publishing and exposing ports、capabilities(7)

更新履歴: 2026-11-09 全面改訂（定型の手順を、ポート変更とリバースプロキシの比較・設定例・8080 を閉じる手順に置き換え、WordPress での構成例を追加）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。