海上连接变慢时，先判断链路还是设备

排查应保持任务不变并逐层比较，而不是同时更换所有条件。

先描述真正受影响的任务

网页打开慢、照片上传中断、实时状态延迟和大文件补传失败，可能由不同环节造成。先记录任务、时间、网络类型、目标页面与错误提示，避免只用“网络不好”概括。

选择一个低风险代表任务重复测试，比连续刷新多个页面更容易看出变化。

存储空间不足、后台限制、系统时间错误和电池省电，都可能让应用表现得像断网。先确认其他本地功能与同一网络下的不同应用是否正常。

若只有一台设备异常，可以在不改变账号和任务的前提下用另一台受支持设备对照。

信号格数只反映接入的一部分。天线姿态、卫星遮挡、蜂窝回传和运营商拥塞都可能影响实际任务。

能够访问普通网页却无法完成目标服务，也可能来自远端维护、会话过期或文件限制，不应立即归因于海上链路。

同时切换网络、重装客户端、修改DNS和更新系统，会让恢复原因无法判断。先保存现场状态，再按本地设备、接入链路、岸站和目标服务逐层验证。

调整后重复同一任务，并记录结果。无效操作及时回退，避免累积新的配置问题。

传输进度重新前进不代表先前分块完整。检查对象数量、大小、摘要或应用提供的完整性结果，尤其是在断线重连后。

如果资料用于研究或运行决策，接收方还应抽查能否打开和解释，而不是只看发送端成功提示。

简短记录应包含设备、版本、时间、位置范围、任务、已尝试操作与最终结果。不要提交密码、验证码或敏感配置。

下一位维护人员能根据记录复现问题，才算真正完成排查。否则同一故障会在下一次航次重新开始。

船体转向、桅杆设备和高浪都可能让天线暂时失去理想视野。若故障与航向或摇摆同步，应先检查天线状态和安装位置。信号恢复后再观察任务是否自动续传，避免把短暂接入变化误判成账号失效。

同一设备和同一文件在靠港网络完成，说明客户端与目标服务大致可用，问题更可能位于海上接入或中间路径。如果靠港后仍然失败，应继续检查文件限制、会话、存储和服务状态。对照测试需要保持文件版本不变，才有比较价值。

接收目录容量不足、单文件限制或账号权限变化，也会让上传停在最后阶段。排查时查看目标端是否产生临时对象、是否返回明确状态，以及其他成员能否写入同一位置。确认配额后再重复任务，能避免持续消耗有限的海上流量。

问题消失后写下真正起作用的操作、当时网络和服务状态，并标记仍无法确认的原因。这样下次遇到相似现象时，可以从已验证线索开始，而不是重复所有尝试。