2026年6月6日
2026年6月6日
ループバックアドレスとグローバルIPの違い|127.0.0.1で待ち受ける意味とサーバー設定での使い分け
ループバックアドレス(127.0.0.1 や ::1)は「そのマシン自身」を指す、マシンの外には出ていかないアドレスです。グローバル IP は、インターネット上で一意に割り当てられ、世界中から届くアドレスです。この違いは、サーバーでサービスをどのアドレスで待ち受けるかに直結します。この記事では、2つの範囲と届く範囲の違いを整理したうえで、待ち受けアドレスの確認方法、データベースやキャッシュを外部に公開しない設定、WordPress のループバックリクエストが失敗するときの考え方まで説明します。
違いをひとことで言うと
- ループバックアドレス:自分自身との通信専用。パケットはネットワークカードから外に出ず、OS の中で折り返される。どのマシンでも同じアドレスを使う
- グローバル IP:インターネットで経路が通る公開アドレス。プロバイダーやクラウド事業者から割り当てられ、同じアドレスを持つ機器は世界に1つだけ
| 項目 | ループバックアドレス | グローバル IP |
|---|---|---|
| IPv4 の範囲 | 127.0.0.0/8(通常は 127.0.0.1) | プライベートや予約済みの範囲を除くアドレス |
| IPv6 | ::1 の1つだけ | 2000::/3 のグローバルユニキャスト |
| 届く範囲 | そのマシンの中だけ | インターネット全体 |
| 割り当て | OS が自動で用意 | プロバイダー・クラウド事業者 |
| 主な用途 | 同じマシン内のサービス同士の通信、動作確認 | 外部に公開する Web サーバーなど |
localhost というホスト名は、通常ループバックアドレスに解決されます。ただし、IPv4 の 127.0.0.1 と IPv6 の ::1 のどちらに解決されるかは環境によって異なり、片方でしか待ち受けていないサービスにつながらない原因になることがあります。
Linux では、lo インターフェースに 127.0.0.1/8 が設定されているため、127.0.0.1 以外の 127.x.x.x 宛ても自分自身に届きます。
自分のサーバーで確認する
まず、インターフェースに付いているアドレスを見ます。
ip -br addr
lo に 127.0.0.1 と ::1、eth0 や ens3 などに外向きのアドレスが表示されます。ここで注意したいのは、クラウドのサーバーではグローバル IP がインターフェースに表示されないことが多い点です。たとえば AWS の EC2 では、インスタンス自身はプライベート IP だけを持ち、グローバル IP との変換はクラウド側で行われます。外から見えているアドレスは、外部のサービスに問い合わせて確認します。
curl -4 https://ifconfig.me
サービスがどのアドレスで待ち受けているかを見る
違いが実務で効いてくるのは、待ち受け(bind)アドレスです。次のコマンドで、待ち受け中のポートとアドレスを確認できます。
sudo ss -tlnp
Local Address:Port の列の読み方は次のとおりです。
127.0.0.1:3306や[::1]:6379:同じマシンの中からしか接続できない0.0.0.0:80や[::]:80:すべてのインターフェースで待ち受ける。外向きのアドレスにも届くので、外部から接続できる可能性がある10.0.0.5:3306のような特定のアドレス:そのアドレスが付いたインターフェース経由でだけ接続できる
Web サーバーの 80/443 番は外部から使うので 0.0.0.0 や [::] で問題ありませんが、データベースやキャッシュが 0.0.0.0 で待ち受けていると、ファイアウォールの設定ひとつで外部に公開されてしまいます。
データベースやキャッシュはループバックで待ち受ける
WordPress と MySQL / MariaDB が同じサーバーにある構成なら、データベースはループバックだけで待ち受けるのが基本です。設定ファイルの場所はディストリビューションやバージョンで異なりますが、[mysqld] セクションに次のように書きます。
[mysqld]
bind-address = 127.0.0.1
Redis も同様に、設定ファイルの bind でループバックだけを指定します。最近の Redis の既定設定はループバックのみで待ち受ける内容になっていますが(2026年10月現在)、手を入れた設定や、コンテナ用のイメージでは変わっていることがあるため、実際の値を確認してください。
bind 127.0.0.1 -::1
設定を変える前には設定ファイルをバックアップし、変更後はサービスを再起動して ss -tlnp の表示が変わったことを確かめます。データベースを別サーバーに分ける構成では、ループバックではなくプライベート IP で待ち受け、ファイアウォールで WordPress サーバーからの接続だけを許可します。グローバル IP で待ち受けて外部に開くのは避けてください。
なお、ループバックで待ち受けていても安全が保証されるわけではありません。同じサーバーに侵入された場合や、サーバー自身に任意の URL へリクエストさせる脆弱性(SSRF)がある場合は、ループバック上のサービスにも届きます。パスワードなどの認証は省略しないでください。
WordPress で混同しやすい場面
DB_HOST の localhost と 127.0.0.1
wp-config.php の DB_HOST を localhost にすると、PHP の mysqli は TCP ではなく Unix ソケットで接続しようとします。127.0.0.1 と書くと TCP のループバック接続になります。どちらも同じマシンへの接続ですが経路が異なるため、片方だけ失敗する場合は、ソケットファイルの場所や、データベースのユーザーが 'user'@'localhost' と 'user'@'127.0.0.1' のどちらで作られているかを確認します。
Docker コンテナの中の 127.0.0.1
コンテナの中で 127.0.0.1 を指定すると、ホストではなくそのコンテナ自身を指します。WordPress コンテナから別コンテナの DB に接続するときは、Docker Compose のサービス名などで指定します。
ループバックリクエストが失敗する
WordPress は WP-Cron の起動やサイトヘルスの確認などで、サーバー自身から自分のサイトの URL へ HTTP リクエストを送ります。これを「ループバックリクエスト」と呼びますが、宛先は 127.0.0.1 ではなく、DNS で解決したサイトのアドレス(多くはグローバル IP)です。そのため、次のような原因で失敗します。
- サーバーのファイアウォールや WAF が、自分自身のグローバル IP からの接続を遮断している
- NAT の内側にあるサーバーで、ルーターがヘアピン NAT(内側から自分のグローバル IP 宛ての通信を折り返す機能)に対応していない
- サーバー内の DNS 設定で、自分のドメインが古いアドレスに解決されている
- Basic 認証などでサイト全体を保護している
サーバー上で curl -I https://example.com/ を実行し、外部からと同じ応答が返るかを確かめると切り分けられます。対処として /etc/hosts で自分のドメインを 127.0.0.1 に向ける方法もありますが、その場合は Web サーバーが 127.0.0.1 でも待ち受けていて、同じ証明書でそのドメインを提供している必要があります。
まとめ
- ループバックアドレスはマシンの中だけで使う自分自身のアドレス、グローバル IP はインターネット全体から届く公開アドレス
- クラウドではグローバル IP がインターフェースに表示されないことが多いので、外部から見えるアドレスは別に確認する
ss -tlnpで待ち受けアドレスを確認し、データベースやキャッシュはループバックかプライベート IP に限定する- ループバックで待ち受けていても、認証は省略しない
- WordPress のループバックリクエストは自分のサイトの URL 宛てなので、ファイアウォール・ヘアピン NAT・DNS を順に確認する
- 待ち受け設定を変える前は設定ファイルをバックアップし、ステージング環境で試してから本番に反映する