美洽客服在线但访客看到离线

美洽显示客服在线但访客看到离线，通常由配置或连接不同步造成。常见原因有：坐席未加入会话组、工作时间设置、网页脚本被拦截、长连接掉线、浏览器第三方Cookie限制、前后端状态缓存不一致。排查顺序建议：先看座席端与会话分组，再看前端网络请求，最后检查长连接与代理策略。按步骤定位通常能快速解决多数情况哦！

先把事情说清楚：在线/离线到底指什么

想象一下：美洽的“在线/离线”像小区门口的岗亭。岗亭的人（座席端）告诉物业（服务端）“我在岗”，物业再把这个信息广播到门口显示屏（访客端）。如果任一环节出问题，访客就会看到“没人值班”。说白了，访客端看到的状态取决于三件事：

• 坐席本人在工作台或客服App的状态（是否登陆、是否设为不可见）
• 服务端把坐席状态正确地同步并推送给前端（长连接或轮询是否稳定）
• 前端页面正确接收到并展示了这个状态（脚本没被拦截、配置参数匹配）

常见原因（一步步拆解）

1. 坐席配置与会话分组问题

表现：坐席工作台显示在线，但访客分配的队列或会话分组没有该坐席，访客端显示离线或无可用坐席。

为什么会这样：美洽通常使用“会话组/客服组”做路由。如果坐席未被加入到某渠道对应的组，系统认为该渠道没有可用坐席。

2. 工作时间/自动上下线设置

表现：管理员设定了业务时间、值班表或自动离线策略，导致系统在特定时间段内对访客展示“离线”。

3. 前端脚本未加载或被阻止

表现：网页端根本没有向美洽拉取在线状态（看不到连接建立、没有心跳请求）。常见于广告拦截、严格的内容安全策略（CSP）或脚本被删改。

4. 长连接（WebSocket/Socket）掉线或被中间件关闭

表现：服务端和访客端或服务端和坐席端的长连接频繁重连，或者根本没有建立成功（无101切换）。负载均衡、Nginx、F5或云厂商的健康检查/超时设置可能会中断连接。

5. 浏览器隐私策略与第三方Cookie限制

表现：Safari、Firefox或Chrome在某些隐私模式下阻止第三方Cookie或跨站点跟踪，导致会话或状态识别失败。

6. 多端冲突与会话授权过期

坐席在多个设备上登录或 token 在后台过期，导致状态在不同设备上互相覆盖或不同步。

7. 后端同步/缓存延迟

分布式部署时缓存（Redis、CDN）或数据库复制延迟，会让状态在部分节点仍旧是离线。

8. 渠道特性差异

像微信公众号、微信小程序、APP 嵌入与网页widget使用不同SDK或不同路由，某些渠道的在线判断逻辑不同，结果显示不同。

逐步排查：从简到难（按优先级）

• 步骤一：确认坐席端真实状态
  • 坐席是否登陆？是否设置为“隐身/忙碌/离线”模式？
  • 坐席是否被加入到访客看到的会话组？（产品管理后台检查）
• 步骤二：检查工作时间与自动上下线策略
  • 确认企业设置的“服务时间”是否覆盖当前时间。
  • 确认是否有排班、节假日、自动离线规则。
• 步骤三：浏览器控制台 & 网络抓包
  • 打开访客页面，查看控制台是否报错（脚本 404、CSP、Mixed Content、Blocked cookie）。
  • 网络面板看是否建立了 websocket（状态码 101）或轮询请求返回 presence 信息。
• 步骤四：测试不同环境
  • 换浏览器、关闭广告拦截、使用无痕/隐私模式测试。
  • 在手机网络与公司网络间切换以排除网络或代理问题。
• 步骤五：查看服务端日志与状态推送
  • 在服务端查找 presence 更新日志：是否向相应客户端推送了 online 状态。
  • 检查长连接是否有异常断开、重连的记录。
• 步骤六：运维层面检查
  • 负载均衡或反向代理（Nginx）对 websocket 的超时/心跳设置；检查 keepalive、proxy_read_timeout。
  • 检查 Redis/DB 主从延迟、集群间时间同步（NTP）。

前端工程师常用的具体排查点

• 确认 SDK/Script tag 的 appKey 与页面使用一致：填错 appKey 会导致向错误的项目请求。
• 检查 CSP（Content-Security-Policy）：确保允许加载美洽相关域名的脚本与 websocket 连接。
• 查看浏览器 Network 中的请求：关键项包括：/socket、/presence、xhr 的返回码与 JSON 内容（是否返回在线坐席列表）。
• 第三方 Cookie/SameSite 问题：若使用跨域 iframe 或第三方 Cookie 授权，需确认 SameSite=None 且 Secure。
• 确认页面没有被缓存的旧脚本：清缓存或打开无痕窗口以排除缓存影响。

运维/后端要注意的点

• WebSocket 与负载均衡：很多网关会在空闲一段时间后关闭连接，请设置合适的超时并启用心跳。
• 代理与反向代理配置：nginx 需要 proxy_set_header Upgrade 和 connection upgrade；并调整 proxy_read_timeout、proxy_send_timeout。
• 状态同步与缓存策略：使用 Redis 等做在线状态缓存时，确保过期时间合理且主从延迟小。
• 监控：对长连接数量、心跳失败率、重连次数设置告警。

常见问题与快速修复清单（方便截图发工单）

一些现场能立刻试的操作（小技巧）

• 让坐席退出登录再重新登录，看访客端是否马上变在线（可判断是否为坐席端状态未触发推送）。
• 在访客页面打开 DevTools → Network → Filter websocket，观察 frames 是否有 presence、agent_list 等消息。
• 临时关闭广告拦截、隐私扩展或在无痕模式下访问，排除扩展干扰。
• 用 curl 或 Postman 请求相关 API，查看返回的在线坐席数据是否正确（便于判断是前端接收问题还是服务端响应问题）。

让体验更稳的实践建议（长期）

• 完善监控：长连接数量、心跳失败率、在线人数波动等都要纳入监控与报警。
• 容错机制：如果推送暂时不可用，前端应有轮询备份机制，或显示“正在尝试连接”的合理提示。
• 清晰的访客提示：在无法确认实时在线状态时，用“暂时无人在线，您可以留言”这种文字替代直接“离线”，体验更友好。
• 定期演练：在低峰期做断连、重连、切换路由等演练，验证系统在各种异常下的表现。

写完这些步骤我突然想到一个细节：很多团队在遇到“在线/离线”问题时第一反应就是找产品或平台，结果往往是某个小配置或网络超时导致。按着上面的顺序一步步来，绝大多数情况都能在短时间内定位。要是实在定位不了，那把关键截图（坐席端状态、访客端控制台网络面板、服务端推送日志）一并发给美洽支持或运维，能大幅缩短诊断时间。希望这些方法对你有用，我这边还记得当初排查过类似问题，用的是“先看坐席组，再看 websocket，再看浏览器拦截”的套路，基本都是它救了场面。