The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

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

📅 2026/08/16 08:13 📁 AI, Web

最近我在研究 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 到底差在哪？

我第一個反應就是：「難道是 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，應該對下面這個參數不陌生：

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

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

http://127.0.0.1:9222

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

例如：

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

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

{
  "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"
}

其中最重要的其實就是：

"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。

回傳內容大概像這樣：

[
  {
    "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 本身就支援這種模式。

例如：

{
  "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

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

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 的安全機制。

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

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 可以這樣：

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

Linux 可以這樣：

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

Windows 可以這樣：

"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 可以這樣設定：

{
  "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 的人，大概馬上就會聯想到：

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

然後很自然地測試：

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。

所以：

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 設成：

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

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

如果你使用的是：

chrome://inspect/#remote-debugging

官方建議搭配的是：

--autoConnect

也就是：

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

如果你使用的是：

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

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

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

然後先確認：

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

可以正常取得 JSON。

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

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

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

--wsEndpoint

例如：

{
  "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。

最簡單可以先測：

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

如果拿到：

{
  "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：

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

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

如果是：

--browser-url

則先確認 Chrome 真的是透過：

--remote-debugging-port

啟動。

Chrome 136+ 還要確認有：

--user-data-dir

接著測：

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」這幾個層次拆開來看，整個架構其實就不複雜了。

相關連結

留言評論