2026年6月4日

Loopback の競合を解消する方法｜127.0.0.1 のポート重複・localhost の IPv6 解決・lo に載せた VIP の衝突

IPアドレス・ルーティング

ループバック（127.0.0.1 や ::1、lo インターフェース）での「競合」は、ほとんどが次のどれかです。同じアドレスとポートを2つのプロセスが取り合っている、localhost が IPv4 と IPv6 のどちらに解決されるかが食い違っている、ロードバランサー用に lo へ載せたアドレスが ARP で外に漏れている、ルーターのループバックアドレス（ルーターID）が重複している。この記事では、エラーメッセージやログから症状を読み、起きやすい順に原因を確認して直す手順を説明します。WordPress のサイトヘルスで出る「ループバックリクエスト」の失敗についても、最後に切り分け方をまとめます。

作業はサーバーの設定を変えるものを含みます。変更前に設定ファイルを控え、可能であれば検証環境で試してから本番に反映してください。

まず症状を読む

競合の種類は、出ているメッセージでおおよそ見分けられます。

bind() to 127.0.0.1:8080 failed (98: Address already in use) のような表示、または起動直後にサービスが落ちる → ポートの取り合い（次の章）
curl http://localhost:3000 だけが失敗し、curl http://127.0.0.1:3000 は成功する → localhost の解決先の食い違い
負荷分散の構成で、特定のサーバーにだけ通信が偏る、ゲートウェイの ARP テーブルに同じアドレスで複数の MAC が見える → lo に載せた VIP の ARP 漏れ
OSPF や BGP のログに、ルーター ID の重複を示す警告が出る、隣接が張れたり切れたりを繰り返す → ループバックアドレス（ルーターID）の重複

原因1：127.0.0.1 のポートを別のプロセスが使っている

もっとも多いのがこれです。開発用のサーバー、データベース、キャッシュ、DNS などは 127.0.0.1 だけで待ち受けることが多く、同じポートを使うものを後から入れると起動に失敗します。

確認

# 待ち受け中の TCP/UDP と、そのプロセスを表示（プロセス名の表示には root が必要）
sudo ss -ltnup | grep ':8080'

# lsof が入っていれば、ポートからプロセスを引く
sudo lsof -i :8080

Windows では netstat -ano | findstr :8080 で PID を調べ、タスクマネージャーやPowerShellの Get-Process -Id <PID> で何のプロセスかを確かめます。

注意したいのは、0.0.0.0:8080（すべての IPv4 アドレス）で待ち受けているプロセスがいると、127.0.0.1:8080 で待ち受けようとする別のプロセスも基本的に失敗する点です。ss の表示で 127.0.0.1 だけを探していると見落とします。

よくある例：ポート53と systemd-resolved

Ubuntu などで systemd-resolved が有効な場合、127.0.0.53 の 53 番ポートでスタブリゾルバーが待ち受けています。そこへ dnsmasq や Unbound、BIND を入れて全アドレスの 53 番で待ち受けさせると競合します。直し方は2通りです。

新しく入れる DNS サーバーを、特定のアドレス（たとえば LAN 側のアドレスや 127.0.0.1）だけで待ち受けるように設定する
systemd-resolved のスタブリスナーを止める（/etc/systemd/resolved.conf の DNSStubListener=no）。ただしこの場合、/etc/resolv.conf が 127.0.0.53 を指したままだと名前解決が止まるので、参照先も合わせて見直します

後者はサーバー全体の名前解決に関わる変更です。SSH 接続を残したまま作業し、変更後に resolvectl status と実際の名前解決を確かめてから切断してください。

直し方の考え方

どちらかのポートを変えるのが基本です。両方とも外から使わないなら、片方を別のポートに移すだけで済みます。同じポートで動かしたい理由があるなら、Linux では 127.0.0.0/8 全体がループバックとして扱われるため、片方を 127.0.0.2 など別のループバックアドレスで待ち受けさせる方法もあります。macOS は既定では 127.0.0.1 しか lo0 に載っていないため、別アドレスを使うには追加の設定が要ります。

原因2：localhost が ::1 と 127.0.0.1 のどちらに解決されるかが食い違う

アプリが 127.0.0.1 だけで待ち受けているのに、クライアントが localhost を IPv6 の ::1 に解決して接続すると、接続は拒否されます。逆も起こります。最近の実行環境では、localhost を IPv6 で先に試すものが増えているため、言語やライブラリを更新したタイミングで急に表面化することがあります。

確認

# localhost がどう解決されるか
getent ahosts localhost

# 待ち受けが IPv4 だけか、IPv6 もあるか
sudo ss -ltn | grep ':3000'

/etc/hosts も確認します。Debian・Ubuntu ではホスト名が 127.0.1.1 に割り当てられていることがあり、ホスト名で接続するアプリだけ別のアドレスに向かう、という食い違いの原因になります。

直し方

接続先を localhost ではなく 127.0.0.1（または ::1）と明示する。データベースの接続設定などでは、これがもっとも確かな方法です
サーバー側を IPv4 と IPv6 の両方で待ち受けるようにする
/etc/hosts の localhost の行を消したり、::1 の行を削ったりする方法は、ほかのソフトウェアに影響するため避けます

原因3：lo に載せた VIP が ARP で外に漏れる

LVS や keepalived などで DSR（Direct Server Return）構成を組むと、各実サーバーの lo に共通の仮想 IP（VIP）を載せます。このとき Linux の既定の挙動では、lo に載せたアドレスについても他のインターフェースから ARP に応答してしまうため、同じ VIP を持つ複数のサーバーが一斉に ARP に答え、通信が特定のサーバーに偏ったり、ロードバランサーを素通りしたりします。

確認

# 実サーバー側：lo に VIP が載っているか
ip addr show dev lo

# ARP 応答の制御値
sysctl net.ipv4.conf.all.arp_ignore net.ipv4.conf.all.arp_announce

同じセグメントの別のマシンから arping で VIP を引き、複数の MAC アドレスから応答が返るなら、この問題です。

直し方

実サーバー側で、自分のインターフェースに付いたアドレス以外の ARP 要求に答えないようにし、ARP の送信元に適切なアドレスを使わせます。DSR 構成で一般に使われる設定は次のとおりです。

# /etc/sysctl.d/90-lvs-dsr.conf
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

sudo sysctl --system で反映します。ロードバランサー本体には VIP を通常のインターフェースに載せるので、この設定は実サーバー側だけに入れます。構成によってはインターフェース単位の値が優先されるため、all と該当インターフェースの両方の値を確認してください。

原因4：ルーターのループバックアドレスが重複している

ルーターや FRRouting を動かす Linux では、管理用やルーター ID 用にループバックへアドレスを付けるのが一般的です。機器を複製して追加したときなどに、このアドレスやルーター ID が重複すると、OSPF では LSA が互いに上書きされて経路が安定しなくなります。BGP でも同じ ID のピアとはセッションの確立がうまくいかないことがあります。

確認は、各ルーターでルーター ID とループバックのアドレスを一覧にして見比べるのが早道です。FRRouting なら vtysh -c "show ip ospf" でルーター ID を表示できます。直すときは、ループバックのアドレスとルーター ID を明示的に一意の値で設定し、プロセスの再起動など、機器ごとに定められた方法で新しい ID を反映させます。ルーター ID の変更は隣接の張り直しを伴うため、影響の少ない時間帯に行います。

WordPress の「ループバックリクエスト」が失敗する場合

WordPress のサイトヘルスには、サイトが自分自身に HTTP でリクエストを送れるかを確かめる項目があります。これが失敗すると、WP-Cron の実行や、テーマ・プラグインのファイル編集時の安全確認などに影響します。ここでの「競合」は、ネットワークよりもプラグインや設定の干渉であることが多いです。

起きやすい順に確認します。

セキュリティ系プラグインやWAFが自サイトからのリクエストを遮断している：一時的に無効化して再テストします。管理画面に入れなくなった場合は、FTP などで該当プラグインのフォルダー名を変えると無効化できます
Basic 認証やIP制限をかけている：検証環境でよくある原因です。サーバー自身のアドレスからのアクセスを許可するか、検証環境では失敗を許容します
サーバーが自分のドメイン名を解決できない、または外向きの経路でしか到達できない：サーバー上で curl -I https://自サイトのドメイン/ を実行し、応答を確かめます
SSL 証明書の不備：サーバーから見て証明書の検証に失敗していないか、同じく curl の結果で確認します

プラグインの干渉かどうかは、公式ディレクトリで配布されている Health Check & Troubleshooting プラグインのトラブルシューティングモードで切り分けられます。このモードは自分のログインセッションだけでプラグインを無効化するため、訪問者への影響を抑えて試せます。画面上の表記は版によって異なることがあります（2026年10月現在）。

まとめ

ループバックの競合は、ポートの取り合い、localhost の IPv4/IPv6 解決の食い違い、lo に載せた VIP の ARP 漏れ、ルーターIDの重複、のいずれかであることがほとんどです。まずメッセージから種類を見分けます。
ポートの取り合いは ss や lsof でプロセスを特定し、0.0.0.0 での待ち受けも含めて確認します。systemd-resolved の 53 番は代表的な例です。
localhost の食い違いは、接続先を 127.0.0.1 などと明示するのがもっとも確かです。/etc/hosts の基本の行は消さないでください。
DSR 構成では実サーバーに arp_ignore と arp_announce を設定し、ルーターではループバックとルーターIDを一意にします。
WordPress のループバックリクエストの失敗は、セキュリティ系プラグイン、認証、名前解決、証明書の順に確かめます。