Chrome 136 CDP 封鎖預設 Profile 解決方案：自動化腳本實務指南

AI
, , , ,
1

Chrome 136+ 為安全考量封鎖 CDP 存取預設 Profile。掌握複製 Profile、專用自動化目錄、符號連結三大繞過方案，附長期維護腳本建議，解決 browser-use 等自動化工具登入失效問題。

背景：Chrome 136 強化 CDP 安全限制

Chrome 136 版本起，Google 基於安全考量修改 --remote-debugging-port 與 --remote-debugging-pipe 行為：偵測到瀏覽器使用「預設 user-data-dir」啟動時，直接拒絕開啟遠端調試埠口。預設目錄與非預設目錄採用不同加密金鑰，此舉旨在防止攻擊者透過 CDP 竊取已登入帳號的 Cookie、Session 與憑證。

對依賴 CDP 的自動化工具（如 browser-use、Puppeteer、Playwright）而言，直接連接預設 Profile 不再可行。指定 --user-data-dir 指向新路徑雖能繞過封鎖，但會啟動空白 Profile，失去所有登入狀態。

三種社群驗證的繞過方案

方案一：複製既有 Profile 到新目錄（推薦，穩定性最高）

  1. 完全關閉所有 Chrome 進程
  2. 將預設 Profile 完整複製到自訂目錄：
    • macOS：~/Library/Application Support/Google/Chrome/Default → ~/chrome-automation/Default
    • Windows：%LOCALAPPDATA%\Google\Chrome\User Data\Default → C:\chrome-automation\Default
    • Linux：~/.config/google-chrome/Default → ~/chrome-automation/Default
  3. 使用 --user-data-dir=<新目錄父路徑> 啟動 Chrome（注意指向父目錄而非 Default 子目錄）
# macOS 範例
google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=~/chrome-automation

優點：保留完整登入狀態、Cookie、擴充功能設定；官方未禁止此行為，長期可維護。
缺點：需定期同步更新；大量資料複製耗時。

方案二：建立專用自動化 Profile，手動登入一次

  1. 指定新 --user-data-dir 啟動全新 Chrome
  2. 手動完成所有目標網站登入
  3. 後續自動化腳本固定使用此目錄
# 建立專用自動化環境
google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=~/chrome-bot-profile

優點：乾淨隔離，不影響日常瀏覽 Profile；無需同步機制。
缺點：首次需手動登入；多因素驗證（2FA）網站需重新授權；登入狀態過期需人工介入。

方案三：符號連結指向原始目錄（進階，風險自負）

# macOS / Linux
ln -s ~/Library/Application\ Support/Google/Chrome ~/chrome-automation-link

# Windows (管理員權限)
mklink /D C:\chrome-automation-link %LOCALAPPDATA%\Google\Chrome

再以 --user-data-dir=~/chrome-automation-link 啟動。

優點：零複製開銷，即時同步主 Profile 變更。
缺點：非官方支援；Chrome 內部機制可能偵測實際路徑而非連結目標；並發存取風險（主瀏覽器與自動化同時寫入）；長期穩定性未經大規模驗證。

已失效方案：--disable-features=DevToolsDebuggingRestrictions

早期可搭配預設 Profile 繞過限制，但 Chrome 140 左右版本已修補失效。不建議依賴此旗標。

長期維護建議：自動化同步腳本

若自動化流程需頻繁更新登入狀態（如 Cookie 過期、新增網站授權），建議撰寫定時同步腳本取代手動複製：

#!/bin/bash
# sync-chrome-profile.sh
# 每日同步主 Profile 到自動化目錄

SRC="$HOME/Library/Application Support/Google/Chrome/Default"
DST="$HOME/chrome-automation/Default"

# 確保 Chrome 未運行
pkill -f "Google Chrome" 2>/dev/null
sleep 2

# 同步（排除快取與鎖定檔）
rsync -av --delete \
  --exclude='Cache*' \
  --exclude='Code Cache' \
  --exclude='GPUCache' \
  --exclude='*Lock*' \
  --exclude='*.log' \
  "$SRC/" "$DST/"

echo "[$(date)] Profile 同步完成"

搭配 crontab 或 launchd 定期執行，確保自動化環境始終擁有最新登入狀態。

關鍵提醒

  • Chrome 開發團隊已明確表態：此為刻意安全設計，短期內不會開放預設 Profile 的 CDP 存取
  • 務必完全關閉 Chrome 後再複製或啟動，否則會產生鎖定檔導致 Profile 損毀
  • 指定 --user-data-dir 時指向父目錄（包含 Default 子目錄的那一層），而非 Default 本身
  • 並發風險：主瀏覽器與自動化同時使用同一 Profile（含符號連結）可能導致資料競爭與損毀

結語

Chrome 136+ 的 CDP 限制是永久性安全架構調整。複製 Profile 到專用目錄是目前最務實、穩定且符合官方預期的做法。搭配自動化同步腳本，可在安全性與自動化便利性間取得平衡。