ルーターのポートフォワーディングが機能しない「Connection Refused」を修正する

状況

ルーターにポート転送を設定し、サーバーのローカルIPに向けて外部からテストした――しかし何も起きない。Connection refused、タイムアウト、あるいは接続がただハングする。サービスはLAN内では完璧に動いているのに、外部からのトラフィックは一切通らない。

腹立たしいのは、ルーターの管理パネルでは全て正しく見えることだ。ルールはある。IPも合っている。それでも動かない。実際に何が壊れているかを見つける方法を紹介する。

ステップ1：サービスが正しくリッスンしているか確認する

まだルーターには触れないこと。まず、アプリケーションが正しいアドレスとポートでリッスンしているかを確認する。

# Linux/macOSの場合
ss -tlnp | grep 8080

# または netstat を使う
netstat -tlnp | grep 8080

# Windows
netstat -ano | findstr :8080

以下のような出力が得られるはずだ：

tcp   0.0.0.0:8080   LISTEN   12345/node

0.0.0.0:8080ではなく127.0.0.1:8080と表示されている場合、そのサービスはローカル接続しか受け付けていない――ルーターからのトラフィックはアプリに届く前に破棄される。アプリの設定を変更して0.0.0.0または特定のLANインターフェースにバインドするよう修正すること。

ステップ2：ルーターを責める前にローカルでテストする

同じLAN上の別のデバイスから、サーバーのプライベートIPに直接接続してみる：

# LAN上の別のマシンから
curl http://192.168.1.100:8080

# またはTCP接続だけをテスト
nc -zv 192.168.1.100 8080

これが失敗する場合、問題はローカルにある――ファイアウォールか設定ミスのあるサービスだ。まずここを修正すること。内部からサーバーへのトラフィックすら届かない状態でルーターをデバッグしても意味がない。

ステップ3：ルーターのポート転送ルールを確認する

ルーターにログインし（通常は192.168.1.1または192.168.0.1）、各フィールドを丁寧に確認する：

• 外部ポート：外部クライアントが接続するポート
• 内部IP：サーバーの固定ローカルIP――変わる可能性のあるDHCP割り当てIPではなく
• 内部ポート：アプリが実際にリッスンするポート（外部ポートと異なっていても良い）
• プロトコル：TCP、UDP、または両方――WebサーバーにはTCP、ゲームサーバーにはUDPが必要な場合がある
• ルールが有効になっているか：一部のルーターでは無効な状態でルールを保存できる

最もよくある落とし穴はIPのズレだ。先週DHCPがサーバーに192.168.1.105を割り当て、再起動後に192.168.1.112に再割り当てされた――これで転送ルールは間違ったマシンを指すことになる。サーバーに固定IPを設定するか、ルーターでDHCPリザベーションを使い、常に同じアドレスが割り当てられるようにすること。

ステップ4：サーバー自身のファイアウォールを確認する

ポート転送はトラフィックをマシンまで届ける。しかしローカルファイアウォールがその後で静かにパケットを破棄することがある。ポートを確認して開放する：

# UFW (Ubuntu/Debian)
sudo ufw status
sudo ufw allow 8080/tcp

# firewalld (CentOS/RHEL/Fedora)
sudo firewall-cmd --list-ports
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

# iptables (直接)
sudo iptables -L INPUT -n | grep 8080
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

# Windows Defender Firewall
netsh advfirewall firewall add rule name="Allow 8080" protocol=TCP dir=in localport=8080 action=allow

ステップ5：実際の外部ネットワークからテストする

自分のLAN内からテストしても意味がない――ほとんどの家庭用ルーターはNATヘアピニングをサポートしていないため、誤った結果が出る。モバイルデータ通信中のスマートフォン、安価なクラウドVM、またはオンラインのポートチェッカーを使うこと。

# まず自分のパブリックIPを確認する
curl ifconfig.me
# または
curl https://api.ipify.org

# 次に外部からテストする
curl http://YOUR_PUBLIC_IP:8080
nc -zv YOUR_PUBLIC_IP 8080

エラーをよく読むこと。タイムアウトはファイアウォールが上流でパケットを破棄していることを意味する――ルーターのファイアウォール、ISP、またはOSのファイアウォール。Connection refusedはトラフィックがマシンには届いているが、アプリケーション層で何かが拒否していることを意味する。

ステップ6：ダブルNATを確認する

ISPからのモデム/ルーター一体型デバイスに加え、自分のルーターをその背後に接続している場合、ダブルNATの状態になっている。自分のルーターでポートを転送しても、ルーターのWANポートまでしか届かない――ISPのデバイスがインターネットからのトラフィックを依然としてブロックしている。

# 経路をトレースする
traceroute 8.8.8.8

# プライベートIPホップが2つある場合（例：192.168.0.1 → 10.0.0.1）？
# それがダブルNATだ。

最もクリーンな解決策は、ISPのデバイスをブリッジモードに設定してNATを完全に停止させることだ。それ以外の場合、両方のデバイスにポート転送ルールが必要になる――ISPのモデムが自分のルーターのWAN IPに転送し、さらに自分のルーターがサーバーに転送する。モデムの管理パネルがロックされている場合はISPに連絡すること。

ステップ7：CGNATを確認する

これは意表を突かれることが多い。多くのISP――特にモバイル/4Gプロバイダー――はキャリアグレードNATを使用しており、「パブリック」IPが実際には数千の顧客と共有されている。その場合、インバウンド接続を受け付けることは文字通りできない。ポート転送は機能しない、それだけだ。

# これらの2つを比較する：
curl ifconfig.me          # 見かけ上のパブリックIP
# 対して、管理パネルに表示されるルーターのWAN IP

# 異なっていれば、CGNATの背後にいる。

ルーターのWAN IPが以下のいずれかの範囲に該当する場合、それが確認となる：

100.64.0.0/10   (CGNATの範囲、RFC 6598)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

選択肢：ISPに本物のパブリックIPを申請する（無料で提供するところもあれば、月額5〜10ドル程度かかるところもある）、ポート転送をサポートするVPNサービスを使う（Mullvad、AirVPN）、またはCloudflare Tunnelやngrokのようなトンネルで問題を回避する。

確認

修正を適用した後、実際の外部ネットワークから確認する：

# モバイルデータまたはクラウドVMから
curl -v http://YOUR_PUBLIC_IP:8080

# 期待される結果：アプリからのHTTPレスポンス
# 良くない結果："Connection refused" またはハング

ルーターのファイアウォール/NATログも確認すること――ほとんどのルーターはパケットが転送ルールにヒットしたかどうかを記録しており、トラフィックがどこまで届いているかを正確に把握できる。

ヒント

NATとサブネットの問題を追いかけているとき、私はToolCraftのSubnet Calculatorをタブで開いたままにしている。サーバーのLAN IPが実際にルーターのローカル範囲内に収まっているかを素早く確認するのに便利だ――既にイライラしているときはサブネットマスクの計算ミスが起きやすい。ブラウザ上で動作し、何もアップロードされない。

ルーターの設定に深入りする前に、簡単なサニティチェックをいくつか：

• サーバーがルーターのLANインターフェースと同じサブネット上にあることを確認する（例：どちらも192.168.1.0/24上にある）
• サーバーのデフォルトゲートウェイがルーターを指していることを確認する――残っている静的ルートではなく
• ip route（Linux）またはroute print（Windows）を実行して、トラフィックが別のインターフェースから抜け出していないことを確認する

予防策

• ポート転送するサーバーには必ず固定IPまたはDHCPリザベーションを割り当てること――IPが変わるとルールが静かに壊れる
• ポート転送のルールをどこかに書き留めておくこと。ルーターのリセットやファームウェアのアップデートで消去されてしまい、6ヶ月後には自分が何を設定したか忘れてしまう
• 長期的な安定したリモートアクセスには、個別のポートを開けるよりWireGuard VPNの方が優れている――攻撃されにくく、監査も容易で、制限の厳しいネットワーク上でも動作する
• 変更を加えた後は必ず自分のネットワークの外部から確認すること。NATループバックの問題により、同じLAN内からテストすると誤った結果が得られる