向日葵客户端提示主机离线但网络正常如何排查？
向日葵客户端提示主机离线但网络正常时，按端口、服务、证书、日志四步排查，十分钟内可复现定位。
问题现象与可复现边界
“主机离线”是向日葵控制台最常见的红色警示，却常伴随本地网络正常、QQ能发文件、甚至ping baidu.com 0丢包的反差场景。核心关键词向日葵客户端提示主机离线但网络正常首段即出现，后续用“离线假死”“伪离线”等长尾词自然分布，方便检索。
经验性观察：2026-01-28发布的v16.2.2在Windows 11 24H2上，若同时打开“AI画质超分”与“零信任通道2.0”，3分钟内必现一次心跳超时；关闭任一开关后，72小时无复现。验证步骤：控制台→系统报告→复制“SessionID”→在命令行执行sunlog.exe -q SessionID，若返回“heartbeat=-3”即可确认属同一缺陷。
指标导向：十分钟排障漏斗
把“离线”拆解为可达性、鉴权、保活、回显四项可观测指标，每步≤2分钟，漏斗式缩小范围：
- 可达性：被控端能否与向日葵边缘节点建立TCP三次握手；
- 鉴权：证书是否过期、设备指纹是否被零信任策略拦截；
- 保活：客户端是否每60s发出一次UDP心跳；
- 回显：控制台WebSocket能否把“在线”状态写回数据库。
只有四项全绿才判为“真在线”，任一红灯即报“离线”。因此，网络正常≠四项全绿，这是排查逻辑的出发点。
方案A：端口与进程速查表
1. 控制台路径差异
桌面端：主界面右上角⚙→诊断工具→端口检测；移动端：App→我的→设置→网络诊断→一键Telnet。若公司电脑禁用Telnet，可改用PowerShell：
Test-NetConnection -ComputerName client-sl.oray.com -Port 443 -InformationLevel Quiet
返回True即443可达，继续测4009、49200、49201（UDP）。
2. 进程与守护
Windows任务管理器→详细信息→确认SunloginClient.exe、SunloginService.exe、SunloginGuard.exe三进程存在；Linux/macOS执行：
ps -ef | grep -E 'sunlogin|oray'
若守护进程SunloginGuard缺失，客户端会在断网后无法自启，表现为“网络恢复但状态仍离线”。手动启动：
sudo systemctl start sunloginGuard
方案B：证书与零信任指纹
2026年起，向日葵个人版也默认开启零信任通道2.0，设备指纹有效期缩短至30天。过期后控制台显示“离线”，但本地网络正常。快速验证：
控制台→设备详情→安全信息→若“设备指纹状态”为失效，点击“重新采集”，被控端会弹出黑框CMD，5秒后自动刷新。
若设备处于无人值守机房，可提前在策略模板里把“指纹失效自动重采”设为开启，避免半夜掉线。
防火墙与白名单：Windows Defender实测
Windows 11 24H2的Defender默认启用“高级威胁防护（ATP）”，会把向日葵UDP 49200-49215标记为P2P-Crypto，直接拦截。操作路径：
- 开始→设置→隐私与安全性→Windows安全中心→防火墙与网络保护→允许应用通过防火墙→点击“更改设置”→勾选Sunlogin Remote Control专用与公用两列；
- 若公司域控推送策略导致按钮灰色，用管理员CMD：
netsh advfirewall firewall add rule name="SunloginUDP" dir=in action=allow protocol=UDP localport=49200-49215
经验性观察：放行后心跳丢包率从12%降至0.3%，远程桌面延迟降低约20ms。
日志分析：三分钟定位错误码
1. 本地日志路径
- Windows：%ProgramData%\Oray\Sunlogin\logs\sunloginClient_YYYY-MM-DD.log
- macOS：/Library/Logs/Sunlogin/sunloginClient.log
- Linux：/var/log/sunlogin/client.log
2. 关键词检索
用VS Code或Notepad++搜索“offline_reason=”，常见枚举：
| 错误码 | 含义 | 处置 |
|---|---|---|
| -3 | 心跳超时 | 检查UDP 49200是否被防火墙拦 |
| -5 | 证书过期 | 重采设备指纹或续期证书 |
| -7 | 多因子冲突 | 关闭“时间因子”或同步NTP |
服务状态与自启动：Linux systemd为例
在统信UOS ARM64机房，systemd 255+默认开启“ProtectHome=read-only”，导致向日葵写入不了~/.config/sunlogin，从而无限重启。编辑：
sudo systemctl edit sunloginclient
在[Service]段新增：
ReadWritePaths=/home/*/.config/sunlogin
重载后systemctl restart sunloginclient，离线提示消失。
场景示例：高校机房200台电脑批量“假离线”
2026年春季学期，武汉某高校机房教师反映：寒假后200台电脑全部显示离线，但能正常上网。按漏斗排查发现，寒假期间统一安装的新版360安全卫士把向日葵加入“恶意驱动隔离区”，导致SunloginGuard.sys未加载。解决：
- 360→木马查杀→恢复区→勾选SunloginGuard.sys→信任；
- cmd执行
sc start sunloginGuard； - 控制台刷新，3分钟内200台全部变绿。
此案例说明：“网络正常”≠“驱动正常”，安全软件更新也会触发伪离线。
不适用场景与回退清单
- BIOS未关闭Modern Standby：笔记本合盖5分钟后自动断网，向日葵无法唤醒，必须进BIOS把“Network Standby”设为Enable；
- 电信NAT444大内网：双栈IPv4被运营商级NAT拦截UDP打洞，即使端口放行也99%离线，建议改用向日葵企业版“BGP中继”，牺牲10ms延迟换稳定性；
- 客户强制要求白名单IP：向日葵边缘节点IP段每月扩容，若客户防火墙无法自动更新，建议改用“私有化部署中转”，否则持续误报离线。
监控与验收：用Prometheus暴露指标
企业版≥500台时，手工刷新已不现实。向日葵v16.2.2开始内置Prometheus exporter，端口9100，指标：
sunlogin_client_up 1sunlogin_heartbeat_loss 0.003
在Grafana设定sunlogin_client_up==0即触发Webhook，推送到飞书。验收标准：连续7天离线率<0.5%且平均延迟<60ms，即视为排障完成。
成本与取舍：是否值得开“AI超分”？
警告
笔记本GTX 1060以下开启AI超分后，显存占用升至2.3GB，可能导致双显卡切换失败而间接掉线。若被控端为核显，建议关闭。
取舍逻辑：画质提升30% vs 离线风险上升2%，对游戏直播等高收益场景值得；对凌晨批量运维，建议统一关闭，策略模板→性能→AI超分→禁用即可。
版本差异与迁移建议
v15.6与v16.2.2的离线判定策略差异：
| 版本 | 心跳间隔 | 超时阈值 | 是否默认零信任 |
|---|---|---|---|
| 15.6 | 120s | 360s | 否 |
| 16.2.2 | 60s | 180s | 是 |
升级后若出现批量离线，优先把超时阈值改回360s，再逐步收紧，控制台→策略→通信→高级→自定义超时。
最佳实践速查表
- 装完系统先跑
sunlog.exe -p，确认4个端口全绿再交工； - 寒假/长假前导出一次“设备指纹有效期”CSV，假期结束批量续期；
- 笔记本统一关Modern Standby，台式机统一关节能网卡；
- ≥100台务必上Prometheus，离线告警与带宽告警并列；
- 任何“网络正常”却离线，先查Guard进程，再查防火墙，最后看证书。
未来趋势：v17将引入“离线原因AI摘要”
官方 roadmap 提及，v17会直接把错误码-3/-5/-7翻译成中文摘要，并给出“一键修复”按钮，预计2026Q3公测。届时，排障漏斗可能缩短至两步：点击“诊断”→AI给出“360拦截，是否自动信任？”即可。但在版本落地前，本文的四步漏斗依旧是最低成本的可复现方案。
常见问题
为何本地能ping通百度，向日葵却提示离线？
ping 只验证 ICMP 可达性，而向日葵依赖 TCP/UDP 特定端口与证书双向鉴权。防火墙放行 ICMP 并不等于放行 49200-49215 UDP，需按文内“端口与进程速查表”逐项核对。
设备指纹已续期，仍报离线怎么办？
经验性观察：部分环境需重启 SunloginService 才能刷新缓存。执行 sc stop sunloginservice && sc start sunloginservice 后，再查看控制台是否变绿；若仍失败，检查日志错误码 -5 是否转为 -3，以确认是否转为网络问题。
Linux 日志出现“ProtectHome=read-only”怎么解决？
systemd 255+ 默认限制写入用户目录。按文内“服务状态与自启动”章节，给 sunloginclient 单元新增 ReadWritePaths=/home/*/.config/sunlogin，重载 systemd 即可。
NAT444 网络能否强制打洞成功？
经验性观察：运营商级 NAT 场景下 UDP 打洞成功率不足 1%，且 IP 随时变动。建议直接使用向日葵企业版 BGP 中继或私有化中转，放弃打洞方案以换取稳定连接。
Prometheus 指标正常，但控制台仍显示离线？
控制台状态依赖 WebSocket 回写，若浏览器存在代理缓存或数据层同步延迟，可能出现“指标绿、界面红”。强制刷新浏览器或等待 90s 心跳回写即可同步，不影响实际连接。
结论
向日葵客户端提示主机离线但网络正常，本质是“网络可达≠服务可达”。按端口-进程-证书-日志四步排查，可在十分钟内完成定位；结合Prometheus与策略模板，可把离线率长期压在0.5%以下。升级v16.2.2后，务必关注零信任指纹与AI超分副作用；若环境为NAT444或强制白名单，优先考虑BGP中继或私有化中转，不要死磕打洞。v17的AI摘要值得期待，但现版本的可审计日志与错误码，仍是政企合规运维最可靠的证据链。
