问题源于WebSocket连接中断或未维持长连接，需依次排查：一、验证连接是否建立成功；二、检查反向代理配置；三、检测客户端网络阻断；四、确认前端WS地址正确；五、审查后端服务健康状态。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您已成功安装WorkBuddy但实时通知未触发，问题很可能源于客户端与服务器之间的WebSocket连接中断或未能维持长连接。以下是排查WebSocket连接稳定性的具体操作步骤：
一、验证WebSocket连接是否建立成功
WebSocket连接需在页面加载后主动发起并完成握手，若初始连接失败，则后续所有实时通知将无法投递。需确认浏览器控制台是否存在连接拒绝、状态码400/401/502等错误提示。
1、打开WorkBuddy所在网页，按F12调出开发者工具。
2、切换至Network（网络）标签页，刷新页面。
3、在筛选栏输入ws或wss，查看是否有协议为ws://或wss://的请求条目。
4、点击该请求，检查Headers面板中Status Code是否为101 Switching Protocols，Response为空且无报错。
二、检查反向代理层对WebSocket的支持配置
Nginx、Apache或云服务商负载均衡器若未显式启用WebSocket支持，会主动关闭Upgrade头或复用HTTP连接，导致连接在60秒内被强制断开。
1、登录Nginx服务器，打开对应站点的配置文件（如/etc/nginx/conf.d/workbuddy.conf）。
2、确认server块内location /ws/（或实际WebSocket路径）下包含以下三行指令：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
3、执行nginx -t验证语法，再运行systemctl reload nginx重载配置。
启用该技能，可以在WorkBuddy对话页的右边栏添加一个日历，提供月历视图、日程增删改查、分类标签（开庭/会议/截止日期/个人/研究/其他），支持从对话中提取事件并自动同步到日历。当用户提到"日历""日程""打开日历""添加日程""我的日程""calendar""安排"或询问已记录的日程信息时使用。
三、检测客户端网络环境是否阻断WebSocket
企业防火墙、校园网出口设备或部分运营商NAT网关会静默丢弃非标准HTTP流量，尤其针对长时间空闲的WebSocket连接，表现为onclose事件无code或reason。
1、在相同网络下使用Chrome访问https://websocketstest.com/进行连通性测试。
2、观察结果页中Connection Test是否显示Success，同时Ping/Pong Latency有稳定响应。
3、若失败，尝试切换至移动热点网络重试；若成功，则当前局域网存在中间设备干预。
四、确认WorkBuddy前端初始化时正确传入WebSocket地址
前端JavaScript必须使用与后端部署协议、域名、端口完全一致的URL实例化WebSocket对象，任意一项不匹配均会导致连接被浏览器拦截或CORS拒绝。
1、在开发者工具Console中执行：console.log(window.WORKBUDDY_WS_URL)，核对输出值是否以wss://或ws://开头且域名与当前页面同源（或已配CORS）。
2、若输出为undefined或http://地址，说明环境变量未注入，需检查构建时.env文件中VUE_APP_WS_URL或REACT_APP_WS_URL字段是否填写正确。
3、修改后重新构建前端并部署静态资源，确保HTML中script标签加载的JS文件含最新地址常量。
五、审查后端WebSocket服务进程健康状态
Node.js、Python或Java实现的WebSocket服务若崩溃、内存溢出或未监听指定端口，客户端将始终处于connecting状态直至超时。
1、登录WorkBuddy后端服务器，执行netstat -tuln | grep :8080（替换为实际WS端口），确认存在LISTEN状态条目。
2、运行systemctl status workbuddy-ws（或对应服务名），检查Active状态是否为active (running)且无Recent crash日志。
3、查看服务日志：执行journalctl -u workbuddy-ws -n 50 --no-pager，搜索关键词upgrade、handshake、EADDRINUSE。
