# 搞懂 Chrome Remote Debugging：--autoConnect、9222 與 CDP 的差異

最近我在研究 Chrome DevTools MCP 時，遇到一個讓我困惑的問題：明明在 **chrome://inspect/#remote-debugging** 啟用了 Remote Debugging，也看到 **Server running at: 127.0.0.1:9222**，但 **curl http://127.0.0.1:9222/json/version** 卻回傳 **HTTP 404 Not Found**。深入研究後才發現，這其實是兩種不同的「連線建立方式」——以下就是完整的來龍去脈。

![搞懂 Chrome Remote Debugging：--autoConnect、9222 與 CDP 到底差在哪？](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/3acccdb7b48fac343944-65fbc4c9-6bd9-4ffd-93a8-81c4da0eed26.webp)

我第一個反應就是：「難道是 Chrome 版本跟 CDP 版本對不起來？」後來仔細研究才發現，完全不是這麼一回事。從 Chrome 144 開始，Chrome 多了一套專門給 Chrome DevTools MCP 使用的 Auto Connect 機制，而它雖然一樣叫做 Remote Debugging，也一樣可能使用 **127.0.0.1:9222**，甚至底層最終也還是走 Chrome DevTools Protocol，但它跟我們過去熟悉的 **\--remote-debugging-port=9222** 其實是兩種不同的「連線建立方式」。這篇文章我就打算完整整理 **\--autoConnect**、**127.0.0.1:9222**、傳統 Remote Debugging Port 與 CDP 之間到底是什麼關係。

### 先講最重要的結論：Auto Connect 與傳統 Remote Debugging 最後都還是 CDP

這裡我覺得最容易產生的一個誤解，就是把 `--autoConnect` 跟「走 CDP」當成兩種互斥的技術。其實這個說法並不精確。

Chrome DevTools MCP 不管是透過：

-   `--autoConnect`
-   `--browser-url=http://127.0.0.1:9222`
-   `--wsEndpoint=ws://...`

最後真正控制 Chrome、讀取 DOM、監控 Network、執行 JavaScript、擷取 Performance Trace 的底層協定，基本上仍然是 **Chrome DevTools Protocol，簡稱 CDP**。

真正不同的地方其實是：

**「我要怎麼找到 CDP 的 WebSocket Endpoint，以及 Chrome 要不要讓我連進去？」**

傳統 Remote Debugging 的答案是：

> 我直接開一個 TCP Port，提供 HTTP Discovery API，任何能連到這個 Port 的程式都可以找到 CDP WebSocket Endpoint。

Chrome 144+ Auto Connect 的答案則變成：

> 我讓目前正在使用的 Chrome 啟動一個經過使用者授權的 Remote Debugging 機制，由 Chrome DevTools MCP 自動找到它，然後每次有人想控制瀏覽器時，Chrome 都會跳出授權視窗要求使用者確認。

所以兩邊的差異主要是在 **Discovery、Connection 與 Permission Model**，而不是 CDP 本身。

### 傳統的 Chrome Remote Debugging 到底是怎麼運作的

如果你以前有用過 Puppeteer、Playwright、Selenium、ChromeDriver 或直接操作 CDP，應該對下面這個參數不陌生：

```bash
google-chrome --remote-debugging-port=9222
```

Chrome 啟動之後，就會在本機開啟一個 HTTP Server，例如：

```
http://127.0.0.1:9222
```

這個 HTTP Server 有一組很簡單的 Discovery API。

例如：

```bash
curl http://127.0.0.1:9222/json/version
```

正常情況下會得到類似以下結果：

```json
{
  "Browser": "Chrome/150.0.xxxx.xx",
  "Protocol-Version": "1.3",
  "User-Agent": "...",
  "V8-Version": "...",
  "WebKit-Version": "...",
  "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
```

其中最重要的其實就是：

```json
"webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/..."
```

真正的 CDP 通訊不是一直透過 HTTP 傳送，而是 Client 先透過 HTTP Discovery API 找到這個 WebSocket URL，接著再建立 WebSocket 連線。

完整流程大概長這樣：

```
CDP Client
    |
    | HTTP GET /json/version
    v
127.0.0.1:9222
    |
    | 回傳 webSocketDebuggerUrl
    v
ws://127.0.0.1:9222/devtools/browser/{id}
    |
    | WebSocket
    v
Chrome DevTools Protocol
    |
    v
  Chrome
```

所以我們以前講的「9222 Remote Debugging Port」，其實裡面同時包含了兩件事情：

1.  HTTP Discovery API
2.  CDP WebSocket Endpoint

這個觀念非常重要。

### 傳統 Remote Debugging Port 還有哪些 HTTP API

除了 `/json/version` 之外，Chrome 傳統 Remote Debugging Port 還提供不少 HTTP Endpoint。

例如：

```
GET /json/version
```

取得 Browser 與 Protocol Version，以及 Browser-level WebSocket Endpoint。

還可以：

```
GET /json
GET /json/list
```

取得目前所有可以被偵錯的 Targets，例如瀏覽器中的 Tab。

回傳內容大概像這樣：

```json
[
  {
    "id": "DAB7FB6187B554E10B0BD18821265734",
    "type": "page",
    "title": "The Will Will Web",
    "url": "https://blog.miniasp.com/",
    "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/page/DAB7FB6187B554E10B0BD18821265734"
  }
]
```

甚至還有：

```
GET /json/protocol
PUT /json/new?https://example.com/
GET /json/activate/{targetId}
GET /json/close/{targetId}
```

這就是傳統 CDP Remote Debugging 最典型的 Discovery Model。

也因為如此，很多第三方工具只要知道：

```
http://127.0.0.1:9222
```

就可以自己取得 `/json/version`，找到 `webSocketDebuggerUrl`，然後直接控制 Chrome。

### Chrome DevTools MCP 的 --browser-url 其實就是走這套傳統機制

Chrome DevTools MCP 本身就支援這種模式。

例如：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}
```

這裡的：

```
--browser-url=http://127.0.0.1:9222
```

意思不是「WebSocket 就在這個 URL」。

這個 URL 其實是告訴 Chrome DevTools MCP：

> 這裡有一台支援傳統 Remote Debugging Discovery API 的 Chrome，你自己去找它的 CDP WebSocket Endpoint。

所以概念上會變成：

```
AI Agent
   |
   | MCP
   v
chrome-devtools-mcp
   |
   | --browser-url
   v
http://127.0.0.1:9222
   |
   | GET /json/version
   v
webSocketDebuggerUrl
   |
   | WebSocket
   v
  CDP
   |
   v
 Chrome
```

這也就解釋了為什麼如果：

```bash
curl http://127.0.0.1:9222/json/version
```

拿到的是：

```
HTTP 404 Not Found
```

那麼：

```
--browser-url=http://127.0.0.1:9222
```

通常也不會正常工作。

因為它期待的是「傳統 HTTP Discovery Endpoint」。

### Chrome 136 開始對傳統 Remote Debugging Port 做了重要的安全限制

講到這裡還有一個非常重要的版本變更一定要知道。

從 Chrome 136 開始，Google 強化了 `--remote-debugging-port` 與 `--remote-debugging-pipe` 的安全機制。

以前你可能直接這樣啟動：

```bash
google-chrome --remote-debugging-port=9222
```

然後直接對你平常使用的 Chrome Profile 開 Remote Debugging。

這件事現在已經被 Chrome 限制了。

從 Chrome 136 開始，如果你使用的是 Chrome 預設 User Data Directory，Chrome 會忽略 `--remote-debugging-port` 與 `--remote-debugging-pipe`。

你必須另外指定一個非預設的：

```
--user-data-dir
```

例如 macOS 可以這樣：

```bash
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-stable
```

Linux 可以這樣：

```bash
/usr/bin/google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-stable
```

Windows 可以這樣：

```powershell
"C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\chrome-profile-stable"
```

原因其實非常合理。

因為只要有人可以控制你平常使用的 Chrome Profile，他理論上也可能接觸到：

-   Cookies
-   Local Storage
-   Session Storage
-   已經登入的網站
-   OAuth Session
-   企業內網系統
-   個人帳號資訊

過去甚至已經出現惡意程式透過 Chrome Remote Debugging 竊取 Cookie 的攻擊方式，所以 Google 才在 Chrome 136 對這個行為進一步限制。

換句話說，**傳統 Remote Debugging Port 現在比較適合專門建立一個獨立的 Automation Profile，而不是直接控制你每天使用的 Chrome Profile。**

### 那如果我就是想讓 AI Agent 操作「我現在正在使用的 Chrome」怎麼辦

這其實正是 Chrome DevTools MCP `--autoConnect` 想要解決的問題。

傳統 Remote Debugging 的作法是：

```
Chrome 啟動
    +
--remote-debugging-port
    +
--user-data-dir
```

這通常意味著你要另外啟動一套 Chrome Profile。

可是對 AI Coding Agent 來說，很多時候我們真正想要的是：

> 我現在已經登入系統了，我也已經把 Bug 重現出來了，你直接進來看我現在這個 Tab 就好。

例如：

-   公司內部系統需要 Entra ID 登入
-   網站需要 Google OAuth
-   系統需要 VPN 才能存取
-   已經走完一個很複雜的購物流程
-   已經手動操作到某個特殊狀態
-   Bug 只有在特定 Extension 存在時才會出現
-   我已經在 DevTools Network Panel 找到可疑 Request

如果還要叫 AI Agent 自己開一套全新的 Chrome，然後重新登入、重新建立 Session、重新操作一次，實在非常麻煩。

所以從 Chrome 144 開始，Chrome DevTools 加入了新的 Auto Connect Remote Debugging Flow。

### Chrome 144 的 --autoConnect 到底做了什麼

首先，你要在你平常使用中的 Chrome 開啟：

```
chrome://inspect/#remote-debugging
```

然後啟用：

```
Allow remote debugging for this browser instance
```

Chrome 會開始提供一個 Remote Debugging Server。

接著 Chrome DevTools MCP 可以這樣設定：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--autoConnect"
      ]
    }
  }
}
```

這裡最重要的地方是：

```
--autoConnect
```

你完全不需要告訴 MCP：

```
http://127.0.0.1:9222
```

也不需要提供：

```
ws://127.0.0.1:9222/devtools/browser/...
```

Chrome DevTools MCP 會自行尋找本機正在執行，而且已經開啟 Remote Debugging 的 Chrome。

當 MCP 要建立 Debugging Session 時，Chrome 還會跳出一個確認視窗，詢問你是否允許這次 Remote Debugging Connection。

也就是說，新的流程比較像這樣：

```
AI Agent
    |
    | MCP
    v
chrome-devtools-mcp --autoConnect
    |
    | 尋找本機 Chrome
    v
Running Chrome
    |
    | Request Remote Debugging Session
    v
Chrome 顯示權限確認視窗
    |
    | 使用者按下 Allow
    v
建立 Remote Debugging Session
    |
    | WebSocket
    v
Chrome DevTools Protocol
```

請注意最後面仍然是：

```
Chrome DevTools Protocol
```

所以 **Auto Connect 並沒有取代 CDP，而是改變了 CDP 連線建立與授權的方式。**

### 最容易讓人誤會的就是 127.0.0.1:9222

麻煩的地方就在這裡。

當你在：

```
chrome://inspect/#remote-debugging
```

啟用 Remote Debugging 之後，你可能看到 Chrome 顯示：

```
Server running at: 127.0.0.1:9222
```

看到這裡，只要以前碰過 CDP 的人，大概馬上就會聯想到：

```bash
google-chrome --remote-debugging-port=9222
```

然後很自然地測試：

```bash
curl http://127.0.0.1:9222/json/version
```

結果：

```
HTTP/1.1 404 Not Found
Content-Length: 0
```

這時候非常容易誤判成：

-   Chrome 壞掉
-   Remote Debugging 沒有成功
-   CDP Version 不相容
-   MCP 版本太舊
-   9222 被其他程式占用

但其實不一定。

Chrome 144+ 透過 `chrome://inspect/#remote-debugging` 開啟的這套 Remote Debugging Flow，**不能直接視為傳統 `--remote-debugging-port=9222` 所建立的 HTTP Discovery Server。**

目前這套 Auto Connect Remote Debugging Server 的使用方式是由 Auto Connect 流程取得 WebSocket Debugging Connection，而不是要求外部 Client 透過：

```
/json/version
/json
/json/list
```

進行 Discovery。

所以：

```bash
curl http://127.0.0.1:9222/json/version
```

拿到 `404`，並不能證明 Remote Debugging 沒有啟動。

更不能直接推論成 CDP Version Mismatch。

### 為什麼兩個都是 9222，行為卻不一樣

原因很簡單：

**Port Number 只代表 TCP Listener 在哪裡，並不代表上面的 Application Protocol 一定提供完全相同的 API。**

舉個簡單的概念：

```
127.0.0.1:9222
```

只是在說：

```
IP Address = 127.0.0.1
TCP Port   = 9222
```

至於上面到底提供：

```
GET /json/version
```

還是只提供某種 WebSocket Remote Debugging Flow，完全是 Chrome 自己決定的。

所以這兩種狀況看起來可能都是：

```
127.0.0.1:9222
```

但實際能力完全不同。

傳統模式：

```
--remote-debugging-port=9222

127.0.0.1:9222
    |
    +-- HTTP /json/version
    +-- HTTP /json/list
    +-- HTTP /json/protocol
    +-- WebSocket CDP
```

Chrome 144+ Auto Connect 模式則比較接近：

```
chrome://inspect/#remote-debugging

127.0.0.1:9222
    |
    +-- Permission-controlled Remote Debugging
    +-- WebSocket Debugging Connection
    +-- CDP
    |
    +-- 傳統 HTTP Discovery API 不應假設一定存在
```

這也是整篇文章試圖說明的核心差異。

### \--browser-url 與 --autoConnect 其實不能直接互換

所以假設你做了這件事：

```
chrome://inspect/#remote-debugging
```

看到：

```
Server running at: 127.0.0.1:9222
```

然後 MCP 設成：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}
```

這兩者其實並不是官方設計上互相搭配的組合。

如果你使用的是：

```
chrome://inspect/#remote-debugging
```

官方建議搭配的是：

```
--autoConnect
```

也就是：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--autoConnect"
      ]
    }
  }
}
```

如果你使用的是：

```
--browser-url=http://127.0.0.1:9222
```

那你應該真的用傳統方式啟動 Chrome：

```bash
google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-debug-profile
```

然後先確認：

```bash
curl http://127.0.0.1:9222/json/version
```

可以正常取得 JSON。

這兩套設定最好不要混在一起理解。

### 如果我已經知道 WebSocket Endpoint，也可以直接使用 --wsEndpoint

Chrome DevTools MCP 還提供第三種比較底層的方式：

```
--wsEndpoint
```

例如：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=ws://127.0.0.1:9222/devtools/browser/xxxxxxxx"
      ]
    }
  }
}
```

這個模式跟 `--browser-url` 最大的差異就是：

`--browser-url`：

```
給我 HTTP Discovery URL
↓
我自己去找 webSocketDebuggerUrl
↓
建立 WebSocket
```

`--wsEndpoint`：

```
你直接把 WebSocket Endpoint 給我
↓
直接建立 WebSocket
```

所以可以把三種模式整理成：

| Chrome DevTools MCP 設定 | 你提供什麼 | Discovery | 最後通訊 |
| --- | --- | --- | --- |
| `--autoConnect` | 不用提供 URL | MCP + Chrome 自動處理 | CDP over WebSocket |
| `--browser-url` | HTTP URL | `/json/version` 等 HTTP Discovery | CDP over WebSocket |
| `--wsEndpoint` | WebSocket URL | 不需要 | CDP over WebSocket |

你會發現最後一欄完全一樣。

全部都是：

```
CDP over WebSocket
```

所以再次強調：

**這不是 Auto Connect vs. CDP，而是三種不同的「找到並建立 CDP Connection」的方法。**

### 三種模式的完整架構圖

傳統 `--browser-url`：

```
AI Agent
   |
   | MCP
   v
Chrome DevTools MCP
   |
   | HTTP
   | GET /json/version
   v
127.0.0.1:9222
   |
   | webSocketDebuggerUrl
   v
ws://127.0.0.1:9222/devtools/browser/{id}
   |
   | CDP
   v
Chrome
```

直接 `--wsEndpoint`：

```
AI Agent
   |
   | MCP
   v
Chrome DevTools MCP
   |
   | WebSocket
   v
ws://127.0.0.1:9222/devtools/browser/{id}
   |
   | CDP
   v
 Chrome
```

Chrome 144+ `--autoConnect`：

```
AI Agent
   |
   | MCP
   v
Chrome DevTools MCP
   |
   | Auto Connect
   v
正在執行的 Chrome
   |
   | 使用者授權
   v
Remote Debugging Session
   |
   | WebSocket
   v
  CDP
   |
   v
目前的 Chrome Profile / Tabs
```

這三張圖放在一起看，整個概念應該就非常清楚了。

### \--autoConnect 最大的優點是可以直接繼承你目前的瀏覽器狀態

這也是我認為 Auto Connect 對 AI Coding Agent 最有價值的地方。

假設我現在正在開發一套後台系統，而且網站需要：

```
Entra ID
    ↓
   MFA
    ↓
   VPN
    ↓
企業內部權限
```

傳統 Automation Browser 如果另外開一個乾淨 Profile，光登入就很麻煩。

Auto Connect 則可以直接使用你目前的 Chrome Session。

因此 AI Agent 可以直接看到：

-   目前開啟的 Tabs
-   已登入的網站
-   Cookies
-   Local Storage
-   Session Storage
-   Browser Extensions
-   當前 Application State
-   目前頁面的 DOM
-   Network Requests
-   Console Messages
-   Performance Data

例如我已經手動把 Bug 重現出來了，就可以直接對 Coding Agent 說：

```
我已經在目前 Chrome 的下一個 Tab 把問題重現出來了，
請使用 Chrome DevTools 檢查為什麼按下 Save 按鈕後 API 回傳 400。
```

Agent 不需要：

```
開 Chrome
→ 登入
→ MFA
→ 找頁面
→ 填表單
→ 重現問題
```

而是可以直接：

```
接手我現在的 Browser State
→ 開始 Debug
```

這個工作流程對實際開發非常實用。

### 但 --autoConnect 的權限其實也非常大

Auto Connect 好用歸好用，但一定要理解它的安全性。

因為你讓 Coding Agent 接上的，不是一個乾淨、隔離的測試瀏覽器。

而是：

**你自己正在使用，而且很可能已經登入很多網站的 Chrome Profile。**

Chrome 官方也特別提醒，Auto Connect 啟用後，Agent 可能可以接觸到 Browser Profile 中的：

-   開啟中的頁面
-   Cookies
-   Session Storage
-   Local Storage
-   透過 JavaScript API 可以取得的資料
-   已登入 Session

所以 Auto Connect 比較適合：

```
我信任的 Agent
+
我知道它現在要操作什麼
+
我明確允許這次 Remote Debugging Session
```

而不是：

```
反正 Localhost 就很安全，全部打開就好
```

Localhost 並不等於沒有風險。

這也是為什麼 Chrome 新的 Auto Connect Flow 每次有人要求建立 Remote Debugging Session 時，會透過 UI 向使用者要求授權。

### 傳統 --remote-debugging-port 的安全模型反而更加直接

傳統：

```
--remote-debugging-port=9222
```

的安全模型非常簡單粗暴。

只要能連上這個 Port 的程式，基本上就可能控制 Chrome。

官方文件甚至直接提醒：

> Any application on your machine can connect to this port and control the browser.

所以開啟：

```
--remote-debugging-port=9222
```

的時候，不應該拿你平常使用、已經登入銀行、Email、企業後台的 Profile 來使用。

Chrome 136 之後強制搭配非預設 `--user-data-dir`，本質上也是在減少這類風險。

Auto Connect 則採用了另一個方向：

```
允許使用真正的 User Profile
+
每次連線時要求使用者授權
```

兩者其實是在解決完全不同的使用情境。

### 我會怎樣選這三種方式

如果我的目的是：

**讓 Coding Agent 接手我目前正在使用的 Chrome，直接 Debug 已登入的網站。**

我會選：

```
--autoConnect
```

如果我的目的是：

**建立一套固定的 Browser Automation Environment，例如 Playwright、Puppeteer、CI、測試工具或 Sandbox。**

我會選：

```
--remote-debugging-port
+
--user-data-dir
```

然後 MCP 使用：

```
--browser-url
```

如果我的目的是：

**我自己已經知道 CDP WebSocket Endpoint，或需要跨主機、Port Forwarding、Container、WSL 等比較特殊的架構。**

那可以考慮：

```
--wsEndpoint
```

簡單整理如下：

| 使用情境 | 建議方式 |
| --- | --- |
| 操作目前日常使用中的 Chrome | `--autoConnect` |
| 保留既有登入狀態 | `--autoConnect` |
| AI Coding Agent 接手人工 Debug | `--autoConnect` |
| 固定 Automation Browser | `--remote-debugging-port` |
| Puppeteer / Playwright / CDP Client | 傳統 Remote Debugging |
| CI / Container / Sandbox | `--browser-url` |
| 自己管理 WebSocket Endpoint | `--wsEndpoint` |
| 需要 HTTP`/json/version` | 傳統 Remote Debugging Port |

### 如何快速判斷自己現在開的是哪一種 9222

如果你看到：

```
127.0.0.1:9222
```

千萬不要只看 Port Number。

最簡單可以先測：

```bash
curl http://127.0.0.1:9222/json/version
```

如果拿到：

```json
{
  "Browser": "...",
  "Protocol-Version": "...",
  "webSocketDebuggerUrl": "ws://..."
}
```

那你面對的是標準的傳統 Remote Debugging HTTP Discovery Server。

通常適合：

```
--browser-url=http://127.0.0.1:9222
```

如果拿到：

```
HTTP 404 Not Found
```

但你是在：

```
chrome://inspect/#remote-debugging
```

裡面啟用 Remote Debugging，那這個 `404` 本身並不代表 Chrome 壞掉，也不代表 CDP Version Mismatch。

你真正應該測試的是：

```
chrome-devtools-mcp --autoConnect
```

能不能成功要求 Chrome 建立 Debugging Session。

也就是：

**不要拿傳統 Discovery API 的檢測方式，去驗證新的 Auto Connect Flow。**

### HTTP 404 跟 CDP Version Mismatch 是完全不同的兩件事

這個也值得特別講清楚。

如果真的發生 CDP Protocol Version 不相容，通常代表：

```
Client 已經成功找到 Chrome
Client 已經成功建立 Debugging Connection
但是雙方對 Protocol 能力的理解不一致
```

而：

```
GET /json/version
→ HTTP 404
```

發生得更前面。

它代表的是：

```
你打到了一個 HTTP Server
但是這個 Server 沒有提供 /json/version 這個 Resource
```

連：

```
webSocketDebuggerUrl
```

都還沒取得。

所以從 OSI 思維來看，這兩個問題甚至發生在完全不同的階段。

可以想成：

```
HTTP 404
    ↓
Discovery 階段就不符合預期

CDP Version Mismatch
    ↓
已經進入 Protocol Negotiation / Command Compatibility 階段
```

因此看到 `/json/version` 回 `404` 時，第一個要問的不是：

```
Chrome 跟 CDP 版本合不合？
```

而是：

```
我現在連的這個 9222，到底是不是傳統 Remote Debugging HTTP Discovery Server？
```

這個問題通常更接近真正的原因。

### 一個非常實用的 Troubleshooting 流程

以後遇到 Chrome Remote Debugging 問題，我會建議依照以下順序判斷。

第一步，先確認自己打算使用哪一種模式。

如果是：

```
--autoConnect
```

就去：

```
chrome://inspect/#remote-debugging
```

確認 Remote Debugging 已經啟用。

然後直接測試 MCP：

```bash
npx -y chrome-devtools-mcp@latest --autoConnect
```

不要把 `/json/version` 當成這個模式的健康檢查。

如果是：

```
--browser-url
```

則先確認 Chrome 真的是透過：

```
--remote-debugging-port
```

啟動。

Chrome 136+ 還要確認有：

```
--user-data-dir
```

接著測：

```bash
curl http://127.0.0.1:9222/json/version
```

這裡一定要能正常取得 JSON。

最後再設定：

```
--browser-url=http://127.0.0.1:9222
```

如果你用的是：

```
--wsEndpoint
```

那就應該直接確認 WebSocket Endpoint 是否正確，而不是去測 HTTP Discovery API。

### 最後整理一下這幾個名詞

這幾個名詞真的非常容易混在一起，我最後再整理一次。

**Chrome DevTools Protocol，CDP**

這是真正控制 Chrome 的 Protocol。

例如：

```
Page.navigate
Runtime.evaluate
Network.enable
DOM.getDocument
Performance.getMetrics
```

都屬於 CDP。

**Remote Debugging Port**

例如：

```
--remote-debugging-port=9222
```

這是傳統讓外部程式存取 CDP 的方法。

它會提供：

```
HTTP Discovery API
+
WebSocket CDP Endpoint
```

**127.0.0.1:9222**

這只是一組：

```
IP + TCP Port
```

本身並不能證明它一定提供 `/json/version`。

一定要看它是怎麼被 Chrome 啟動的。

**\--browser-url**

Chrome DevTools MCP 使用傳統 HTTP Discovery Endpoint 連線 Chrome 的方式。

例如：

```
--browser-url=http://127.0.0.1:9222
```

**\--wsEndpoint**

跳過 HTTP Discovery，直接告訴 Chrome DevTools MCP CDP WebSocket Endpoint。

**\--autoConnect**

Chrome 144+ 提供的新式連線流程。

讓 Chrome DevTools MCP 自動找到目前執行中的 Chrome，透過使用者授權建立 Remote Debugging Session。

但最後真正控制 Browser 的 Protocol：

**依然是 CDP。**

### 結語

我覺得 Chrome 這次最大的問題並不是設計不好，而是新舊兩套機制使用了非常相似的名詞，甚至預設還可能同樣看到 `127.0.0.1:9222`，對熟悉傳統 CDP 的開發者來說真的很容易產生誤解。以前看到 `9222`，我們很自然就會想到 `--remote-debugging-port=9222`，接著理所當然地存取 `/json/version`；但 Chrome 144 之後，透過 `chrome://inspect/#remote-debugging` 開啟的 Auto Connect Remote Debugging Flow，已經不能再用這個假設來理解。**最重要的觀念就是：Auto Connect 並沒有取代 CDP，它只是提供了一套更適合 AI Coding Agent、更強調使用者授權，而且可以直接接手現有 Browser Session 的 CDP Connection Flow。** 只要先把「CDP Protocol」、「HTTP Discovery」、「Remote Debugging Port」與「Auto Connect」這幾個層次拆開來看，整個架構其實就不複雜了。

### 相關連結

-   [Connect your AI agent to your personal browser with auto-connect](https://developer.chrome.com/docs/devtools/agents/use-cases/auto-connect)
-   [Let your Coding Agent debug your browser session with Chrome DevTools MCP](https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session)
-   [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp)
-   [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)
-   [Changes to remote debugging switches to improve security](https://developer.chrome.com/blog/remote-debugging-port)
-   [Cannot connect with --browser-url to chrome://inspect Remote Debugging](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1194)