使用 Neko 搭建 ChatGPT 拼车共享浏览器

作者：蓝逸 日期：2026-07-20 浏览：1321℃ 分类：分享

之前开了 GPT Pro 共享车，需要把已经登录的 Web 端共享给车友。直接提供账密码或者分发浏览器资料（比如指纹浏览器），账号凭证和登录状态都不容易控制。

后来我改成用 Neko 共享一台已经登录 ChatGPT 的 Chromium 。车友只进入 Neko 房间，不直接接触账号密码；房间口令、控制权和浏览器可访问的网站可以分别限制。下面记录完整的手动部署过程。

网络结构 先总览一下网络拓扑，帮助大家理解 Neko + 共享浏览器的网络链路：

Neko 站点的 HTTPS 、登录接口和 WebSocket 经过 443 ，再由 Nginx 转发到 Neko 的 8080 。

Neko 页面中浏览器画面和音频通过 WebRTC 传输，本文开放 UDP 52000–52100 ，并保留 TCP 52101 作为回退。

ChatGPT 账号网络：Chromium 访问网站时使用容器自己的出站网络。给浏览器增加代理，不会替代 WebRTC 的入站端口。

域名页面能打开，只能证明 443 和 8080 正常，不能证明 WebRTC 已经连通。Neko WebRTC 文档 也明确要求媒体端口直接可达，或者通过 TURN 中继。（部署时就踩了这个坑） Docker Compose 部署 准备一台带公网 IP 的 VPS 、一个已解析到该 IP 的域名，以及 Docker Engine 和 Compose 插件。新建目录后写入 compose.yaml： services: neko: image: ghcr.io/m1k1o/neko/chromium:latest container_name: neko restart: unless-stopped shm_size: "2gb" ports:

  • "127.0.0.1:8080:8080"
  • "52000-52100:52000-52100/udp"
  • "52101:52101/tcp" environment: NEKO_MEMBER_PROVIDER: "multiuser" NEKO_MEMBER_MULTIUSER_USER_PASSWORD: "${NEKO_USER_PASSWORD:?required}" NEKO_MEMBER_MULTIUSER_ADMIN_PASSWORD: "${NEKO_ADMIN_PASSWORD:?required}"
  NEKO_SERVER_BIND: "0.0.0.0:8080"
  NEKO_SERVER_PROXY: "true"
  NEKO_DESKTOP_SCREEN: "1920x1080@30"

  NEKO_SESSION_IMPLICIT_HOSTING: "false"
  NEKO_SESSION_CONTROL_PROTECTION: "true"
  NEKO_FILETRANSFER_ENABLED: "false"
  NEKO_DESKTOP_UPLOAD_DROP: "false"

  NEKO_WEBRTC_EPR: "52000-52100"
  NEKO_WEBRTC_NAT1TO1: "${NEKO_PUBLIC_IP:?required}"
  NEKO_WEBRTC_ICELITE: "true"
  NEKO_WEBRTC_TCPMUX: "52101"

同目录创建 .env： NEKO_PUBLIC_IP=203.0.113.10 NEKO_USER_PASSWORD=replace-with-a-long-random-value NEKO_ADMIN_PASSWORD=replace-with-another-long-random-value

普通用户和管理员使用不同口令。当前配置关闭了点击画面自动取得控制权，并要求管理员在房间内时普通用户才能取得控制权；如果需要无人值守的远程控制，应按使用场景调整这两个选项。 把 .env 权限收紧，并在启动前检查 Compose 展开结果： chmod 600 .env docker compose config --quiet docker compose up -d docker compose ps curl -fsS http://127.0.0.1:8080/health

NEKO_SERVER_BIND=0.0.0.0:8080 让 Docker 能访问容器内服务；宿主机的端口映射仍限定在 127.0.0.1，外部访问只能经过反向代理。NEKO_SERVER_PROXY=true 用于信任反向代理传入的客户端地址头，不能在 Neko 直接暴露公网时开启。完整变量说明可在官方配置页核对。 官方示例使用 latest。完成测试后可以固定到验证过的镜像版本或摘要，避免重新拉取镜像时引入未验证变更。 反向代理和防火墙 Nginx 配置需要保留 WebSocket Upgrade 头： server { listen 443 ssl http2; server_name neko.example.com;

ssl_certificate     /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

}

修改后执行 nginx -t，确认无误再 reload 。Neko 会定期发送 WebSocket 心跳，代理超时时间不能短于会话心跳周期。官方反向代理示例给出了相同的 Upgrade 配置。 需要开放的端口如下：

端口 协议 用途

443 TCP HTTPS 、登录接口和 WebSocket

80 TCP 可选；用于 ACME HTTP-01 签发或跳转 HTTPS

52000–52100 UDP WebRTC 媒体端口，必须与 NEKO_WEBRTC_EPR 完全一致

52101 TCP 可选的 WebRTC TCP mux 回退

不要把 8080 开放到公网。云防火墙和系统防火墙都要检查；只配置其中一层仍可能导致媒体连接超时。 关键配置 1.持久化 Chromium 资料 默认情况下，重建容器会丢失 Chromium 的 Cookie 、扩展和设置，为了避免每次重启容器需要重新登录 chatgpt 账号。需要保留资料时增加卷挂载： volumes:

  • ./chromium-data:/home/neko/.config/chromium

挂载后先检查目录属主。浏览器无法启动、只有黑屏时，可以在容器内确认目录是否属于 neko 用户： docker exec -it neko ls -la /home/neko/.config/chromium docker exec -it neko chown -R neko:neko /home/neko/.config/chromium

持久化目录会同时保存网站登录态。允许多人进入同一个房间时，应把整个 profile 视为共享数据，并单独决定备份和销毁方式。 把 WebRTC 收敛到单端口 如果不想开放一段 UDP 端口，可以改用 UDP/TCP mux 。删除 NEKO_WEBRTC_EPR 及其端口映射，改成： ports:

  • "127.0.0.1:8080:8080"
  • "52000:52000/udp"
  • "52000:52000/tcp" environment: NEKO_WEBRTC_UDPMUX: "52000" NEKO_WEBRTC_TCPMUX: "52000"

UDP 延迟通常更低，TCP 适合作为受限网络中的回退。端口不能在 Docker 层改映射，例如不能把宿主机 52000 转到容器 59000 。 2.单独设计浏览器出站

为了降低 WebRTC 延迟，可以把 Neko 部署在离用户较近的服务器；如果服务器无法直接访问 ChatGPT ，再单独为 Chromium 配置出站代理。

Neko v3 没有用于设置 Chromium 代理的环境变量。当前 Chromium 镜像会读取 /etc/chromium/policies/managed/ 下的浏览器策略，因此可以新建 chromium-proxy.json：

{ "ProxySettings": { "ProxyMode": "fixed_servers", "ProxyServer": "socks5://proxy.example.com:1080", "ProxyBypassList": "localhost,127.0.0.1" } }

HTTP 代理可以把 ProxyServer 改成 http://proxy.example.com:3128。先检查 JSON ，再把文件挂载到 Chromium 的 managed policy 目录： jq empty chromium-proxy.json

volumes:
  - ./chromium-proxy.json:/etc/chromium/policies/managed/20-proxy.json:ro

如果前面已经配置了 Chromium 资料持久化，把两个挂载项放在同一个 volumes 列表中。重新创建容器使策略生效： docker compose up -d --force-recreate

先从容器测试代理是否可达。下面以 SOCKS5 为例，HTTP 代理将参数改为 --proxy http://proxy.example.com:3128： docker exec neko curl -fsS --proxy socks5h://proxy.example.com:1080 https://api.ipify.org

最后在 Neko 的 Chromium 中打开 https://api.ipify.org。浏览器显示代理出口 IP ，说明 ProxySettings 已经生效；

docker exec neko curl -fsS https://api.ipify.org 仍会显示服务器自己的出口 IP ，因为这份策略只作用于 Chromium ，不会改变 Neko 容器的出口 IP 。

示例没有加入 direct:// 回退：代理断开时 Chromium 会直接报错，不会改用服务器出口。Chromium 也不会读取写在代理 URL 中的用户名和密码；需要认证时，优先让上游代理按服务器 IP 放行，或者增加一个只在 Docker 网络内监听的本地转发代理。

HTTP/SOCKS5 只能代理 Chromium 的 HTTP 、HTTPS 和 WebSocket 请求，但不能转发 UDP 。如果需要让语音等 UDP 流量走代理，应改用 VPN 或网关容器；使用 network_mode: service: 后，Neko 的 8080 和 WebRTC 端口也要改由网关容器发布。Chromium 代理文档列出了代理协议、WebSocket 选择顺序和认证限制。

3.限制用户使用共享浏览器的访问地址 Neko 的 Chromium 镜像已经内置了一份浏览器策略，其中包括禁用开发者工具、下载和访客模式等限制。为了保留这些默认项，先从正在运行的容器复制策略文件，只修改其中的 URLBlocklist 和 URLAllowlist： docker cp neko:/etc/chromium/policies/managed/policies.json ./chromium-policies.json

用 jq 只替换这两个字段，输出一份新的策略文件： jq ' .URLBlocklist = ["", "file://"] | .URLAllowlist = [ "chatgpt.com", "chat.openai.com", ".auth.openai.com", ".auth0.openai.com", ".setup.auth.openai.com", "oaistatic.com", "oaiusercontent.com", "oaistatsig.com", ".cdn.openaimerge.com", ".challenges.cloudflare.com", ".cdn.workos.com", ".forwarder.workos.com", ".setup.workos.com", ".images.workoscdn.com", ".workos.imgix.net", "chrome://policy" ] ' chromium-policies.json > chromium-policies-restricted.json

Chromium 的策略语法中，chatgpt.com 会同时匹配它的子域名；以点开头的 .auth.openai.com 只匹配这个主机名。上面的列表用于 ChatGPT Web 、登录、静态资源和文件访问，域名取自 OpenAI 当前的网络配置建议。语音、付款或第三方登录需要使用时，再从官方列表加入对应域名。 先检查 JSON 格式，然后把文件挂载回原路径： jq empty chromium-policies-restricted.json

volumes:
  - ./chromium-data:/home/neko/.config/chromium
  - ./chromium-policies-restricted.json:/etc/chromium/policies/managed/policies.json:ro

如果不需要持久化 Chromium 资料，删除第一行卷挂载即可。重新创建容器后，在 Chromium 中打开 chrome://policy，点击 Reload policies （重新加载策略），确认 URLBlocklist 和 URLAllowlist 的状态为 OK： docker compose up -d --force-recreate

最后分别打开 https://chatgpt.com 和一个未放行的网站，确认前者可用、后者显示被管理员阻止。验证完成后可以从白名单中删除 chrome://policy，再重新创建容器。 URLBlocklist 限制的是 Chromium 中的地址访问，不是容器级防火墙；chatgpt.com 内部的会话、设置等功能也仍在放行范围内。需要限制容器内其他进程的出站连接时，还要在出口代理或防火墙上单独配置白名单。 排障

现象 检查 处理

域名无法打开 curl http://127.0.0.1:8080/health 、Nginx 错误日志 先确认容器健康，再检查反代目标、证书和 443

登录页正常，画面超时 EPR 、Docker UDP 映射、两层防火墙、nat_ips 日志 让端口范围和协议完全一致；修正 NEKO_WEBRTC_NAT1TO1

有光标但 Chromium 黑屏 shm_size 、profile 路径和属主 保持至少 2 GB /dev/shm ；修复或暂时移除持久化目录

外网正常，内网无法连接 路由器是否支持 NAT loopback 使用公网地址回环、VPN 或 TURN

Chromium 没有网络 先访问 https://1.1.1.1 ，再检查 DNS 和 Docker 网段 能访问 IP 但不能访问域名时修 DNS ；同时排除 Docker 子网冲突

服务端可以先看 Neko 识别到的公网地址： docker compose logs neko | grep nat_ips

客户端使用 Chromium 时打开 chrome://webrtc-internals。如果 candidate 中只有不可达的内网地址，继续检查 NAT1TO1 、端口映射或 TURN ，不必反复修改 Nginx 。Neko Troubleshooting 也采用这个排查顺序。

博客原文

内容版权声明：除非注明，否则皆为本站原创文章。

转载注明出处：http://dixi.eu.org/33643.html

上一篇 最近在玩 Task Bar Hero ，一个偏放置养成的 RPG 。
下一篇 经典：上涨时是认知胜利，回撤时是命运喜剧，被质疑时是舆论战争，深套时又变成自我修行。