ファイアウォールでポートを開放する手順（ufw・firewalld・クラウドのセキュリティグループ）

ポートを開放して外から接続できるようにするには、「サービスがそのポートで待ち受けている」「サーバーOSのファイアウォールが許可している」「クラウドやVPS事業者側のフィルターが許可している」の3層をそろえる必要があります。どれか1つでも閉じていれば接続できません。この記事では、ufw（Ubuntu/Debian）と firewalld（RHEL系）でポートを開ける手順に加え、見落としやすいクラウド側の設定と、外部からの疎通確認までを順に説明します。

なお、接続元IPを絞り込む・既定で拒否するといった「アクセス制御の設計」は別の話題として扱う範囲が広いため、この記事では「必要なポートを正しく開ける」ことに焦点を絞ります。

作業前に決めておくこと

ポート開放は、手順そのものより「何を、誰に向けて開けるか」を先に決めるほうが大切です。作業前に次の3点をメモしておくと、開けすぎや開け忘れを防げます。

• ポート番号とプロトコル（TCPかUDPか）。Webなら 80/tcp と 443/tcp、HTTP/3 を使うなら 443/udp も対象です
• 接続を許可する相手。全世界に公開するのか、特定のIPアドレスだけなのか
• 作業中に締め出されたときの復旧手段。VPSやクラウドの管理画面にあるコンソール機能（ブラウザから操作できる画面）が使えるかを事前に確認します

SSHで接続したままファイアウォールを操作する場合は、SSHのポートを許可する前にファイアウォールを有効化しないことが最大の注意点です。順番を誤ると、その瞬間に接続が切れて戻れなくなります。作業中はSSHのセッションをもう1つ開いておき、新しい接続が通るかを別セッションで確かめながら進めると安全です。

ステップ1：サービスが待ち受けているか確認する

ファイアウォールを開ける前に、そもそもサービスがそのポートで待ち受けているかを確認します。ここが抜けていると、ファイアウォールをいくら触っても接続できません。

# TCPで待ち受けているポートとプロセス
sudo ss -tlnp

# UDPの場合
sudo ss -ulnp

出力の「Local Address:Port」の列を見ます。0.0.0.0:443 や [::]:443 なら全インターフェースで待ち受けており、外部から届く状態です。一方 127.0.0.1:3306 のようにループバックアドレスになっている場合、そのサービスはサーバー内部からの接続しか受け付けません。この場合はファイアウォールではなく、サービス側の設定（MySQLなら bind-address など）を変える必要があります。ただし、データベースのように本来は内部だけで使うサービスを外に出すのは慎重に判断してください。

ステップ2：OSのファイアウォールでポートを開ける

ufw（Ubuntu / Debian）の場合

まず現在の状態を確認します。

sudo ufw status verbose

「Status: inactive」なら ufw は無効です。有効化する前に、SSHを許可するルールを先に追加します。

# 先にSSHを許可（ポートを変更している場合はその番号に）
sudo ufw allow 22/tcp

# Web用のポートを開ける
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 特定のIPアドレスからだけ許可する例
sudo ufw allow from 203.0.113.10 to any port 8080 proto tcp

# ルールを確認してから有効化
sudo ufw show added
sudo ufw enable

ufw allow 443 のようにプロトコルを省略するとTCPとUDPの両方が開きます。意図しないUDPを開けないよう、/tcp を付けて書く習慣をつけておくと安心です。

ufw にはアプリケーションプロファイルという仕組みもあり、sudo ufw app list で使える名前を確認できます。Nginx や Apache をパッケージで入れると「Nginx Full」のようなプロファイルが追加されることがありますが、名前や中身はパッケージによって異なるため、sudo ufw app info "プロファイル名" で対象ポートを確かめてから使ってください。

不要になったルールは番号付きで表示してから削除します。

sudo ufw status numbered
sudo ufw delete 3

firewalld（RHEL / AlmaLinux / Rocky Linux など）の場合

firewalld は「ゾーン」単位でルールを管理します。まず、ネットワークインターフェースがどのゾーンに属しているかを確認します。

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

firewalld には、すぐ反映されるが再起動で消える「ランタイム設定」と、再起動後も残る「永続設定」の2種類があります。ランタイムで試し、問題がなければ永続化する流れがおすすめです。

# まずランタイムで開けて動作確認
sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --zone=public --add-port=8080/tcp

# 問題なければ現在のランタイム設定を永続設定に保存
sudo firewall-cmd --runtime-to-permanent

# 最初から永続設定に書く場合は --permanent を付けて reload
sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

よくあるつまずきは、--permanent を付けて追加したのに --reload を忘れ、「設定したのに開かない」と悩むケースです。逆に --permanent を付けずに追加して満足し、再起動後に閉じてしまうケースもあります。--list-all と --list-all --permanent の両方を見比べると、どちらの状態かが分かります。

ufw と firewalld を同時に使わない

1台のサーバーで ufw・firewalld・手書きの iptables / nftables ルールを混在させると、どのルールが効いているのか分からなくなります。ディストリビューションの標準に合わせて1つに決め、ほかは無効にしておくのが基本です。

ステップ3：クラウド・VPS側のフィルターを確認する

OSのファイアウォールを開けても接続できないとき、原因として多いのがサーバーの外側にあるフィルターです。

• AWS EC2：インスタンスに割り当てたセキュリティグループのインバウンドルール。サブネットのネットワークACLを使っている場合は、ACLはステートレスなので戻りの通信（エフェメラルポート）も許可が必要です
• Google Cloud：VPCファイアウォールルール。ネットワークタグやサービスアカウントで対象インスタンスが絞られていることがあります
• Microsoft Azure：ネットワークセキュリティグループ（NSG）。サブネットとNICの両方に割り当てられている場合は両方で許可が必要です
• 国内のVPS：事業者によっては管理画面に「パケットフィルター」や「セキュリティグループ」といった名前の機能があり、初期状態でSSH以外を閉じていることがあります

画面の名前や初期設定は事業者ごとに異なり、変更されることもあります（2026年10月現在）。契約しているサービスのマニュアルで、サーバー外側のフィルターの有無を確認してください。

また、自宅や社内からの確認では、接続元のネットワーク側で通信が止められていることもあります。たとえば国内のプロバイダーでは、迷惑メール対策として外向きの25番ポートを制限する「OP25B」が一般的です。サーバー側をいくら開けても、こうした接続元側の制限は解消できません。

ステップ4：外部から疎通を確認する

確認は、サーバー自身からではなく外部のマシンから行います。サーバー内から自分のグローバルIPに接続すると、経路によってはファイアウォールを通らずに成功してしまい、正しい判断ができないためです。

# ポートに接続できるか（ncはnetcat）
nc -zv example.com 443

# HTTP(S)の応答まで確認
curl -sv -o /dev/null https://example.com/

# 自分が管理するサーバーに対してだけ実行すること
nmap -Pn -p 22,80,443 example.com

結果の読み方として、次の2つの違いを押さえておくと切り分けが速くなります。

• 「Connection refused」がすぐ返る：通信はサーバーまで届いていますが、そのポートで待ち受けているプロセスがないか、ファイアウォールが拒否（REJECT）しています。ステップ1の待ち受け確認に戻ります
• 応答がなくタイムアウトする：途中のどこかで通信が破棄（DROP）されています。OSのファイアウォール、クラウドのセキュリティグループ、接続元ネットワークの順に疑います

nmap の結果が「filtered」ならタイムアウト側、「closed」ならRefused側とほぼ同じ意味です。なお、他人のサーバーへのポートスキャンはトラブルの原因になるため、自分が管理しているサーバーにだけ実行してください。

Dockerを使っている場合の注意

Docker でコンテナのポートを -p 8080:80 のように公開すると、Docker は独自の iptables ルールを追加します。このため ufw で閉じたつもりのポートが外から開いている、ということが起こります。外部に出したくないコンテナは -p 127.0.0.1:8080:80 のようにループバックに限定し、手前のリバースプロキシ経由で公開する構成にしておくと安全です。

開けたあとの点検

ポートを開けたら、それで終わりにせず次の点を見直しておくと、後からの事故を減らせます。

• データベース（3306）、Redis（6379）、管理画面用のポートなど、本来は内部だけで使うものを全世界に開けていないか
• 一時的に開けたテスト用のポートが残っていないか
• 変更内容（いつ、何のために、どのポートを開けたか）を作業記録に残したか

設定変更の前には、現在のルールを sudo ufw status numbered や sudo firewall-cmd --list-all --permanent の出力として保存しておくと、元に戻すときの手がかりになります。本番環境で大きく変える場合は、同じ構成の検証環境で先に試すのが理想です。

まとめ

• ポート開放は「サービスの待ち受け」「OSのファイアウォール」「クラウド・VPS側のフィルター」の3層をそろえて初めて通ります
• ufw では有効化の前にSSHを許可し、プロトコルを明示して開けます。firewalld はランタイムと永続設定の違いに注意します
• 疎通確認は外部から行い、「Refused」と「タイムアウト」の違いで原因の層を切り分けます
• Docker の公開ポートは ufw のルールを迂回することがあるため、公開範囲をコンテナ側でも制限します
• 内部用のポートを開けすぎていないか、作業後に点検します

• AWS EC2 のセキュリティグループを設定する方法
• nmap で開いているポートを確認する方法