2026年6月22日
systemd-resolved のキャッシュは sudo resolvectl flush-caches で消せますが、このコマンドが消すのは「systemd-resolved が覚えているDNSの答え」だけです。すでにつながっているデータベース接続や、PHPやアプリケーションが自前で持っている情報、上流のDNSサーバーのキャッシュには影響しません。この記事では、flush-caches が何を消して何を消さないのかを整理し、WordPressサーバーでDBやAPIの接続先を変えたときに、どの順番でクリアや再起動を行えばよいかを説明します。
キャッシュの消し方と「消えたか」の確かめ方そのものは別の記事で詳しく扱っているため、ここでは仕組みと使いどころに重点を置きます。
systemd-resolved のキャッシュはどこにあるか
systemd-resolved は、Ubuntu など多くのLinuxディストリビューションで標準になっている名前解決のサービスです。アプリケーションからの問い合わせは、主に次のどちらかの経路で systemd-resolved に届きます。
/etc/resolv.confに書かれたnameserver 127.0.0.53（スタブリゾルバ）へのDNS問い合わせ/etc/nsswitch.confのhosts:行にあるresolveを通じたNSS経由の問い合わせ
systemd-resolved は上流のDNSサーバーから受け取った答えを、TTLの範囲でメモリ上にキャッシュします。ディスクには保存しないため、サービスを再起動しても消えます。キャッシュの中身は、名前が存在した場合の答え（肯定応答）と、存在しなかった場合の答え（否定応答）の両方です。
flush-caches で消えるもの
sudo resolvectl flush-cachesこのコマンドで消えるのは、systemd-resolved のDNSキャッシュ全体です。特定の名前だけを消す指定はなく、すべてのネットワークインターフェースの分がまとめて消えます。
- 肯定応答のキャッシュ（古いIPアドレスなど）
- 否定応答のキャッシュ（「その名前は存在しない」という答え）
否定応答も消える点は、新しくレコードを追加したときに役立ちます。追加前に一度問い合わせてしまい「存在しない」と覚えられた名前は、消去しないと、ゾーンのSOAで決まる時間が過ぎるまで見つからないままになるためです。
flush-caches で消えないもの
上流のDNSサーバーのキャッシュ
systemd-resolved が問い合わせる先（プロバイダーやクラウドのDNS、公開DNSなど）も、それぞれキャッシュを持っています。flush-caches の直後に問い合わせても、上流が古い答えを持っていれば、その古い答えがもう一度キャッシュされます。上流の状態は dig @上流のアドレス 名前 で直接確認します。上流のアドレスは resolvectl status で確認できます。
サーバーが学習した上流の特性
systemd-resolved は、上流のサーバーがEDNSやDNSSECにどこまで対応しているかを試しながら学習し、通信の方法を調整しています。上流のサーバーを入れ替えた後や、ネットワーク機器の設定を変えた後に名前解決が不安定な場合は、この学習結果を初期化するコマンドがあります。
sudo resolvectl reset-server-featuresこれはキャッシュの消去とは別の操作です。名前解決が遅い・ときどき失敗する、という症状のときに試すもので、古いIPが返る問題には通常は関係しません。
/etc/hosts の内容
systemd-resolved は /etc/hosts も読み込みますが、これはキャッシュではなく設定です。移転作業の確認のために /etc/hosts に書いた行が残っていると、キャッシュを何度消しても同じアドレスが返ります。
すでに確立している接続
DNSの答えが使われるのは、新しく接続を始めるときだけです。キャッシュを消しても、すでにつながっているTCP接続は古い接続先のまま維持されます。WordPressの環境では、次のような接続がこれに当たります。
- PHP-FPMやアプリケーションが持続的に保持しているデータベース接続
- Redis や Memcached などのオブジェクトキャッシュへの接続
- 長時間動き続けるワーカーやデーモンの接続
アプリケーション自身のキャッシュ
ソフトウェアによっては、OSとは別に名前解決の結果を保持します。PHPの cURL 拡張は接続ハンドルごとに短時間のDNSキャッシュを持ち、Java などのランタイムは独自のキャッシュ設定を持っています。また、nscd や dnsmasq、unbound が併用されている場合は、それぞれのキャッシュも別に消す必要があります。
キャッシュを使わずに今の答えを確認する
キャッシュを消す前に、「上流から今どんな答えが返るか」だけを確認したいときは、resolvectl query にキャッシュを使わない指定を付けます。
# キャッシュを使わずに問い合わせる
resolvectl query --cache=no db.example.com
# 通常の問い合わせ（キャッシュを使う）と比べる
resolvectl query db.example.comこの2つの答えが違えば、systemd-resolved のキャッシュに古い値が残っていると判断できます。同じ古い値が返る場合は、上流か権威DNS側の問題です。オプションの有無や出力の形式はバージョンによって異なるため、resolvectl --help で手元の環境を確認してください（2026年10月現在）。
サーバー移転・接続先変更のときの使いどころ
WordPressサーバーで、次のような「接続先のホスト名が指すIPアドレスが変わる」作業をするときに、キャッシュのクリアが関わってきます。
wp-config.phpのDB_HOSTにホスト名を使っていて、データベースサーバーを移した- 外部APIや決済サービス、SMTPサーバーの接続先が変わった
- オブジェクトキャッシュ用の Redis サーバーを入れ替えた
この場合は、次の順番で進めると、どこで止まっているかが分かりやすくなります。作業前に wp-config.php やサーバーの設定ファイルのバックアップを取り、可能であればステージング環境で一度試します。
1. 権威DNSと上流で新しい値が返ることを確かめる
dig db.example.com A +short
resolvectl query --cache=no db.example.comここで古い値が返る場合は、DNSの設定かTTLの待ち時間の問題です。サーバー側でキャッシュを消しても解決しないため、DNS側の反映を先に待ちます。
2. systemd-resolved のキャッシュを消す
sudo resolvectl flush-caches
getent ahosts db.example.comgetent はNSSを通るため、PHPなどのアプリケーションに近い経路で名前解決の結果を確認できます。
3. 接続を保持しているプロセスを再起動する
新しいアドレスで接続し直させるため、接続を保持しているサービスを再起動します。どのサービスが該当するかは環境によって異なりますが、WordPressの構成では PHP-FPM が代表的です。
# サービス名はディストリビューションとPHPのバージョンによって異なる
sudo systemctl restart php8.3-fpm再起動の間はサイトの応答が一瞬止まるため、アクセスの少ない時間帯に行います。再起動後、管理画面へのログインや投稿の保存など、データベースに書き込む操作を一度行い、エラーが出ないかを確認します。
4. それでも古い接続先が使われる場合
Docker などのコンテナでWordPressを動かしている場合、コンテナは独自の /etc/resolv.conf を持ち、ホストの systemd-resolved を経由しないことがあります。この場合はコンテナの中で getent ahosts を実行して確認し、必要に応じてコンテナを再起動します。
キャッシュの設定を変える前に考えること
何度もクリアが必要になるからといって、/etc/systemd/resolved.conf の Cache= でキャッシュを無効にするのは、本番環境では慎重に判断します。キャッシュを切ると、すべての問い合わせが上流へ向かうため、名前解決が遅くなり、上流の障害の影響を受けやすくなります。多くの場合は、変更前に対象レコードのTTLを短くしておくことと、上の手順のように作業の流れにクリアと再起動を組み込むことで足ります。設定を変える場合は、元のファイルを残したうえで /etc/systemd/resolved.conf.d/ に追加の設定ファイルを置く方法にすると、戻しやすくなります。
まとめ
resolvectl flush-cachesが消すのは、systemd-resolved が持つ肯定応答・否定応答のキャッシュ全体です。- 上流のキャッシュ、
/etc/hosts、すでに確立した接続、アプリケーション独自のキャッシュは消えません。 resolvectl query --cache=noを使うと、キャッシュを消さずに今の答えを確認できます。- 接続先の変更では、DNS側の確認 → キャッシュの消去 → 接続を保持するプロセスの再起動、の順に進めます。
- キャッシュの無効化は最後の手段とし、TTLの事前調整と作業手順で対応します。