2026年8月1日
2026年8月1日
IPv6 only の無効化手順|IPv4でも接続を受けられるようにする設定
サーバーが IPv6 でしか待ち受けていない、あるいは IPv6 だけのネットワークに置かれているために IPv4 の利用者から接続できない場合は、「どの層で IPv6 only になっているか」を特定し、その層だけを IPv4 と両方に対応させれば解消します。この記事では、Linux カーネルの設定、nginx・Apache・SSH・Postfix の待ち受け設定、DNS、クラウドのネットワークの順に、IPv6 only の状態を見つけて無効化する手順を説明します。
IPv6 そのものを止めたいわけではない点に注意してください。ここで扱うのは「IPv6 だけ」の状態をやめ、IPv4 と IPv6 の両方で通信できるようにする作業です。設定を変える前に、対象の設定ファイルをバックアップし、可能ならステージング環境で試してください。
まず症状を確認する
IPv6 only が原因かどうかは、IPv4 と IPv6 を指定して接続を比べると分かります。自宅や手元の回線が IPv6 に対応していない場合は、外部の確認ツールや別のサーバーから試してください。
# IPv4 で接続
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com/
# IPv6 で接続
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com/
IPv6 では 200 が返り、IPv4 だけ接続できない(タイムアウトや Connection refused)なら、以下のどこかで IPv6 only になっています。Connection refused はサーバーまで届いたが待ち受けが無い、タイムアウトは途中で遮断されているか IPv4 アドレスへの経路が無い、という目安になります。
次に、サーバー上で待ち受けの状態を確認します。
sudo ss -tlnp | grep -E ':(80|443|22|25)\s'
0.0.0.0:80 は IPv4 の全アドレスでの待ち受けです。IPv6 のソケットについては、比較的新しい iproute2 の ss では、IPv4 も受ける(IPv4射影アドレスを受け付ける)ものを *:80、IPv6 専用のものを [::]:80 と表示します。表示はバージョンによって異なることがあるため、[::]:80 だけが並んでいて 0.0.0.0:80 も *:80 も無い場合は、IPv6 only を疑って以下のカーネル設定とアプリの設定を確認してください。
1. カーネルの bindv6only を確認する
Linux では、IPv6 のソケットを :: で待ち受けたときに IPv4 の接続も受けるかどうかを net.ipv6.bindv6only で決めています。
sysctl net.ipv6.bindv6only
0(多くのディストリビューションの既定値): アプリが特に指定しなければ、[::]の待ち受けで IPv4 も受けられます。1: アプリが特に指定しなければ、[::]の待ち受けは IPv6 だけになります。
1 になっていて、それが意図した設定でなければ 0 に戻します。どのファイルで設定されているかを先に探し、そのファイルを直してください。別の場所に書き足すと、どちらが有効か分かりにくくなります。
# 設定箇所を探す
grep -rn bindv6only /etc/sysctl.conf /etc/sysctl.d/ 2>/dev/null
# 見つかったファイルの値を 0 にしたうえで再読み込み
sudo sysctl --system
この値は、変更後に起動したソケットにだけ効きます。反映させるには各サービスの再起動が必要です。また、アプリ側が個別に IPv6 only を指定している場合(次の nginx など)は、カーネル設定よりアプリの指定が優先されます。
2. Web サーバーの待ち受け設定
nginx
nginx の listen には ipv6only というパラメータがあり、既定では on です。つまり listen [::]:80; だけを書くと IPv6 専用になります。IPv4 でも受けるには、IPv4 用の listen を並べて書くのが分かりやすい方法です。
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com;
# ...
}
listen [::]:80 ipv6only=off; として1つのソケットで両方を受ける方法もありますが、その場合は同じポートに listen 80; を書くと二重の待ち受けになり起動に失敗します。どちらか一方の書き方にそろえてください。ipv6only は同じアドレスとポートの組に対して設定全体で1回しか指定できない点にも注意が必要です。複数の server ブロックがある場合は、default_server を付けたブロックなどにまとめて書きます。
変更後は構文を確認してから再読み込みします。
sudo nginx -t && sudo systemctl reload nginx
Apache
Apache は Linux の一般的なビルドでは Listen 80 と書くだけで IPv4 と IPv6 の両方を受けます。設定が Listen [::]:80 だけになっている場合は Listen 80(HTTPS は Listen 443)に戻します。待ち受け設定は ports.conf(Debian/Ubuntu系)や httpd.conf(RHEL系)にあることが多いです。
sudo apachectl configtest && sudo systemctl reload apache2 # RHEL系は httpd
VirtualHost を <VirtualHost [2001:db8::10]:443> のように IPv6 アドレスで限定していると、IPv4 での接続がそのサイトに割り当てられません。<VirtualHost *:443> にするか、IPv4 アドレスのものを並べて書きます。
3. SSH・メールなど他のサービス
サービスごとに IPv6 だけを使う設定があります。代表的なものを挙げます。
- OpenSSH:
/etc/ssh/sshd_configのAddressFamily inet6をanyにします(inetは IPv4 のみ)。ListenAddressが IPv6 アドレスだけになっていないかも確認します。SSH の設定を変えるときは、今のセッションを閉じずに別の端末から接続できることを確かめてから閉じてください。設定を誤るとログインできなくなります。 - Postfix:
postconf inet_protocolsがipv6ならallに変更します(sudo postconf -e 'inet_protocols = all'の後に再起動)。IPv4 で送信できるようになると、送信元IPv4アドレスの逆引き(PTR)やSPFの設定も必要になる点に注意してください。 - MySQL / MariaDB:
bind-addressが IPv6 アドレスに限定されていないか確認します。データベースは外部に公開しないのが基本なので、ローカル接続だけで足りるなら変更不要です。
4. DNS に A レコードがあるか
待ち受けを直しても、ドメインに AAAA レコード(IPv6)しかなければ、IPv4 だけの利用者は名前解決の段階で接続先を得られません。
dig A example.com +short
dig AAAA example.com +short
A レコードが無ければ、サーバーの IPv4 アドレスで追加します。A と AAAA の両方を公開する場合は、どちらで接続しても同じサイト・同じ証明書が返るように、Web サーバー側の設定もそろえておきます。
5. サーバーやネットワーク自体が IPv6 only の場合
クラウドや VPS では、インスタンスに IPv6 アドレスしか割り当てない構成(IPv6 only のサブネットやプラン)を選べることがあります。この場合はOSやアプリの設定ではなく、ネットワーク側で IPv4 アドレスを割り当てる必要があります。
- インスタンスにパブリック IPv4 アドレスを割り当てる、または固定の IPv4 アドレスを関連付けます。
- サブネットやVPCに IPv4 のアドレス範囲があるかを確認します。サービスによっては IPv6 only のサブネットを後からデュアルスタックに変更できず、作り直しが必要になることがあります。
- セキュリティグループやファイアウォールに、IPv4 用の許可ルールを追加します。IPv6 用のルールだけでは IPv4 の通信は通りません。
- OS 内で IPv4 アドレスが設定されたかを
ip -4 addrで確認します。
仕様や設定の名称はクラウドごとに異なり、変更されることもあります(2026年10月現在)。各サービスのドキュメントで、既存の環境に IPv4 を追加できるかを確認してください。パブリック IPv4 アドレスは有料になっているサービスも多いため、料金体系もあわせて確認します。
変更後の確認
最後に、最初の確認を繰り返します。
sudo ss -tlnp | grep -E ':(80|443)\s'
curl -4 -I https://example.com/
curl -6 -I https://example.com/
IPv4・IPv6 の両方で同じステータスとレスポンスヘッダが返れば完了です。WordPress の場合は、管理画面へのログインやフォーム送信も IPv4 側から試しておくと、セキュリティプラグインのIP制限などで IPv4 側だけ弾かれていないかを確認できます。
まとめ
- まず
curl -4/curl -6とss -tlnpで、どこで IPv4 が通らないかを見ます。 - カーネルの
net.ipv6.bindv6onlyが1なら、設定箇所を探して0に戻します。 - nginx は
listen [::]:80;だけだと IPv6 専用です。IPv4 用のlistenを並べて書きます。 - SSH の
AddressFamily、Postfix のinet_protocolsも確認し、SSH は別セッションで接続確認してから閉じます。 - DNS に A レコードが無い、またはサーバー自体が IPv6 only の場合は、IPv4 アドレスの割り当てとレコード追加が必要です。