[Bug] websocket端口的相关设置无效，以及发现了一些github请求

[dxkrs]

Pre-check / 提交前确认

• I have searched existing issues and did not find a duplicate. / 我已搜索现有 issue，确认不是重复问题。
• I have read README deployment and FAQ sections. / 我已阅读 README 的部署与 FAQ 部分。

Install Method / 部署方式

Docker Compose

Version / 版本

oru17/neko-master:1.3.5

Environment / 运行环境

我是使用docker-compose.yaml部署的，部署在家庭里的NAS服务器，192.168.1.112是我的NAS局域网地址。

Steps to Reproduce / 复现步骤

问题概述

感觉WS_EXTERNAL_PORT与NEXT_PUBLIC_WS_PORT设置，在docker直连（反向代理未试过）的情况下看似无效。最终误打误撞地发现设置完整的NEXT_PUBLIC_WS_URL才生效。

问题描述

我是使用docker-compose.yaml部署，里面的环境变量设置了这些值：

- NODE_ENV=production
- WEB_EXTERNAL_PORT=1604
- WS_EXTERNAL_PORT=1605
- NEXT_PUBLIC_WS_PORT=1605

端口映射是192.168.1.112:1604:3000和192.168.1.112:1605:3002，192.168.1.112是我的nas局域网地址。

Expected Behavior / 预期行为

按照我对README介绍的理解，此时我通过1604端口访问web页面，页面应该会尝试发起1605端口的websocket连接。

Actual Behavior / 实际行为

但我在浏览器里看到的是它发起了1604端口的websocket连接！因此它永远都无法建立websocket连接并且始终回退到HTTP轮询。

后来我尝试配置- NEXT_PUBLIC_WS_URL=http://192.168.1.112:1605，才看见web页面去尝试发起1605端口的websocket连接，并成功连接且不会退回到HTTP轮询。

Logs and Screenshots / 日志与截图

Additional Context / 补充信息

那么WS_EXTERNAL_PORT和NEXT_PUBLIC_WS_PORT这两个设置值，至少在这个使用场景下，是否无效？或者是README的相关介绍不太准确？
其实我也不太明白为什么要设置WS_EXTERNAL_PORT和NEXT_PUBLIC_WS_PORT这两个设置值，感觉应该是可以合并。我甚至尝试另外设置WEB_EXTERNAL_PORT是非1604的值，docker映射端口不改变，也不妨碍我通过1604端口访问web页面，也就是说WEB_EXTERNAL_PORT这个值也是无意义的？

稍微进一步分析

我尝试让我的claw稍微分析了一下项目，它指出了/apps/web/lib/websocket.ts文件的149行中，可能是runtime?.WS_PORT没有设置好，导致hostForPort获取了浏览器上的host。

另外的一些小疑问

• 在web页面已成功建立websocket连接的情况下，我观察浏览器的请求，发现依然反复去访问http://192.168.1.112:1604/api/backends这个地址，即使我在页面上无任何操作。这是正常？
• 同样的，我继续观察浏览器的websocket连接情况，我发现只有我在页面上做任何点击的操作，都会新建websocket连接来获取数据，这是把websocket当作http使用了？
• 即使我的是本地部署了这个项目，但在为什么我的使用web页面过程中还是看到项目向github发起了请求？目前我抓到了这些请求：
  • https://api.github.com/repos/foru17/neko-master
  • https://raw.githubusercontent.com/foru17/neko-master/refs/heads/main/package.json

[foru17]

Good report, and thanks for the detailed analysis — you basically nailed the root cause.

What was happening:

In production mode, the WebSocket candidate list put /_cm_ws first (using window.location.host, i.e. your Web port 1604). Since Next.js has no WebSocket proxy for that path, the connection failed silently and fell back to HTTP polling before the direct-port URL (:1605) was ever tried. So WS_EXTERNAL_PORT and NEXT_PUBLIC_WS_PORT appeared to do nothing.

One more thing worth clarifying: NEXT_PUBLIC_WS_PORT is a build-time variable — it gets baked into the JS bundle at image build time. Setting it in docker-compose.yml at runtime has no effect on a pre-built image. The correct runtime variable is WS_EXTERNAL_PORT, which gets written into runtime-config.js by the startup script.

Fix:

When runtime-config.WS_PORT is present (i.e. WS_EXTERNAL_PORT is set), the direct ws://host:port URL is now preferred over /_cm_ws. This means your original config should work correctly without needing NEXT_PUBLIC_WS_URL as a workaround.

Fixed in v1.3.6. The README has also been updated to clarify the NEXT_PUBLIC_WS_PORT build-time limitation.

As for your other questions:

• /api/backends polling every 5s is intentional — it tracks backend health status in real time.
• Multiple WebSocket instances per page click is by design — each data panel manages its own connection independently.
• The GitHub requests are from the version check feature (checks for updates every 30 minutes). Totally understand if that's unexpected behavior for a self-hosted tool — worth considering an opt-out in the future.