[Bug]: 无法连接websock

[Wrxsidox-88]

错误描述

在云服务器上尝试构建时，在构建成功后，访问提示websock连接断开，无论是普通版本还是精简版本 都出现了同样的问题。我使用了阿里云服务器

重现步骤

1. 按照步骤克隆代码
2. 使用命令构建精简版镜像
3. 运行docker-compose up -d启动构建并构建完成
4. 访问HTTPS端口即可复现

预期行为

能正常使用

截图

操作系统

Ubuntu 20.04

浏览器

Chrome

Docker版本

28.1.1

Docker Compose版本

2.35.1

相关日志

> Warning:          Could not resolve keysym XF86FishingChart
> Warning:          Could not resolve keysym XF86SingleRangeRadar
> Warning:          Could not resolve keysym XF86DualRangeRadar
> Warning:          Could not resolve keysym XF86RadarOverlay
> Warning:          Could not resolve keysym XF86TraditionalSonar
> Warning:          Could not resolve keysym XF86ClearvuSonar
> Warning:          Could not resolve keysym XF86SidevuSonar
> Warning:          Could not resolve keysym XF86NavInfo
Errors from xkbcomp are not fatal to the X server
xsettingsd: Created window 0x200001 on screen 0 with timestamp 103507636
xsettingsd: Selection _XSETTINGS_S0 is owned by 0x0
xsettingsd: Took ownership of selection _XSETTINGS_S0

附加信息

我在尝试直接使用域名访问和浏览器IP地址访问均是同样的问题，构建均通过宝塔面板完成

检查清单

• 我已经搜索了现有的issues，确认这不是重复问题
• 我已经阅读了README和相关文档
• 我提供的信息足够详细，可以帮助重现问题

[nickrunning]

根据当前描述与日志信息判断，该问题更可能发生在浏览器与容器之间的 WebSocket/反向代理链路，而不是镜像构建阶段。

当前提供的日志主要为 xkbcomp 按键告警及 xsettingsd 启动信息，这类输出通常不会导致 Selkies 服务无法启动，说明容器内桌面环境大概率已经完成初始化。浏览器侧出现 websock 断开时，常见原因通常包括以下几类：

1. 阿里云安全组或服务器本机防火墙未实际放通 3001/tcp
2. 宝塔面板的反向代理未正确启用 WebSocket Upgrade
3. 通过域名访问时，链路中存在额外代理/CDN/WAF，导致 WebSocket 握手或长连接被中断
4. 访问路径中叠加了额外 HTTPS 反代，但相关反代配置不完整

建议优先按照以下顺序排查：

1. 先绕过宝塔和域名，直接验证容器端口

请先直接访问：

https://<服务器IP>:3001

建议先不要经过域名，也不要经过宝塔反代。

如果直接访问 IP:3001 可以正常打开，而通过域名访问失败，则基本可以确认问题位于宝塔或上层反向代理配置，而非本项目镜像本身。

2. 确认端口已实际放通

请同时检查阿里云安全组与服务器本机防火墙，确认 3001/tcp 已开放。

可在服务器侧执行以下命令进行确认：

docker ps
docker compose logs -f wechat-selkies
ss -lntp | grep 3001

3. 如使用宝塔反代，请确认已正确支持 WebSocket

Selkies 依赖 WebSocket 长连接。若通过宝塔/Nginx 做反向代理，建议确认至少包含以下配置：

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-Forwarded-Proto $scheme;
proxy_read_timeout 86400;
proxy_send_timeout 86400;

若宝塔面板中存在“WebSocket 支持”选项，也需要一并启用。

4. 反代链路建议先保持最简

本项目默认对外端口如下：

• 3000：HTTP
• 3001：HTTPS

如需使用反向代理，建议先使用最简单的一层代理配置完成验证，避免同时叠加多层转发、证书代理或 CDN 规则，以便准确定位问题。

5. 关于端口暴露的补充说明

上游 linuxserver/baseimage-selkies 内部确实会使用 WebSocket 相关服务，但对外通常由容器内 Nginx 统一转发。因此在默认部署方式下，通常仅映射 3000/3001 即可，无需额外手工暴露其他端口。

为便于进一步确认问题范围，建议补充以下信息：

1. 当前实际访问方式是 https://服务器IP:3001，还是 https://域名
2. 宝塔中是否启用了反向代理；若已启用，反代目标为 3000 还是 3001
3. 浏览器开发者工具（F12）中失败的 WebSocket 请求状态码，例如 101、400、403、404、502
4. 以下命令的完整输出：

docker ps
docker compose logs --tail=200 wechat-selkies

补充上述信息后，将更容易确认问题位于端口放通、宝塔反向代理配置，还是 HTTPS 访问链路本身。

[topmoxiaoxiao]

虚拟机安装后，http和https都无法打开

[nickrunning]

补充说明：最新评论中提到“HTTP 和 HTTPS 都无法打开”，这与最初的“页面可访问但 WebSocket 断开”并不完全属于同一层级的问题，需要先区分。

• 若浏览器能够打开登录页或桌面页面，但随后提示 websock 断开，这通常属于 WebSocket/反向代理链路问题。
• 若 http://<IP>:3000 与 https://<IP>:3001 均完全无法访问，则应优先排查 容器是否正常启动、端口是否监听、端口映射是否生效、防火墙或安全组是否放通。

对于“HTTP 和 HTTPS 都无法打开”的情况，建议先执行以下检查：

docker ps
docker compose logs --tail=200 wechat-selkies
ss -lntp | grep -E '3000|3001'

请重点确认以下几点：

1. 容器状态是否为 Up
2. docker ps 中是否存在端口映射 0.0.0.0:3000->3000/tcp 与 0.0.0.0:3001->3001/tcp
3. 阿里云安全组或虚拟机所在环境是否已放通 3000/tcp、3001/tcp
4. 服务器本机防火墙（如 ufw、firewalld）是否拦截了对应端口
5. 若通过宝塔启动或管理容器，宝塔是否实际使用了仓库中的 docker-compose.yml，以及是否存在端口冲突或重复代理

若当前环境为虚拟机，还需要额外确认网络模式：

• 若使用 NAT 网络，宿主机端口是否已正确转发到虚拟机
• 若使用桥接网络，虚拟机 IP 是否可被当前访问端直接连通

如果 3000 和 3001 都无法直接访问，建议暂时不要先排查 WebSocket，而是先确认基础访问链路已经打通。

为便于进一步判断，建议补充以下信息：

docker ps
docker compose logs --tail=200 wechat-selkies
cat docker-compose.yml

以及说明当前访问方式：

• 直接访问 http://服务器IP:3000 / https://服务器IP:3001
• 还是通过域名、宝塔反向代理、虚拟机端口转发后访问

在基础端口可访问之前，后续的 WebSocket 排查结论通常没有参考意义。

[luxu045]

你的第一个问题跟我一样，我把日志发AI给了解决办法，我已经解决了
这份日志直接把“真凶”揪出来了，问题根本不在端口，也不在 HTTPS 配置，而是群晖的文件夹权限卡住了程序的启动。

仔细看日志里的这两行报错：

• mkdir: cannot create directory '/config/Desktop': Permission denied
• Failed to create /config/.cache for shader cache (Permission denied)

这说明容器里的程序（微信 Selkies）试图在 /config 目录下写数据，但被拒绝了。因为无法创建必要的缓存和文件，导致内部的服务（包括 WebSocket 服务）根本没起来，所以你才会看到“连接断开”。

这通常是因为你之前用不同的 PUID/PGID（比如 1000/100）启动过容器，导致 ./config 文件夹被“锁”在了旧的权限上。

解决方案：重置文件夹权限

请在群晖的 SSH 终端（以 root 身份）执行以下操作，只需两步即可修复：

1. 停止并删除旧容器

先把当前的烂摊子停掉：

docker-compose down

2. 强制修改 config 文件夹权限

我们需要把 ./config 文件夹的所有权彻底交给容器里指定的用户（根据你刚才的代码，是 1000 和 1001）。

请在终端执行（注意替换 ./config 为你的实际路径，如果就在当前目录直接用 . 即可）：

递归修改当前目录下 config 文件夹的权限
chown -R 1000:1001 ./config

赋予最高读写权限（防止其他干扰）
chmod -R 777 ./config

3. 重新启动

权限修复后，再次启动容器：

docker-compose up -d

验证方法

再次查看日志：

docker logs wechat-selkies

如果看到日志里不再出现 Permission denied，而是出现了 Listening on port... 或者类似 Server started 的字样，就说明成功了。

[topmoxiaoxiao]

非常感谢您的来搞,邮件已收到.