本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。
あるサーバー上で動かしているDrupalにアクセスできなくなり、調査したところ、原因はDrupalそのものではなく、前段のリバースプロキシであるTraefikがDocker APIへ接続できなくなっていたことでした。きっかけはDocker Engineのメジャーバージョンアップで、サードパーティリポジトリ由来のパッケージを一括アップグレードしたことに起因していました。同種の構成では再発しうる内容のため、調査と復旧の手順、再発防止策を整理します。
症状
あるDrupalサイトにアクセスできない状態でした。アプリケーション側のエラー画面ではなく、リクエストがバックエンドまで到達していない様子でした。
構成
このサーバーは、TraefikをリバースプロキシとしてDrupalの前段に置く構成です。TraefikはDockerソケットを監視し、コンテナのラベルからルーティング設定を動的に組み立てる、いわゆるDocker provider方式で運用していました。
[Internet] → [Traefik :443] → [Drupal :30080] → [MariaDB]
(healthy) (healthy)
確認したところ、Drupalコンテナ・MariaDBコンテナ自体はいずれも healthy で稼働していました。アプリケーションは生きているのに、前段のTraefikがリクエストを転送できていない、という切り分けになりました。
原因調査
Traefikのログを確認すると、Docker APIとの通信で次のエラーが繰り返し出力されていました。
Error response from daemon: client version 1.24 is too old.
Minimum supported API version is 1.40, please upgrade your client to a newer version
これはDockerデーモン側が、接続してきたクライアント(この場合はTraefik内蔵のDockerクライアント)のAPIバージョンが古すぎるとして拒否しているメッセージのようでした。TraefikはAPIバージョン1.24で接続を試みているのに対し、デーモン側が最小サポートバージョンを1.40に引き上げていたため、両者がかみ合っていない状態でした。
Docker providerで動くTraefikは、起動時およびイベント受信時にDocker APIからコンテナ情報を取得してルーティング表を構築します。このAPI接続が拒否されると、ルーティング設定そのものを読み込めず、結果として配下のすべてのサービスへ振り分けができなくなります。Drupalが落ちていたのではなく、Drupalへの経路が引けていなかった、という構図でした。
根本原因
サーバーの履歴を確認すると、2026-04-30に apt-get -y upgrade が実行され、その際にDocker CEがメジャーバージョンを含めてアップグレードされていました(調査した限りでは 26.1.2 から 29.4.1 への更新でした)。
新しいDocker EngineはAPIの最小サポートバージョンを引き上げており、それ未満のクライアントからの接続を拒否するようになっていたようです。一方で、稼働していたTraefik(v3.2、2025年初頭のビルド)に内蔵されたDockerクライアントは、引き続きAPIバージョン1.24で接続を試みていました。
Docker Engineのアップグレードに伴ってDockerサービスが再起動された際、Traefikコンテナも再起動されています。このタイミングで、新しいデーモンに対してTraefikがAPI接続を試みたものの拒否され、ルーティング設定を読み込めない状態に陥った、というのが一連の流れと考えられます。
整理すると、次の3点が重なって発生した障害でした。
apt-get upgradeがサードパーティリポジトリ由来のDocker CEをメジャーバージョンまで更新した- 新しいDocker EngineがAPIの最小サポートバージョンを引き上げ、古いクライアントを拒否するようになった
- 稼働中のTraefikが古いAPIバージョンで接続を試みており、デーモンの更新後に互換性が失われた
対応
Traefikのイメージを、マイナーバージョン固定の traefik:v3.2 から、v3系の最新を指す traefik:v3 に更新して再起動しました。新しいTraefikであれば、内蔵Dockerクライアントも新しいAPIバージョンに対応していると見込んでの対応です。
# docker-compose.yml(変更箇所)
services:
traefik:
- image: traefik:v3.2
+ image: traefik:v3
cd /home/ubuntu/traefik
docker compose pull
docker compose up -d
再起動後、TraefikがDocker APIと正常に通信できるようになり、Drupalへのルーティングが復旧しました。Drupal・MariaDB側には変更を加えていません。
再発防止
今回の障害は、リバースプロキシ単体ではなく「OS全体のパッケージ更新」と「コンテナ基盤(Docker Engine)のメジャーアップグレード」と「それに追従できていないクライアント(Traefik)」が連鎖して起きたものでした。再発を防ぐ観点として、現時点では次のような選択肢を検討しています。
Docker Engineのバージョンを固定する
Docker CEはサードパーティリポジトリ(download.docker.com)から提供されており、apt-get upgrade を実行するとメジャーバージョンを含めて更新されます。意図しないメジャーアップグレードを避けるには、パッケージを保留(hold)してアップグレード対象から外す方法があります。
sudo apt-mark hold docker-ce docker-ce-cli containerd.io
保留したパッケージは、更新する際に意識的に解除して対応する運用になります。
Traefikのイメージタグをv3系の最新に追従させる
マイナーバージョンを固定(traefik:v3.2)していると、Docker API側の互換性変更に追従できず、今回のように取り残されることがあります。traefik:v3 のようにメジャーバージョン系列の最新を参照しておくと、Docker APIの互換性問題を受けにくくなります。執筆時点(2026-06)では、Traefikの最新メジャーはv3系列で(v4は未リリース)、最新安定版はv3.7系列のようです。Traefikのサポートポリシー上、アクティブにサポートされるのは最新マイナーのみで、新しいマイナーが出ると前のマイナーはEOL扱いになるため、特定マイナーを固定し続けるとサポート・互換性の両面で取り残されやすい点も、系列最新を追う動機になります。一方で、メジャー系列内の予期しない挙動変化を取り込むリスクとのトレードオフになるため、更新時の動作確認とセットで運用するのが無難です。
一括アップグレードの運用を見直す
サードパーティパッケージを含む全パッケージを apt-get upgrade で一括更新するのは、今回のようにコンテナ基盤のメジャーバージョンまで巻き込むリスクがあります。セキュリティ更新に限定する運用(例えば unattended-upgrades のセキュリティアップデートのみを自動適用する設定)に寄せておくと、想定外のメジャーアップグレードを避けやすくなります。
まとめ
アプリケーションが落ちていなくても、前段のリバースプロキシがコンテナ基盤のAPIに接続できなくなると、サイト全体がアクセス不能になります。今回はDocker Engineのメジャーアップグレードが引き金で、稼働中のTraefikが古いAPIバージョンのまま取り残されていたことが原因でした。コンテナ基盤を apt-get upgrade の一括更新対象に含めたままにしておくと、再起動のタイミングで同種の互換性問題が顕在化しうるため、バージョン固定や更新運用の見直しを行う予定です。
コメント
…