# CDP 连接用户已有 Chrome

## 场景

用户已经在 Chrome 中登录了招聘平台，Hermes 需要复用这个登录态来操作浏览器。

## Chrome 148 注意事项

Chrome 148+ 要求 `--user-data-dir` 必须与已有 Chrome 实例**路径不同**，否则调试端口不生效。解决方案是 bind mount：

```bash
# ~/.config/google-chrome → ~/.config/chrome-debug（fstab 已配置，重启自动挂载）
ls -la ~/.config/chrome-debug  # 应该看到和 google-chrome 一样的内容
```

## 日常启动

```bash
# 一键启动（自动处理 bind mount、kill 旧进程、等待 CDP 就绪）
bash /home/kt/scripts/chrome/chrome-launch.sh
# 输出 READY 表示成功
```

手动启动（脚本不可用时）：
```bash
killall -9 chrome chrome_crashpad_handler 2>/dev/null; sleep 2
export DISPLAY=:0 XDG_RUNTIME_DIR=/run/user/1000
google-chrome-stable --remote-debugging-port=9222 --remote-allow-origins='*' \
  --no-first-run --no-default-browser-check \
  --user-data-dir=$HOME/.config/chrome-debug &
sleep 5; curl -s --max-time 3 http://localhost:9222/json/version
```

> **环境变量必须设置**：Hermes 后台执行不继承桌面 session，不设置 `DISPLAY` 会报错。

## 验证连接

```bash
curl -s http://localhost:9222/json/version
# 应返回 JSON，含 webSocketDebuggerUrl (ws://...)
```

## Node.js 连接模板

```javascript
const { chromium } = require('playwright-core');

// CDP_PORT 支持端口转发场景（默认9222，Windows远程为9223）
const port = process.env.CDP_PORT || 9222;
const res = await fetch(`http://localhost:${port}/json/version`);
const info = await res.json();
// 必须用 ws:// URL，chromium.connectOverCDP('http://...') 会返回 400
const browser = await chromium.connectOverCDP(info.webSocketDebuggerUrl);
const ctx = browser.contexts()[0];
// 找到已打开的页面（复用登录态）
let page = ctx.pages().find(p => p.url().includes('zhaopin.com'));
```

> playwright-core 模块路径：`/home/kt/scripts/chatgpt/node_modules/playwright-core`
> 后台进程需要绝对路径，相对 require 会找不到。
>
> **Windows 远程场景**：通过 SSH 端口转发连接，`CDP_PORT=9223 ssh -N -L 9223:127.0.0.1:9222 sshadmin@192.168.50.99`。详见 `references/windows-remote-scraping.md`。

## 常见问题

### 调试端口不生效
- Chrome 已有实例在跑 → 先 killall 再启动
- `--user-data-dir` 与运行中的 Chrome 相同 → 用 bind mount 方案

### 登录态丢失
- bind mount 断了 → 重新 mount：`sudo mount --bind ~/.config/google-chrome ~/.config/chrome-debug`
- 用了完全不同的 profile 目录 → 确认使用 `~/.config/chrome-debug`

### SSH 隧道建立后 curl 立即失败（正常现象）

现象：`ssh -fN -L 9223:127.0.0.1:9222 ...` 成功后，`curl 127.0.0.1:9223` 立即返回 `exit code 7`（连接被拒绝），但 `ss -tlnp | grep 9223` 显示端口在监听。

原因：SSH tunnel 建立后需要几秒才能稳定转发。等 2-3 秒再 curl 即可。

另外，`ssh -fN` 可能输出 `bind [::1]:9223: Cannot assign requested address` 警告——这是无害的，tunnel 仍绑定在 IPv4 `127.0.0.1` 上正常工作。**不要因为这个警告杀掉 tunnel 重建**。

**验证步骤：**
```bash
# 1. 检查进程在跑
ps aux | grep 'ssh.*9223' | grep -v grep
# 2. 检查端口监听（应该有 127.0.0.1:9223）
ss -tlnp | grep 9223
# 3. 等 2-3 秒后验证 CDP
curl -s --connect-timeout 3 http://127.0.0.1:9223/json/version
# 4. 如果仍不通，检查远端 Chrome
ssh sshadmin@192.168.50.99 "curl -s http://127.0.0.1:9222/json/version"
```

### Hermes 网关重启后 tunnel 断裂

网关重启后 SSH tunnel 进程会被杀掉。重建时可能遇到端口残留问题：

```bash
# 杀掉残留占用端口的进程
fuser -k 9223/tcp
sleep 1
# 重建 tunnel（忽略 bind [::1] 警告）
ssh -o ConnectTimeout=5 -fN -L 9223:127.0.0.1:9222 sshadmin@192.168.50.99
# 验证
curl -s --connect-timeout 3 http://127.0.0.1:9223/json/version
```

**注意：** `pkill -f 'ssh.*9223'` 有时杀不干净（信号 15 被忽略），用 `fuser -k 9223/tcp` 更可靠。如果重建后 `ss` 显示端口在监听但 curl 返回 exit 7，等几秒再试（tunnel 稳定需要时间）。

### 后台进程无输出
- 后台 shell 无 tty → `sleep` 和 `node` 仍可运行，但 `set -m` 等会失败，忽略即可
- 确保设置 `DISPLAY=:0 XDG_RUNTIME_DIR=/run/user/1000`
- **Hermes 后台终端 pipe 缓冲**：`setBlocking(true)` 对 Hermes 后台 pipe 无效，所有 `console.log` 在进程退出前看不到。脚本已内置文件日志（`/home/kt/.hermes/data/recruitment/logs/scrape-*.log`），监控用：`ls -t .../logs/scrape-*.log | head -1 | xargs tail -20`