はじめに

Windows で Rancher Desktop + VS Code の Dev Containers を使って開発環境を作っていたところ、docker コマンドが Docker 本体に接続できなくなりました。

再起動すると一時的に直るものの、しばらくするとまた発生する、という分かりにくい症状でした。調べたところ Rancher Desktop 1.24.0 の不具合として GitHub の Issue で報告されていたので、原因と回避策をまとめます。

この記事の内容は 2026年10月24日時点の情報です。修正版がリリースされている場合は、Rancher Desktop を更新するのが一番確実です。

環境

Windows 11
Rancher Desktop 1.24.0
- Container Engine: dockerd (moby)
- Kubernetes: 無効
WSL2
VS Code + Dev Containers 拡張機能

症状

PowerShell で docker version を実行すると、Client の情報は表示されるのに、Server の部分がエラーになります。

PS C:\Users\<user>\project> docker version
Client:
 Version:           29.6.2-rd
 API version:       1.55
 Go version:        go1.26.4
 Git commit:        ede120b
 Built:             Fri Jul 17 17:00:40 2026
 OS/Arch:           windows/amd64
 Context:           default
Error response from daemon: failed to connect to the backend: timed out dialing Hyper-V socket

VS Code の Dev Containers では「Docker デーモンが実行されていることを確認します」というエラーが出て、コンテナを開けませんでした。

WSL のディストリビューション自体は正常に動いていました。

PS> wsl -l -v
  NAME                    STATE           VERSION
* Ubuntu                  Stopped         2
  rancher-desktop         Running         2
  rancher-desktop-data    Stopped         2

特徴的だったのは次の点です。

Rancher Desktop や PC を再起動すると、一時的に直る
ただし、しばらくすると(起動してから1〜3分ほどで)また発生する

通信の経路と、止まっていた場所

Windows 側の docker コマンドが Docker 本体に届くまでの経路は、次のようになっています。

docker.exe(Windows)
   │  名前付きパイプ(\\.\pipe\docker_engine)
   ▼
Rancher Desktop(Windows 側のプロセス)
   │  Hyper-V socket   ← ここでタイムアウト
   ▼
docker-proxy(WSL2 の rancher-desktop ディストリビューション内)
   │
   ▼
dockerd(Docker 本体)

Error response from daemon という応答が返ってきているので、docker.exe から Rancher Desktop までは届いています。止まっているのはその先で、WSL2 内の中継プログラム(docker-proxy)が Hyper-V socket の接続に応答していない状態です。

原因

GitHub の Issue #11130 で、Rancher Desktop のメンテナー(jandubois 氏)のアカウントから投稿されたコメントによると、原因は次のとおりです。このコメントは Claude Code で作成したものと明記されています。元の報告である #10739 でも、同じ内容の原因が議論されています。

Rancher Desktop は、WSL 内の dockerd が正常に動いているかを定期的に確認(ヘルスチェック)している
1.24.0 では、このヘルスチェックに http://./_ping という URL を使っている
ディストリビューションに入っている新しい curl は、この URL を Bad hostname として受け付けない
そのため、ヘルスチェックが毎回失敗し、docker-proxy に停止の命令(SIGTERM)が送られる
docker-proxy は待ち受けを閉じるだけで、プロセスは終了せずに残り続ける
結果として、Windows からの接続に誰も応答しなくなり、タイムアウトになる

再起動すると直るのは、ヘルスチェックが最初に走るまでの1〜3分の間だけ正常に動くためでした。

回避策

修正版が出るまでの回避策として、Issue #11130 の同じコメントで案内されている方法を使います。ヘルスチェックの URL を http://localhost/_ping に書き換えるものです。

WSL 内の設定ファイルを直接書き換えても、Rancher Desktop を起動するたびに元に戻ってしまいます。そのため、起動のたびに自動で実行される provisioning スクリプトとして置きます。

1. Rancher Desktop を終了する

タスクトレイのアイコンを右クリックして Quit します。

2. スクリプトを作成する

エクスプローラーのアドレス欄に次を入力してフォルダを開きます。provisioning フォルダがなければ作成します。

%LOCALAPPDATA%\rancher-desktop\provisioning

このフォルダに、次の内容で fix-docker-healthcheck.start というファイルを作ります。

fix-docker-healthcheck.start

sed -i 's|http://\./_ping|http://localhost/_ping|g' /etc/init.d/docker

改行コードは LF にしてください。 CRLF のままだとスクリプトが正しく動きません。
VS Code で作る場合は、右下の「CRLF」をクリックして「LF」に切り替えてから保存します。
メモ帳で作ると、改行コードが CRLF になったり、拡張子に .txt が付いたりするので注意してください。

3. Rancher Desktop を起動する

起動して、準備が完了するまで待ちます。

4. 確認する

URL が書き換わっているかを確認します。

wsl -d rancher-desktop grep _ping /etc/init.d/docker

http://localhost/_ping と表示されれば成功です。http://./_ping のままの場合は、スクリプトが動いていません。改行コードとファイル名を見直してください。

この不具合は起動から1〜3分後に起きるので、5分ほど待ってから docker version を実行します。

docker version

Server: の情報が表示されれば、回避できています。

その他の回避策

Issue のスレッドでは、ほかに次の方法も報告されています。

Rancher Desktop を終了し、wsl --shutdown を実行してから起動し直す(一時的な対処)
1.23.1 にダウングレードする

修正の状況

修正は Pull Request #10740 で対応されています。内容は次の2点です。

ヘルスチェックの URL を http://localhost/_ping に変更する(今回の回避策と同じ内容)
docker-proxy が SIGTERM を受けたときに正しく終了し、再起動されるようにする

2026年10月24日時点では、この修正を含むバージョンはまだリリースされていません。Issue #11130 のコメントでは「次のリリースに含まれる予定」とされています。

修正版に更新したら、fix-docker-healthcheck.start は削除しておきましょう。

まとめ

timed out dialing Hyper-V socket は、Windows から WSL2 内の Docker への中継が応答しないときに出る
Rancher Desktop 1.24.0 では、ヘルスチェックの URL が新しい curl で失敗することが原因で、起動から1〜3分後に発生する
provisioning スクリプトでヘルスチェックの URL を書き換えると回避できる
修正版が出たら更新し、スクリプトを削除する

再起動で直るので見過ごしがちですが、何度も再発する場合はこの不具合を疑ってみてください。

参考