私有化 Office 页面静置后断连，先查真实连接经过哪些代理，以及哪一跳在什么时间关闭了连接。用户没有打字，不等于服务端没有发送数据；把超时统一调大，也不能证明编辑内容已经保存。对实际采用 WebSocket 的部署，应分开核查握手、静置期间通信、重新鉴权和保存结果。
看到 101，只说明握手走通了
NGINX 的 WebSocket 代理说明介绍了 HTTP/1.1 协议升级：客户端请求升级、上游返回 101 时可建立隧道；Upgrade 与 Connection 是逐跳头，需要显式传给上游。因此，首次连接失败时应先核对升级请求和代理配置；已经取得 101、过一段时间才断开的情况，则需要继续看连接期间发生了什么。
排查时还要记下实际版本。当前代理模块文档说明，自 1.29.7 起代理 HTTP 默认版本为 1.1，此前为 1.0。旧教程中的配置前提未必适合当前环境，不能仅靠复制一行配置判断修复完成。
计时起点是上游数据，不是最后一次打字
NGINX 官方说明，默认情况下，上游若在 60 秒内没有传输任何数据，连接会关闭。模块文档进一步明确，proxy_read_timeout计算的是相邻两次读取之间的间隔，不是整场会话的最长持续时间。因此，页面打开十分钟仍连着并不反常；是否触发这一超时，要看这一跳读到上游数据的间隔。
同一份 WebSocket 说明提到，上游周期发送 Ping 帧可以重置读超时并检查连接。这里不能把鼠标移动、用户输入、应用自己的心跳或任意方向的网络流量直接视作等价证据，应确认实际由谁发送、哪一跳收到、对应什么计时规则。
其他超时也要区分：proxy_connect_timeout针对建立上游连接，proxy_send_timeout针对向上游连续两次写操作之间的间隔。它们不能与读超时互换解释，更不能由“断在一分钟附近”直接认定根因。
沿真实代理链留一份时间记录
建议由企业 IT 与实施方先画出浏览器、负载均衡或网关、NGINX、应用服务的实际路径。并非所有部署都有这些组件；有几层就逐层确认规则，不因为改过 NGINX 就忽略前面的网关。
在授权测试环境使用虚构文档，统一各层时间口径，记录连接标识、首次握手结果、最后一次上游数据的时间、连接关闭时间、关闭原因或错误日志。日志只保留必要定位信息，去掉 Cookie、令牌、带凭据的地址和文档正文。若某层没有足够证据，明确写出缺口和负责补证的人。
如果同一入口会分流到不同节点，应把受测连接实际经过的节点一起记下。一次成功和一次失败可能走了不同配置；先对齐路径与版本再比较，避免将节点差异误判成偶发网络问题。未知路径也应列作证据缺口。
例如观察到“页面打开后约一分钟断开”，只能作为线索；补齐“哪层最后一次收到数据、是否先出现关闭记录、当时生效配置是什么”，才有条件判断。浏览器的断开提示可能晚于服务端动作，不能单凭一张页面截图指定责任方。
用静置与恢复交互两段测试确认结果
以下是建议测试步骤，尚未对具体产品执行。先在正常网络下打开测试文档，确认连接与保存基线，再静置一段覆盖拟排查超时窗口的时间，保留静置期间实际通信记录。接着恢复一次可辨认的编辑，观察仍用原连接还是发生重连，分别记录连接结果与用户可见状态。
若重新连接被认证拒绝，应查相应会话与鉴权规则；它与代理因读超时断开可能相继发生，却不是同一个问题。若连接恢复，还要按产品支持的方式确认保存，并重新打开文件核对测试标记。握手成功、连接恢复和内容保存，各有自己的通过证据。
只有根因和业务需求明确后，才由运维方评估超时、心跳或会话设置的调整，并在同一测试条件下复验。调整一处可能改变连接占用或故障发现时间，不能照抄某个通用秒数，更不能用一次正常演示承诺所有网络条件都可靠。
选型石墨办公套件私有部署时，可带上企业实际代理路径、静置使用场景和已有故障记录，预约演示确认验证安排。采购验收应保留能复查的连接与保存证据，而不是一句笼统的“长连接已配置”。也可以先看私有化部署方案，了解部署形态与交付范围。