1. 项目概述与环境准备做企业内部文档协作的时候OnlyOffice是个绕不开的名字。它最大的价值在于一套开源的在线文档套件能直接在浏览器里编辑Word、Excel、PPT还支持多人协同效果和体验跟桌面Office很接近。但我发现一个有意思的现象很多团队把OnlyOffice部署起来之后由于一直是拿HTTP裸奔访问的真到上线阶段一接入企业微信、钉钉、Nextcloud这类第三方平台或者需要在浏览器里正常使用摄像头、麦克风、剪贴板等权限时瞬间就被浏览器拦住了。所有现代浏览器的安全策略都指向同一个结论只有HTTPS页面才能调用高级API只有HTTPS页面才能被第三方安全地嵌入。所以给OnlyOffice配置HTTPS访问不是锦上添花而是上线必修课。这篇文章写给三类人一是公司内部想自建在线文档平台但还没完全搞定安全访问的运维二是用Nextcloud、Jira、Confluence等系统想集成OnlyOffice的开发三是纯粹想在NAS或虚拟机上折腾一套私有办公套件的技术爱好者。我会把从环境准备、证书申请、Nginx反向代理配置到踩坑排查的完整过程讲清楚而且所有命令和配置都是可以直接复制照用的。先交代一下我这次的部署环境方便你对照。我用一台Ubuntu 22.04的服务器2核4G内存系统里已经装好了Docker和Docker Compose域名是office.example.com服务器IP做了公网解析防火墙只放行了80和443端口。OnlyOffice官方推荐用Docker部署DocumentServer这是最省心的方式。如果你还没装Docker就安装一下curl -fsSL https://get.docker.com | bash systemctl enable --now docker我这里不展开讲Docker安装的细节因为那不是重点。重点是接下来的部署。OnlyOffice DocumentServer的容器镜像不算小大概在2GB左右拉取时间取决于你的网络环境耐心等就行。执行下面的命令先把基础容器跑起来后面再配HTTPSdocker run -i -t -d -p 127.0.0.1:8080:80 \ --restartalways \ -e JWT_ENABLEDtrue \ -e JWT_SECRETmy-super-secret-key-change-me \ -v /opt/onlyoffice/logs:/var/log/onlyoffice \ -v /opt/onlyoffice/data:/var/www/onlyoffice/Data \ -v /opt/onlyoffice/lib:/var/lib/onlyoffice \ -v /opt/onlyoffice/db:/var/lib/postgresql \ --name onlyoffice-document-server \ onlyoffice/documentserver:latest注意我这里是先把容器端口映射到127.0.0.1:8080而不是直接映射到公网。原因很简单HTTPS这层交给Nginx来处理OnlyOffice容器本身不直接对公网暴露端口这样能把TLS终止、HTTP头过滤、访问控制都收敛到Nginx这一层以后排查问题和安全加固都方便。关于JWT密钥我后面专门出一节讲现在先记住一点如果你要集成Nextcloud这类第三方应用JWT必须开启并且第三方应用配置的密钥要跟这里保持一致。容器启动之后先用docker ps看状态再用docker logs -f onlyoffice-document-server跟踪日志看到类似Server started successfully的输出说明OnlyOffice本身已经跑起来了。这时候你在服务器上浏览器访问127.0.0.1:8080或者在本机ssh隧道转发端口应该能看到OnlyOffice的欢迎页。但注意这台服务器上的Nginx还没安装域名解析也还没起作用所以外部访问还没有真正打通接下来要做的事就顺理成章了规划HTTPS的访问方案。2. HTTPS方案选型与核心认知很多人一上来就直接问OnlyOffice怎么配HTTPS实际上OnlyOffice本身并不直接管理证书它只是运行在HTTP之上的Web服务。HTTPS的终止点也就是解密HTTPS流量的那个位置才是你真正要决策的地方。这里有三条路线各有适用场景我逐个分析你可以根据自己的情况选一条。第一条路线是直接用Nginx或Caddy做反向代理把443端口的HTTPS流量解密后转发给后端的OnlyOffice容器。这是我现在推荐的主流做法也是绝大多数线上部署的标准姿势。优点是证书管理灵活续期自动化容易可以通过同一台Nginx做多域名转发还能统一加WAF规则、限流、访问日志未来如果要接多个OnlyOffice实例或者负载均衡都在这一层展开。第二条路线是让OnlyOffice容器自己监听443端口把证书和私钥直接挂载进容器。OnlyOffice官方的Docker镜像本身是支持HTTPS直连的你只需要在环境变量里指定证书路径把证书文件挂载进去把容器端口映射改为443就行。对于不想额外装一层Nginx的小规模场景比如个人NAS、实验室环境这种方案能用但升级镜像时证书管理容易混乱而且一旦想加HTTP到HTTPS的自动跳转又得绕回反代方案灵活性差一些。第三条路线是干脆不让外网直接访问走内网部署、内网DNS解析证书也是内部CA签发的。这种方案常见于纯内网、无外网暴露需求的企业环境。但要注意内网CA发的证书会让浏览器弹不受信任你需要把CA根证书推送到每台客户端的受信任根证书存储区否则天天有人在群里发截图问为什么提示证书错误。对于几十人规模的小团队这方案也能跑但维护成本不低。三类方案的取舍我直接用一张表给你看清楚方案适用场景优点缺点Nginx/Caddy反代生产环境、公网/公司内网证书管理灵活、可扩展性强、便于统一管控需多维护一个服务容器HTTPS直连个人NAS、测试环境架构简单、不用装额外组件证书续期麻烦、升级易出错内网CA内部DNS纯内网、无外网需求数据不出内网、可控性高客户端需装CA证书、维护成本高看完这张表你应该心里有数了。如果你是在公司做统一部署或者准备用Lets Encrypt这类免费证书我的建议是别犹豫直接上方案一。这也是下文的核心内容。这里还要补一个基本概念OnlyOffice的服务结构。DocumentServer容器内部实际上跑了好几个子服务包括文档转换服务、协同编辑服务、回调服务、WebSocket长连接等。协同编辑非常依赖WebSocket它需要在客户端和服务器之间维持一条长连接来实时同步光标位置和编辑内容。这条WebSocket连接同样要走HTTPS所以在配置Nginx反向代理时除了常规的HTTP流量转发还必须处理Upgrade请求头。很多人的OnlyOffice在HTTP下一切正常换成HTTPS之后能打开编辑器但无法多人协同或者打字延迟特别大往往就是WebSocket这条通道没打通。理解了这一点你就知道配置HTTPS的核心绝对不是把ssl on打开这么简单而是要确保以下四条链路全部都走TLS一是用户浏览器的静态资源加载包括编辑器界面、脚本、样式二是API调用比如创建文档、保存文档这些请求三是文档服务之间的回调请求这个通常由第三方应用比如Nextcloud发起地址必须写成HTTPS的四是WebSocket长连接用于协同编辑的实时通信。其中前三条配好了基本不会出问题第四条最容易被漏掉后面我在Nginx配置节里会专门标注。我自己的习惯是在做任何HTTPS配置之前先在浏览器里用HTTP把OnlyOffice完整跑通一遍确认新建文档、多人协同、保存这些功能都正常再套HTTPS。这样做的好处是一旦HTTPS上线后出了问题你能很快定位是证书、代理配置还是OnlyOffice本身的故障不用一把抓。3. 证书申请与Nginx反向代理配置实操3.1 申请免费证书并配置自动续期证书方案我默认用Lets Encrypt的免费证书因为它是目前兼容性最好、申请最方便、自动化程度最高的选择。你需要一个域名并且确保这个域名的A记录已经解析到你服务器的公网IP。这一步非常关键Lets Encrypt在签发证书时会通过HTTP-01或DNS-01方式来验证你对域名的控制权如果解析没生效申请必然失败。我这里用的是certbot工具安装和申请过程如下apt update apt install -y certbot certbot certonly --standalone -d office.example.com --email youexample.com --agree-tos --no-eff-emailcertbot的--standalone模式会临时占用服务器的80端口来完成域名验证所以如果你服务器上已经跑了Nginx或其他Web服务先把它们停掉等证书申请完成再启动。如果不想停服务可以用--webroot模式让certbot把验证文件丢到Nginx的webroot目录Nginx继续正常服务。我个人的建议是在正式配置Nginx之前申请证书直接用--standalone最省事因为这时候Nginx还没装或者还没接管端口。申请成功之后证书文件会出现在/etc/letsencrypt/live/office.example.com/目录下有两个关键文件fullchain.pem是证书链包含你的域名证书和中间证书privkey.pem是私钥。这两个文件是Nginx配置要用的权限默认是root所有Nginx工作进程以www-data或者其他低权限用户运行但读这些文件一般没问题因为/etc/letsencrypt目录是755权限文件是644权限证书内容本身不算机密机密的是私钥但644权限对私钥来说已经够用只要你的服务器上没有其他可疑用户即可。自动续期一定要配Lets Encrypt证书有效期是90天到期前不续期HTTPS就直接失效用户访问会看到红色警告。certbot装好后续期配置写在了系统服务里但保险起见我建议你手动确认一下cron任务或者systemd timer是否存在。可以用下面命令测试续期流程能否正常执行certbot renew --dry-run如果输出显示No renewals were attempted或者Succeeded就说明续期配置没问题。部署的时候把下面这条命令加进crontab每个月1号和15号各执行一次续期后自动重载Nginx让新证书生效0 3 1,15 * * certbot renew --quiet --deploy-hook systemctl reload nginx这里--deploy-hook的含义是只有当证书确实被续期成功时才执行reload nginx的命令。如果证书还没到期不会触发reload这样不会白白重启服务。3.2 安装Nginx并编写HTTPS反向代理配置证书准备好之后我来把Nginx侧的所有配置一次性交付给你。首先安装Nginxapt install -y nginx systemctl enable --now nginx然后修改/etc/nginx/conf.d/onlyoffice.conf写入下面的完整配置。这套配置是我在多次生产环境部署中逐步打磨出来的针对OnlyOffice的几条特殊路径做了处理直接复制就能用server { listen 80; server_name office.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name office.example.com; ssl_certificate /etc/letsencrypt/live/office.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; client_max_body_size 100m; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } location /websocket/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 600s; } }这段配置里有三个细节我必须单独拧出来讲。第一个是Upgrade头。OnlyOffice协同编辑依赖WebSocket浏览器在发起WebSocket连接时会带上Upgrade: websocket和Connection: Upgrade这样的请求头Nginx默认不会把这些请求头原样转发给后端。如果不处理OnlyOffice容器内的WebSocket服务永远接不到客户端的连接请求你会看到打开编辑器后左下方的连接状态一直转圈或者多人同时编辑时看不到彼此的鼠标移动。我这里的做法是把Upgrade和Connection作为默认头加到location /同时单独为/websocket/路径再设置一次并且把proxy_read_timeout拉长到600秒防止长连接被Nginx的默认60秒超时掐断。第二个是X-Forwarded-Proto。把这个头设置成$scheme也就是https是告诉后端OnlyOffice客户端原始请求是HTTPS的它生成的各种回跳URL、回调URL都会基于这个信息来构造。这个头如果不设置OnlyOffice会以为所有请求都是HTTP来的于是出现在编辑器里生成的一些链接会以http开头嵌入到第三方系统时又以https上下文加载就产生了混合内容Mixed Content浏览器直接给你拦掉白屏、按钮点击没响应都是这么来的。第三个是client_max_body_size。OnlyOffice上传文档时如果你不给上传体积设置上限默认1M。虽然这个Limit通常由调用方的服务器来控制但后端Nginx如果限制太小一旦有人传一个10M的文档请求就会在Nginx这一层被直接拒绝返回413错误。我把这个值设成了100m足够应对绝大多数办公场景你需要根据团队实际情况调整。写完配置后用nginx -t检查语法确认无误后重载nginx -t systemctl reload nginx到这里HTTPS访问的骨架已经搭好了。你用手机流量或者浏览器打开https://office.example.com应该能看到一个小锁图标。但注意现在的成功访问只是OnlyOffice的欢迎页能打开了真正要让它被第三方系统正常嵌入使用还需要配置JWT和回调地址这是下一节的内容。3.3 配置JWT与OnlyOffice回调地址OnlyOffice DocumentServer 7.2之后默认强制开启JWT签名。JWT的全称是JSON Web Token简单理解就是OnlyOffice API调用时在请求里携带的一个加密签名用来防止有人伪造请求调用文档服务。第三方系统比如Nextcloud如果要在后台发起文档编辑请求必须用同一个JWT密钥来签名DocumentServer才会信任它。如果你用的是我第一小节里给的docker run命令那么JWT已经在容器启动时通过环境变量配好了密钥是my-super-secret-key-change-me。这个值你一定要改成自己的随机字符串至少32位可以用openssl rand -hex 32来生成。但要记住一旦改了密钥所有接入OnlyOffice的第三方系统都要同步改否则第三方会收到401错误编辑器加载不出来。检查容器中JWT是否生效可以进入容器验证docker exec onlyoffice-document-server cat /etc/onlyoffice/documentserver/local.json在输出里找到services.CoAuthoring.token.enable这个字段如果为true就说明开启了。另外JWT校验的配置通常在local.json的token.inbox和token.outbox两个部分分别对应接收请求和发送请求时的签名校验规则。容器环境变量JWT_SECRET配好后只有第一次启动时会写入local.json之后你再改环境变量是不会自动重写配置的必须把容器删掉重新run或者手动修改local.json后重启容器。这里还有一个非常隐蔽的坑如果上面local.json里token.inbox的enable为true而第三方系统发起的回调请求没有携带正确的JWT签名OnlyOffice会返回401然后编辑保存的时候第三方系统收不到保存回调文档怎么改都存不回去。表现就是你在编辑器里编辑了半天点保存没有报错但关闭后到文件列表里一看内容还是旧的。这个问题排查很费时间因为错误日志藏在容器的日志里不仔细看还真发现不了。所以我给你的建议是在集成第三方系统之前先用官方提供的JWT生成工具做一次API连通性测试确认签名没问题再接入业务系统。如果你根本不打算接第三方只是想让用户直接在OnlyOffice页面里传文档编辑那当然也可以关闭JWT。但我不建议在任何半开放的网络环境里关闭JWT因为DocumentServer的编辑接口只要能访问到别人就能拿它当免费云盘用甚至通过恶意JWT配置发起请求安全风险不小。接下来是回调地址的问题。OnlyOffice的在线编辑流程大致是这样的用户在Nextcloud里打开一个文档Nextcloud向DocumentServer发起一个请求请求里带一个callbackUrl参数这个参数指向Nextcloud自己的一个API端点。用户编辑完文档点保存DocumentServer会把文档内容以回调的形式POST到这个callbackUrlNextcloud收到后把内容写回存储。这个callbackUrl必须是DocumentServer能够访问到的地址而且必须是HTTPS否则现代浏览器会当它是不安全的混合内容直接拦截或者即使不拦截Nextcloud后台日志里也会不断出现回调失败记录。你在接入第三方系统时需要在第三方系统配置一个DocumentServer的地址也就是你现在配置好的https://office.example.com同时把JWT密钥也填成跟DocumentServer一致。以Nextcloud为例安装ONLYOFFICE插件后在管理设置里填两样东西Document Editing Service地址填https://office.example.comSecret key填你刚才设置的JWT密钥。其他地方不用动插件自己会处理callbackUrl的拼接。如果之后你发现文档编辑完成后没有保存回Nextcloud优先去Nextcloud的日志里搜onlyoffice八成能看到callback或者signature相关的报错再加排查。4. 常见问题与排查技巧实录配置HTTPS的过程中我一路踩了不少坑有些问题看似是OnlyOffice的锅实际上是Nginx或证书层面的问题。我把自己遇到的典型问题整理成了一份速查表希望能帮你省下几个小时的排查时间。症状可能原因排查命令 / 解决动作浏览器提示证书不受信任证书链不完整 / 自签名证书未导入用curl -vI查看证书链确认fullchain.pem而非cert.pem打开编辑器白屏Nginx未转发X-Forwarded-Proto产生混合内容确认配置里有proxy_set_header X-Forwarded-Proto $scheme多人协同不可用、光标不同步WebSocket未走HTTPS / 被Nginx超时断开确认Upgrade头配置缩短代理超时改为600s文档编辑后无法保存JWT签名不一致或callbackUrl缺失查看容器日志docker logs核对第三方系统JWT密钥上传大文档返回413Nginx的client_max_body_size太小调整配置后reload nginx页面能打开但API返回502容器后端未启动或端口映射不对docker ps确认端口curl http://127.0.0.1:8080测试证书到期后突然无法访问自动续期未配置或续期后未重载Nginx执行certbot renew --dry-run设置--deploy-hook下面挑几个展开细讲因为光看表格你到实际操作时可能还是会卡住。第一个是证书链不完整的问题。Lets Encrypt签发的证书由三个部分组成你的域名证书、中间证书、根证书。浏览器内置了根证书的信任信息但中间证书必须由服务器下发否则浏览器无法把域名证书链接到根证书上就会提示证书不受信任。很多人申请证书后拿到的是cert.pem也就是只包含域名证书的文件没有中间证书结果配置到Nginx后一直被浏览器报不受信任。解决办法很简单Nginx的ssl_certificate直接用fullchain.pem这个文件是域名证书和中间证书的合并。如果你是从云厂商云盾或证书服务商下载证书包里面通常有nginx目录那个文件一般也已经是完整链。第二个是WebSocket代理超时的问题。OnlyOffice协同编辑在多人同时在线时会保持WebSocket长连接如果这个连接闲置了一段时间Nginx默认的proxy_read_timeout是60秒超过60秒没有数据流动Nginx就把连接掐了。表现是用户在编辑器里挂机超过一分钟再打字时没有任何反应或者重新连接要等好几秒。最典型的场景是一个人开着文档去开会半小时回来再输入文字页面从连接已断开恢复到已连接要等好几秒期间输入的内容有可能会丢。解决办法就是我在配置里写的proxy_read_timeout 600s同时给/websocket/路径单独设置避免影响普通HTTP请求的响应时间。第三个是自签名证书的内网环境问题。有的朋友公司纯内网部署OnlyOffice没有公网域名只好用自签名证书。我不会完全否定这个方案但你必须清楚自签名证书不被浏览器信任每个浏览器首次访问时都会跳出安全警告用户必须手动点高级-继续前往而且每次重启浏览器后可能又要点一次。团队里有几个非技术用户投诉量肯定大。解决办法是把自签名CA的根证书导入到域控通过组策略推送到每台Windows机器的受信任的根证书颁发机构存储区这样浏览器才会安静下来。但这个操作只管WindowsMac和Linux要分别配置工作量不算小。第四种情况更隐蔽你用了自签名证书但Nginx配置正确浏览器警告也点过去了OnlyOffice开始加载却在某一瞬间就断了。你去控制台看会发现WebSocket连接报了SecurityError或者证书错误。原因还是在自签名证书不受信任上页面本身加载时你手动点了一次继续前往但WebSocket连接是浏览器内部发起的它不受你手动点击的影响仍然会用严格的证书校验策略一旦证书不受信任就直接拒绝连接。所以自签名证书做演示还行真要落地生产环境优先考虑把证书换上正规CA签发的哪怕是免费证书也比自签名证书省心得多。5. 安全加固与后续扩展思路HTTPS配完之后工作其实还没完。既然已经到了上线阶段安全方面的加固就不能光靠一纸证书。我总结了我常用的几项配置你可以按需加上。第一项是限制API访问范围。OnlyOffice DocumentServer不仅仅是编辑器页面它还暴露了一些API端点比如文档转换服务这些端点如果完全公开别人拿你的服务器当免费转换服务用会消耗不少CPU和内存。Nginx层配置一条访问控制规则把/ConvertService.ashx等路径限制在内网IP段是成本最低的加固方式。当然如果你有第三方系统需要从公网调这些API那就不能这么简单封掉你需要在业务网关上做更细粒度的鉴权。第二项是容器资源限制。OnlyOffice在文档转换和协同编辑时对CPU和内存的消耗并不小尤其在多人同时编辑高分辨率文档的时候。我在生产环境用的是下面这样的配置限制容器最多使用2核CPU和4G内存防止某个恶意大文档把宿主机资源全部吃光deploy: resources: limits: cpus: 2 memory: 4G第三项是定期看日志。容器日志默认输出到stdout可以用docker logs --tail 100 -f查看实时日志。长期运行的话我建议把stdout日志交给logrotate统一管理避免日志文件无限膨胀。OnlyOffice容器内部把日志写在/var/log/onlyoffice目录我已经通过-v挂载到了宿主机的/opt/onlyoffice/logs这样即使容器销毁日志也还在排查问题不用进容器里翻。第四项是配置监控。不管你的OnlyOffice是裸奔还是在Nginx后面我都推荐至少监控三个指标进程状态、443端口连通性、系统的内存占用。最轻量的做法是用crontab配合curl脚本做心跳检测*/5 * * * * curl -fsS -o /dev/null https://office.example.com/healthcheck || echo OnlyOffice down | mail -s alert youexample.comOnlyOffice有专门的健康检查接口返回OK就说明所有核心服务正常。这个接口比单纯检查端口要靠谱因为它会同时检查文档转换服务、协同编辑服务等多个内部组件的状态。后面如果你要把OnlyOffice用到更大规模可能还会遇到这几个方向一是多节点负载均衡用Kubernetes或者Docker Swarm做横向扩容但要注意Session会话共享和WebSocket亲和性直接做轮询负载均衡会让协同编辑瞬间断连二是把存储从本地目录切换到对象存储OnlyOffice支持外部存储配置但配置相对复杂涉及所有容器节点的数据一致性三是与现有企业账号体系对接OnlyOffice支持通过JWT自定义用户信息这可以用来做单点登录集成。这些内容每一个都能单独写一篇长文将来有机会我再挨个展开。6. 实际操作中容易忽略的细节前面把方案和配置都讲完了本来可以直接收尾但我还是想额外啰嗦几句因为这几个细节在我自己的部署过程中都真实地让我多花过时间提前知道能帮你少走弯路。第一个是时区问题。OnlyOffice容器默认时区是UTC如果你的服务器在中国时区日志里的时间戳看着就会别扭排查问题时对不上号。解决办法是在docker run时加一个环境变量-e TZAsia/Shanghai这个问题本身不致命但当你抓日志排查为什么回调在XX点没有到达时时间对不上会让你多懵一会儿。第二个是防火墙和安全组。很多云服务器除了系统iptables外还有一层云安全组规则。如果你在服务器内用curl测https能通但外网访问不了十有八九是安全组没放行443端口。这件事我提醒过不止一个同事他们在本地调试半小时最后发现是云控制台里的安全组规则没加。第三个是HTTPS配置好之后的回归测试。我想强调的不是测试能不能打开页面而是完整的编辑流程测试。建议你准备好三份测试文档一份Word、一份Excel、一份PPT分别执行以下操作打开文档、输入文字、保存、关闭、重新打开确认内容存在。如果条件允许用两个不同的浏览器比如Chrome和Edge同时打开同一个文档测试基本协同功能。这一轮测试能覆盖到前面说的WebSocket、回调、存储三大链路任何一环有问题在这个时候都会暴露出来。第四个是文档存储的备份策略。OnlyOffice的文档数据并不都存放在DocumentServer里DocumentServer更像一个编辑引擎最终文档内容都通过回调写回第三方系统。所以你在做备份时核心要备份的是第三方系统的存储目录而不是OnlyOffice容器里的data目录。这一点一定要跟团队里的运维同事讲清楚否则天天备份一个不承载最终数据的容器目录真出事的时候该丢的文档照样丢。我个人折腾OnlyOffice的这几次最大的感受是配置的过程本身并不复杂真正花时间的地方在于理解它内部的请求链路。你把用户浏览器 → Nginx → DocumentServer → 回调第三方系统这条链路里的每个环节想明白任何一个报错你都能顺着链路去排查而不是东一头西一头地试。这套方法论不管以后是配置Nextcloud集成还是接入企业微信官方文档应用都能用上。最后分享一个小技巧排查OnlyOffice问题时多用浏览器的开发者工具看Network面板特别是那些红色的请求和返回的HTTP状态码。200和预期行为基本一致401和403基本往JWT签名和权限方向查502和504基本往代理和后端服务方向查。把这个习惯养成你会发现很多神秘问题原来都很简单。