Loopback（ループバック）は「自分自身に戻ってくる通信」を指す言葉で、サーバー運用では主に3つの意味で使われます。OS のループバックアドレス（127.0.0.1 や ::1）、WordPress が自分のサイトに送るループバックリクエスト、ネットワーク機器の Loopback インターフェースです。この記事では、それぞれの違いと、どんな場面で使うと役に立つか、使うときにつまずきやすい点を説明します。
種類1: OS のループバックアドレス
どんなものか
127.0.0.0/8（一般には 127.0.0.1）と IPv6 の ::1 は、外部のネットワークに出ずに同じマシンの中だけで完結する通信に使うアドレスです。lo という仮想的なインターフェースに割り当てられていて、ネットワークケーブルが抜けていても使えます。localhost という名前は、通常 /etc/hosts でこのアドレスに結び付けられています。
使いどころ: 外部に公開しないサービスの待ち受け
最も実用的な使い方は、同じサーバーの中からしか使わないサービスを、ループバックアドレスだけで待ち受けさせることです。WordPress を1台のサーバーで動かしている構成なら、次のようなサービスが該当します。
- MySQL / MariaDB（
bind-address = 127.0.0.1） - Redis（設定ファイルの
bindで127.0.0.1と::1を指定） - PHP-FPM（TCP で待ち受けるなら
listen = 127.0.0.1:9000） - 管理用の Web ツールや監視エージェント
ファイアウォールで外部からのアクセスを止めていても、待ち受け自体をループバックに限定しておけば、ファイアウォールの設定ミスがあったときにも外部へ露出しません。何重かに守っておく考え方です。
既定の待ち受けアドレスは、ソフトウェアのバージョンやディストリビューションのパッケージによって異なります（2026年10月現在）。設定ファイルのバックアップを取ってから変更し、変えたあとは実際にどのアドレスで待ち受けているかを確認します。
sudo ss -ltnp127.0.0.1:3306 のように表示されていればループバックだけ、0.0.0.0:3306 や *:3306 なら全インターフェースで待ち受けています。
つまずきやすい点
**MySQL の localhost と 127.0.0.1 は別物です。** MySQL のクライアント（PHP の mysqli を含む）は、接続先が localhost のとき TCP ではなく Unix ソケットで接続します。wp-config.php の DB_HOST を localhost にしていて接続できない場合、ソケットのパスが合っていないことがあり、127.0.0.1 に変えると TCP 接続になって通る、ということが起こります。どちらが正しいかは、MySQL 側がソケットと TCP のどちらで待ち受けているかによります。
**Docker のコンテナの中の 127.0.0.1 はコンテナ自身です。** コンテナからホストの MySQL に 127.0.0.1 で接続しようとしても、届きません。逆に、ホストでポートを公開するときは -p 127.0.0.1:8080:80 のようにホスト側のアドレスを指定すると、ホストのループバックにだけ公開できます。アドレスを省略すると全インターフェースに公開され、ホストのファイアウォール（ufw など）の設定をすり抜けることがあるため注意が必要です。
リバースプロキシの裏では送信元がループバックに見えます。 Nginx から同じサーバーの Apache やアプリに転送する構成では、アプリから見た接続元はすべて 127.0.0.1 です。「127.0.0.1 からのアクセスは管理者として許可する」といった判定を入れていると、外部からのアクセスまで許可してしまいます。実際の送信元は、信頼できるプロキシが付けたヘッダーから取り出し、プロキシ以外から来たヘッダーは信用しない設計にします。
種類2: WordPress のループバックリクエスト
どんなものか
WordPress は、自分自身のサイトに HTTP リクエストを送る処理をいくつか持っています。これをループバックリクエストと呼びます。代表的なのは次の2つです。
- WP-Cron: ページの表示をきっかけに、
wp-cron.phpへリクエストを送って予約投稿や定期処理を動かします - テーマ・プラグインのファイル編集: 管理画面のエディターで PHP ファイルを保存するとき、致命的なエラーが起きないかを、自分のサイトへのリクエストで確かめます
サイトヘルス（「ツール」→「サイトヘルス」）には、ループバックリクエストが成功するかを調べる項目があります。
失敗する原因と確認方法
サイトヘルスでループバックリクエストの失敗が表示された場合、予約投稿が公開されない、定期処理が動かないといった症状につながります。可能性の高い順に確認します。
- Basic 認証: ステージング環境でサイト全体に Basic 認証をかけていると、自分自身へのリクエストも認証で止まります
- セキュリティ設定: WAF やセキュリティプラグインが、サーバー自身からのリクエストを攻撃と判定して拒否しています
- 名前解決: サーバー上でドメインを引いたときに、CDN やロードバランサーのアドレスが返り、そこからサーバーに戻ってこられない構成になっています
- 証明書: 自己署名の証明書や中間証明書の不足で、TLS の検証に失敗しています
切り分けには、サーバー上から実際にリクエストを送るのが早道です。
# サーバー上で、自分のサイトへのリクエストを試す
curl -sI https://example.com/wp-cron.php
# WP-CLI で WP-Cron の起動を確認する
wp cron testcurl が証明書エラーで失敗する場合は原因4、401 が返る場合は原因1、と症状から絞り込めます。名前解決が原因のときは、サーバーの /etc/hosts に自分のドメインと、サーバーで待ち受けているアドレスを書く方法がありますが、TLS の証明書やバーチャルホストの設定と合っているかを確認してから行います。
WP-Cron のループバックに頼らない方法として、wp-config.php に define( 'DISABLE_WP_CRON', true ); を書き、サーバーの cron から定期的に WP-Cron を実行する構成もあります。アクセスの少ないサイトや、処理を決まった時刻に動かしたいサイトに向いています。
ループバックと SSRF 対策の関係
WordPress の wp_safe_remote_get() などの「safe」が付く関数は、ループバックアドレスやプライベートアドレスへのリクエストを拒否します。ユーザーが入力した URL に対してサーバーからリクエストを送る機能（外部画像の取り込みなど）では、こちらを使うことで、内部のサービスにアクセスされる攻撃（SSRF）を防げます。
種類3: ネットワーク機器の Loopback インターフェース
どんなものか
ルーターやレイヤー3スイッチでは、物理的なポートとは別に、Loopback0 のような仮想インターフェースを作れます。物理インターフェースは回線の障害で使えなくなりますが、Loopback インターフェースは機器が動いている限り使えます。
使いどころ
- 管理用のアドレス: 監視や SSH 接続の宛先にすると、どの回線を経由しても同じアドレスで機器に届きます
- ルーティングプロトコルの識別子: OSPF や BGP のルーター ID や、BGP の接続の始点に使うと、特定の回線の状態に左右されません
Linux サーバーでも、ロードバランサーの DSR（Direct Server Return）構成で、仮想 IP をバックエンドの lo に割り当てる使い方があります。この場合は、そのアドレスに対する ARP に応答しないようカーネルのパラメータを調整する必要があり、設定を誤ると通信が不安定になります。検証環境で動作を確かめてから本番に入れます。
まとめ
- Loopback には、OS のループバックアドレス、WordPress のループバックリクエスト、ネットワーク機器の Loopback インターフェースの3種類がある
- 同じサーバー内だけで使う DB・Redis・PHP-FPM は、ループバックアドレスだけで待ち受けさせる
- MySQL の
localhostはソケット接続、Docker のコンテナ内の127.0.0.1はコンテナ自身、という違いに注意する - WordPress のループバックリクエストの失敗は、Basic 認証、セキュリティ設定、名前解決、証明書の順に確認する
- リバースプロキシの裏では送信元がループバックに見えるため、IP アドレスだけで権限を判定しない