---

一次完整的 Docker 啟動失敗排錯之旅：從 start-limit 到 network not found

你是否也曾自信地敲下 sudo systemctl start docker，卻只得到一個冰冷的 failed？這是一個開發者和運維工程師都可能遇到的場景。本文將通過一個真實的排錯案例，帶你一步步地剖析問題、定位根源、解決故障，最終讓 Docker 服務起死回生。

第一幕：初見端倪 - Active: failed (Result: start-limit)

一切始于一個常規的 Docker 服務啟動命令，但系統卻返回了錯誤。我們立刻檢查服務狀態：

$ systemctl status docker.service
● docker.service - Docker Application Container EngineLoaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)Active: failed (Result: start-limit) since Tue 2025-08-05 23:23:57 CST; 41s agoProcess: 12037 ExecStart=/usr/bin/dockerd ... (code=exited, status=1/FAILURE)Main PID: 12037 (code=exited, status=1/FAILURE)Aug 05 23:23:57 my-linux-server systemd[1]: Failed to start Docker Application Container Engine.
Aug 05 23:23:57 my-linux-server systemd[1]: docker.service failed.

診斷分析：
Active: failed 告訴我們服務失敗了，但更關鍵的是 Result: start-limit。這表示 systemd 在短時間內多次嘗試啟動 Docker 守護進程 (dockerd)，但每次都以失敗告終。為了保護系統，systemd 決定暫時放棄。

核心教訓 #1：systemctl status 只告訴我們“發生了什么”，但要了解“為什么發生”，我們必須深入日志。

第二幕：深挖日志 - ZONE_CONFLICT 防火墻沖突

我們使用 journalctl 來查看 Docker 服務的詳細日志：

$ journalctl -u docker.service --no-pager
...
Aug 05 23:23:55 my-linux-server dockerd[12037]: failed to start daemon: Error initializing network controller: error creating default "bridge" network: Failed to program NAT chain: ZONE_CONFLICT: 'docker0' already bound to a zone
...

診斷分析：
問題清晰了！錯誤是 ZONE_CONFLICT: 'docker0' already bound to a zone。
這通常發生在啟用了 firewalld 的系統（如 CentOS/RHEL）上。Docker 嘗試創建和管理 docker0 網橋并配置 NAT 規則，但 firewalld 防火墻發現 docker0 接口已經被分配到了一個防火墻區域（zone），從而阻止了 Docker 的操作，導致沖突。

解決方案：
我們需要明確告訴 firewalld，docker0 是一個可信的接口，讓 Docker 自行管理。

# 1. 將 docker0 接口永久添加到 trusted 區域
sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0# 2. 重新加載防火墻規則使之生效
sudo firewall-cmd --reload

第三幕：峰回路轉 - 新的錯誤 networks have same bridge name

在解決了防火墻問題后，我們再次嘗試啟動 Docker，但依舊失敗。查看最新的日志，發現錯誤變了：

$ journalctl -u docker.service --no-pager
...
Aug 05 23:33:31 my-linux-server dockerd[3762]: failed to start daemon: Error initializing network controller: ... conflicts with network ...: networks have same bridge name
...

診斷分析：
這個錯誤 networks have same bridge name 意味著 Docker 內部的網絡狀態出現了不一致。很可能是由于之前的反復失敗和異常關閉，導致 Docker 的網絡數據庫文件 (/var/lib/docker/network/files/local-kv.db) 損壞或包含了陳舊的、沖突的數據。

解決方案：
清理 Docker 損壞的網絡狀態文件，讓它在下次啟動時重建一個干凈的狀態。

# 停止 Docker 服務（如果正在嘗試運行）
sudo systemctl stop docker.service# 刪除網絡狀態數據庫文件
sudo rm /var/lib/docker/network/files/local-kv.db

注意：此操作是安全的，僅重置網絡定義，不會影響鏡像和容器數據。

第四幕：撥云見日 - 徹底的清理與重啟

在修復過程中，我們還遇到了配置沖突（-b 和 --bip 互斥）以及一個關鍵的系統警告：

$ sudo systemctl stop docker.service
Warning: Stopping docker.service, but it can still be activated by:docker.socket

診斷分析：
這個警告揭示了 systemd 的“套接字激活”機制。即使我們停止了 docker.service，docker.socket 依然在監聽。任何 docker 命令的調用都會通過 socket 自動喚醒服務，這可能在我們修復過程中造成干擾。

最終的、完整的解決方案：
我們需要一次徹底的、不受干擾的清理和重啟。

1. 徹底停止 Docker，包括服務和套接字。

   sudo systemctl stop docker.socket
   sudo systemctl stop docker.service
   

2. 重置配置文件，排除所有自定義配置的干擾。編輯 /etc/docker/daemon.json，將其內容清空為 {}。

   sudo nano /etc/docker/daemon.json
   # 文件內容修改為:
   # {}
   

3. 清理損壞的網絡狀態（我們在第三幕中已執行）。

   sudo rm /var/lib/docker/network/files/local-kv.db
   

4. 重置并重啟。

   sudo systemctl daemon-reload
   sudo systemctl reset-failed docker.service
   sudo systemctl start docker.service
   

執行完這一系列操作后，systemctl status docker.service 終于顯示了久違的綠色 active (running)！

第五幕：最后的勝利 - 解決應用層的 network not found

Docker 守護進程終于正常運行了。但當我們用 docker-compose 啟動應用時，又遇到了最后一個問題：

Error response from daemon: network a_very_long_id not found

診斷分析：
這是一個預期中的“錯誤”。因為我們清除了 Docker 的所有網絡狀態，它“忘記”了之前由 docker-compose 創建的自定義網絡。而我們的應用配置（docker-compose.yml）仍然指向那個已經被遺忘的網絡 ID。

解決方案：
讓 docker-compose 徹底重建整個應用棧，包括它所需的網絡。

1. 進入你的項目目錄。

   cd /path/to/your/project
   

2. 拆除舊的應用棧，移除所有狀態不一致的容器和網絡定義。

   sudo docker-compose down
   

3. 重新構建并啟動，-d 表示后臺運行，--build 強制重新構建鏡像。

   sudo docker-compose up -d --build
   

docker-compose 會發現網絡不存在，于是自動創建一個新的、干凈的網絡，并啟動新的容器連接到該網絡。至此，所有問題都已解決，應用恢復正常。

總結與啟示

這次排錯之旅告訴我們：

1. 日志是你的羅盤：systemctl status 只是起點，journalctl 才是幫你找到方向的工具。
2. 理解系統交互：Docker 并非孤立運行，它與 systemd、firewalld 等系統服務緊密交互。ZONE_CONFLICT 就是典型的例子。
3. 注意隱藏機制：docker.socket 的套接字激活機制很容易被忽略，但在關鍵時刻它可能是導致問題反復出現的“幕后黑手”。
4. 敢于重置狀態：當內部狀態（如網絡數據庫）損壞時，備份后大膽地清理并讓服務重建，往往是最高效的解決方案。
5. 分清層次：要區分是 Docker 守護進程 的問題，還是 應用層（如 docker-compose）的配置問題。守護進程恢復后，應用層也需要同步更新。

希望這次的經歷能為你在未來的 Docker 排錯道路上提供一份有用的地圖。