systemd-resolved のDNSキャッシュは sudo resolvectl flush-caches で消せます。ただし、実務で困るのは「消したのにまだ古いIPにつながる」場面です。この記事では、WordPressが動くLinuxサーバーを想定し、systemd-resolved が本当に名前解決を担っているかの確認、キャッシュの消去、消えたことの確認、そして消しても直らないときに見る場所を順に説明します。
まず systemd-resolved が使われているか確認する
Ubuntu など多くのディストリビューションでは systemd-resolved が標準で動いていますが、サーバーの構築方法によっては無効化されていたり、別のキャッシュ（nscd や dnsmasq、unbound など）が使われていたりします。消す対象を間違えないよう、最初に確認します。
systemctl is-active systemd-resolved
ls -l /etc/resolv.conf
grep nameserver /etc/resolv.conf次の状態であれば、アプリケーションの名前解決は systemd-resolved を経由しています。
systemctl is-activeがactiveを返す。/etc/resolv.confが/run/systemd/resolve/stub-resolv.confへのシンボリックリンクになっている。nameserver 127.0.0.53が書かれている。
/etc/resolv.conf に上流のDNSサーバーのアドレスが直接書かれている場合は、systemd-resolved が動いていても、アプリケーションはそれを経由せずに問い合わせている可能性があります。その場合、systemd-resolved のキャッシュを消しても挙動は変わりません。/etc/nsswitch.conf の hosts: 行に resolve が含まれているかも合わせて見ておくと、NSS経由の経路も把握できます。
キャッシュを消す
systemd-resolved のキャッシュはメモリ上にあり、次のコマンドで消去できます。
sudo resolvectl flush-caches古い環境で resolvectl が無い場合は、以前のコマンド名で同じ操作ができます。
sudo systemd-resolve --flush-cachesどちらも使えない状況では、systemd-resolved にシグナル SIGUSR2 を送ると、キャッシュの消去が行われます。サービスを再起動しても消えますが、再起動中は名前解決が止まり、設定ミスがあると起動に失敗してサーバー全体の名前解決ができなくなるため、まずは上のコマンドを使います。
sudo killall -USR2 systemd-resolved消去は数秒で終わり、通常はサービスへの影響はありません。ただし直後の問い合わせはすべて上流へ向かうため、問い合わせの多いサーバーでは一時的に名前解決が遅くなることがあります。
消えたことを確認する
flush-caches は成功しても何も表示しません。消えたかどうかは統計で確認します。
resolvectl statistics出力の「Cache」の項目にある現在のキャッシュ件数（Current Cache Size）が、消去直後に 0 または小さな値に戻っていれば、消去されています。表示の項目名はバージョンによって多少異なります（2026年10月現在）。
個別の名前について、答えがキャッシュから来たか、ネットワークから取得したかは resolvectl query で確認できます。比較的新しいバージョンでは、結果の末尾に取得元（cache か network か）が表示されます。
resolvectl query www.example.comキャッシュの中身そのものを見たい場合は、SIGUSR1 を送るとキャッシュとサーバーの状態がジャーナルに書き出されます。さらに新しいバージョンでは resolvectl show-cache で直接表示できますが、手元のバージョンで使えるかは resolvectl --help で確認してください。
sudo killall -USR1 systemd-resolved
sudo journalctl -u systemd-resolved -n 100 --no-pager最後に、アプリケーションと同じ経路で名前解決し、新しいIPが返るかを確かめます。dig は /etc/resolv.conf を見て 127.0.0.53 に問い合わせますが、getent は NSS を通るため、PHP などのアプリケーションに近い結果になります。
getent ahosts www.example.com
dig www.example.com A +short消しても古い値が返るときの確認
キャッシュを消しても古いIPが返る場合、原因は systemd-resolved 以外にあります。よくある順に確認します。
1. 上流のDNSサーバーが古い値を持っている
systemd-resolved を消去すると、次の問い合わせは上流のDNSサーバー（クラウドの内部DNSやデータセンターのキャッシュDNSなど）へ向かいます。その上流が古い値をキャッシュしていれば、また古い値を受け取ります。上流のアドレスを確認し、権威DNSサーバーの値と比べます。
resolvectl status
dig @上流のDNSサーバー www.example.com A
dig @ns1.example-dns.net www.example.com A +norecurse権威側が新しい値で、上流だけが古いなら、上流のTTLが切れるのを待つしかありません。応答のTTL欄で残り時間が分かります。
2. /etc/hosts に古い記述がある
systemd-resolved は標準で /etc/hosts も読み、そこに書かれた名前はDNSより優先されます。サイト移転の作業中に一時的に書いた行が残っていないか確認します。
grep -n example.com /etc/hosts3. 別のキャッシュが動いている
nscd が動いているサーバーでは、hosts のキャッシュが別に残ります。nscd -i hosts で無効化できます。dnsmasq や unbound をローカルに置いている構成では、それぞれのキャッシュも消去が必要です。
4. コンテナやアプリケーションが独自に名前解決している
Docker のコンテナは独自の /etc/resolv.conf を持ち、ホストの systemd-resolved のキャッシュを使わない構成があります。コンテナ内で cat /etc/resolv.conf を確認します。また、長時間動き続けるプロセスの中には、名前解決の結果をプロセス内に保持するものがあります。この場合はそのサービスの再起動が必要です。
5. 否定応答がキャッシュされていた
新しく作ったサブドメインで「名前が見つからない」と返る場合は、作成前の問い合わせの否定応答が上流に残っている可能性があります。否定応答の保持時間はゾーンのSOAレコードの設定で決まります。
キャッシュの設定を見直す
頻繁にDNSを切り替える検証用のサーバーでは、/etc/systemd/resolved.conf の Cache= でキャッシュの扱いを変更できます。no で無効化、新しいバージョンでは no-negative で否定応答だけキャッシュしない設定もあります。変更前に設定ファイルをバックアップし、ステージング環境で試してから反映します。
[Resolve]
Cache=no-negativesudo cp /etc/systemd/resolved.conf /etc/systemd/resolved.conf.bak
sudo systemctl restart systemd-resolved本番サーバーでキャッシュを無効にすると、上流への問い合わせが増え、外部APIを多く呼ぶサイトでは応答が遅くなることがあります。通常はキャッシュを有効のままにし、移転時だけ手動で消去する運用で十分です。
まとめ
- 消す前に、
/etc/resolv.confが 127.0.0.53 を指しているかなどで systemd-resolved が名前解決を担っているか確認する。 - 消去は
sudo resolvectl flush-caches。古い環境ではsystemd-resolve --flush-cachesか SIGUSR2。 resolvectl statisticsのキャッシュ件数やresolvectl queryの取得元表示で、消えたことを確認する。アプリに近い確認はgetent ahosts。- それでも古い場合は、上流DNS、/etc/hosts、nscd などの別キャッシュ、コンテナ、否定応答の順に確認する。
Cache=の変更は検証環境向け。本番はキャッシュ有効のまま、必要なときに消去する。