Appearance
搞自动化发布，最烦的不是写脚本，是每次跑脚本都要重新扫码登录。今天把这个问题的彻底解决方案整理出来。
起因：自动化发布，每次都要扫码
在多平台内容自动化发布场景中（公众号→头条号→知乎→小红书），每次启动Chrome浏览器进行自动化操作，都要重新扫码登录——因为Chrome的用户数据存在/tmp目录下，WSL一重启就没了。
这不是小问题。头条号、知乎这些平台，扫码登录的流程走一遍至少2分钟，如果一天要调试10次，光登录就浪费半小时。
问题排查
第一个发现：Chrome用户数据目录存错了
之前的启动脚本：
bash
chrome.exe \
--remote-debugging-port=9222 \
--user-data-dir="/tmp/chrome-opencli" \
--no-sandbox/tmp目录的特性是重启清空。每次WSL重启或Chrome被关闭重开，所有Cookie、登录状态、浏览记录都没了，等于永远在用"全新浏览器"。
第二个发现：WSL2 mirrored网络模式的坑
解决存储问题后，又遇到连接问题。在WSL里用curl验证CDP连接，一直超时：
bash
curl -s --max-time 5 http://localhost:9222/json/version
# 卡住...超时但用PowerShell在Windows端查，端口明明在监听：
powershell
netstat -ano | findstr 9222
# TCP 127.0.0.1:9222 LISTENING 13624原因： WSL2的mirrored网络模式下，Windows进程绑定的127.0.0.1只能从Windows端访问，WSL的localhost不互通。
第三个发现：同时开了两个Chrome实例
系统里同时跑了两个Chrome调试实例：
- 一个用的临时目录
/tmp/chrome-debug-toutiao-20260429（旧的，已失效） - 一个用的持久目录
D:\chrome-profile-toutiao（新的，正确的）
两个实例都监听9222端口，互相冲突。
解决方案
第一步：把用户数据目录放到Windows磁盘
bash
mkdir -p /mnt/d/chrome-profile-toutiao这样Chrome的Cookie、登录状态、扩展数据都保存在Windows磁盘上，WSL重启不丢失，Chrome关闭不丢失。
第二步：修改OpenCLI配置
json
{
"daemon": {
"port": 19826,
"host": "0.0.0.0"
},
"browser": {
"path": "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe",
"type": "chrome",
"args": [
"--remote-debugging-port=9222",
"--no-sandbox",
"--user-data-dir=D:\\chrome-profile-toutiao"
]
}
}关键改动：
path从/usr/bin/chromium-browser改成Windows Chrome路径- 去掉
--headless=new（需要看到浏览器界面进行自动化操作） user-data-dir用Windows路径
第三步：修改启动脚本
bash
#!/bin/bash
CHROME_PATH="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
USER_DATA_DIR="D:\\chrome-profile-toutiao"
# 检查是否已有Chrome在调试模式运行
if curl -s http://localhost:9222/json/version > /dev/null 2>&1; then
echo "✅ Chrome已在调试模式运行"
exit 0
fi
# 启动Chrome（用户数据持久化在D盘）
"$CHROME_PATH" \
--remote-debugging-port=9222 \
--user-data-dir="$USER_DATA_DIR" \
--no-sandbox \
--disable-gpu &第四步：首次登录，永久免扫
用新配置启动Chrome后，只扫一次码登录头条号、知乎等平台。之后无论WSL怎么重启、Chrome怎么关闭重开，登录状态都在。
踩坑记录
| 坑 | 现象 | 原因 | 解决 |
|---|---|---|---|
| WSL2 curl访问Windows localhost超时 | curl一直卡住 | mirrored模式下Windows 127.0.0.1不可见 | 通过PowerShell从Windows端验证 |
| 多个Chrome实例冲突 | 两个进程都监听9222 | 每次用不同user-data-dir启动 | 启动前检查端口，已占用就复用 |
| Hermes browser_navigate不连接现有Chrome | 无法复用已登录会话 | 启动的是Playwright自带Chromium | 通过CDP协议直接操作Windows Chrome |
| CDP WebSocket无法从WSL连接 | 连接超时 | WebSocket URL中localhost不可达 | 用PowerShell的Invoke-WebRequest通过HTTP端点完成 |
效果对比
| 项目 | 修复前 | 修复后 |
|---|---|---|
| 登录状态 | 每次重启丢失 | 永久保持 |
| 扫码次数 | 每次自动化都要扫码 | 只扫一次 |
| 调试效率 | 登录2分钟+操作3分钟 | 直接操作3分钟 |
| 用户数据 | /tmp随时清空 | D:盘持久存储 |
