OnlyOffice HTTPS配置实战：解决混合内容拦截与白屏问题

你在用 OnlyOffice 自建在线文档服务吗？如果只在局域网里用 IP 访问，可能一直没被这个问题找上门。上周同事找我，说他把 OnlyOffice 文档服务器从内网搬到外网后，在线编辑器一直白屏，浏览器地址栏域名已经带上了上锁图标，页面也能开，可一旦点开文档就卡住不动。我打开开发者工具，控制台一屏红色报错：Mixed Content，HTTPS 页面试图加载 HTTP 的 OnlyOffice 脚本，被浏览器全部拦截。那一刻我就知道，这是每个 OnlyOffice 使用者都躲不开的 HTTPS 配置问题。

OnlyOffice 文档服务器本质是一套 Web 应用，前端要从服务端拉取 JS 脚本、建立 WebSocket 长连接、加载 sharedWorker，内部还会回调第三方系统保存结果。只要你的访问入口是 HTTPS，它下面的所有子资源就必须跟着是 HTTPS，否则白屏、无法保存、协作断开都是家常便饭。这篇文章把我在生产环境配置 OnlyOffice HTTPS 访问的完整思路写下来，包括为什么必须做、证书怎么选、Nginx 反向代理怎么配、Docker 容器内怎么直接启用证书，以及和 Spring Boot 这类系统集成时踩过的坑。无论你是运维还是后端开发，照着操作基本能少熬两天夜。

1. 为什么 OnlyOffice 非上 HTTPS 不可：从一次白屏事故说起

1.1 白屏事故的根因：浏览器把 Mixed Content 全拦了

那台 OnlyOffice 文档服务器本身部署在 Docker 里，内网通过http://192.168.1.10:8088一直用得挺好。同事为了给公司 OA 系统用，在公网 Nginx 上做了反代，加了 Let's Encrypt 证书，浏览器访问https://office.example.com能打开欢迎页。但进入在线编辑页面后，所有图标加载不出来，画面一片白。

原因不复杂。浏览器有一条硬性安全策略：HTTPS 页面里不允许加载 HTTP 子资源，这叫 Mixed Content 拦截。OnlyOffice 编辑器的 HTML 页面是 HTTPS 的，但页面里引用的 API 脚本、CSS、字体、图片，以及后续建立的 WebSocket 连接，如果走了 HTTP，浏览器会直接拒绝。当时 F12 里可以看到大量带blocked:mixed-content字样的报错，这就是问题本身。

这里要提一个容易被忽略的点：OnlyOffice 的欢迎页和真正的编辑器前端不是一回事。欢迎页可能只引用了少量静态资源，即使被拦截也还能渲染，所以看起来“网站能打开”。但编辑器页面依赖一堆动态脚本，任何一个核心脚本被拦，功能就全废。排查时不能只看首页能不能开，要真的点进去编辑文档才能验证。

1.2 HTTPS 不只是“加把锁”：还有 Secure Context 这层硬门槛

很多人觉得 HTTPS 只是加密传输，防止密码被窃听，这种理解没错但不完整。浏览器把很多高级 API 限定在“安全上下文”（Secure Context）里使用，只有 HTTPS 页面或 localhost 才能调用。OnlyOffice 编辑器对这类 API 依赖很深，最典型的是以下几个：

• SharedWorker：OnlyOffice 多标签页协同编辑时，多个浏览器标签页之间要共享一个后台 Worker，这个能力只对安全上下文开放。如果服务跑在 HTTP 下，SharedWorker 可能直接不可用，轻则功能降级，重则编辑页面起不来。
• navigator.clipboard：富文本编辑器里的复制粘贴，很多粘贴增强功能靠 Clipboard API，HTTP 下会被禁用。
• 全屏、通知、音视频设备等权限 API：PPT 演示时点全屏、文档里插入录音等场景都会受影响。

说白了，不配 HTTPS 的 OnlyOffice，即使你觉得“能用”，也只是在用一个残缺版。一旦用户用到协同、剪贴板增强、全屏演示这类高频功能，问题就会集中暴露。

1.3 哪些场景下你一定会被 HTTPS 卡住

一类情况是服务要发布公网。现在主流浏览器对一个 HTTP 网站的标记越来越不友好，地址栏直接显示“不安全”，用户信任度大打折扣。而且很多企业微信、钉钉、飞书的内部页面，或者第三方平台的 H5 容器，天然要求页面必须走 HTTPS。

另一类情况是 OnlyOffice 要被集成到已有 HTTPS 站里。比如 Java 的 Spring Boot 项目，页面本身就是https://xxx，然后用 iframe 嵌入 OnlyOffice 编辑器。这时 iframe 内嵌的地址如果还是http://ip:port，浏览器同样会判定为混合内容，直接拦截编辑器。哪怕你把 OnlyOffice 单独留在 HTTP，也会被主站的安全策略拖死。

还有一类是企业内部的内网场景。很多公司装了 AD 域、配置了多种浏览器组策略，会强制要求内网服务也走 HTTPS。我在本地环境给客户做私有化部署时，对方安全部门给了一个硬性清单，其中一条就是“所有办公类 Web 服务必须启用 TLS”。这种情况下，HTTPS 配置不是技术选项，而是上线前置条件。

2. 部署形态与证书选型：先想清楚再动手

2.1 OnlyOffice 常见的部署形态，决定 HTTPS 配置在哪里做

配置 HTTPS 之前，先搞清楚你手上的 OnlyOffice 是哪种部署方式，这直接决定后续改哪里。

• Docker 单容器：官方镜像onlyoffice/documentserver，一条docker run或者 docker-compose 里只定义这一个容器。所有配置本质是修改容器环境变量和挂载文件。
• Docker Compose 全家桶：官方给出的集成部署，除了 documentserver，还配套 PostgreSQL、RabbitMQ、Redis，用 docker-compose 编排。HTTPS 配置还是在 documentserver 容器上做，也可以通过外层网关统一做。
• Debian/RPM 包安装：直接装在 Linux 系统上，配置文件和日志都在/etc/onlyoffice/、/var/log/onlyoffice/下。HTTPS 可以直接改服务自带的 Nginx 配置。
• K8s / 云原生环境：通过 Helm Chart 部署，HTTP 层一般由 Ingress 统一终结 TLS，文档服务器本身跑 HTTP。

我这里遇到的 90% 场景都是前两种，Docker 部署占比最大。下文会重点覆盖 Nginx 反向代理和 Docker 容器内启 HTTPS 两种路径，这两种路径覆盖了绝大多数自建 OnlyOffice 的情况。

2.2 证书怎么选：Let's Encrypt、自签名还是商业证书

HTTPS 的核心是一张 TLS 证书。选错证书，后面全是坑。

这里要特别提醒国内做自建服务的同学：Let's Encrypt 目前基本不签发纯 IP 地址的证书，你得有一个真实域名。域名解析到服务器公网 IP，80 或 443 端口能访问，才能完成申请。如果只有 IP 没有域名，那就只能自签名或者买支持 IP 的商业证书，体验都很折腾。我见过太多人在这个环节卡住，最后不得不先去注册域名。

另外，自签名证书不是“自己签一张就行”这么简单。你生成证书后，所有访问这个服务的浏览器、手机、别的主机，都要手动把证书或对应 CA 加入信任列表。OnlyOffice 很多情况下是被 iframe 嵌到别的系统里，如果嵌入页是公网环境，用户端根本没法在浏览器里点“继续访问”，编辑器照样用不了。所以自签名证书我只建议内网小范围测试用。

2.3 域名和端口规划，能省下后面大把的调错时间

这部分很少有人细讲，但真的很关键。OnlyOffice 在上报回调地址时，会用它自己感知到的请求 Host 和协议来拼接回调 URL。如果你用 IP 访问、用非标准端口访问，或者反代时没有把协议透传，生成的连接地址就是http://192.168.x.x:8088，后面第三方系统可能就回调不到，表现为“文档保存失败”“打开文档后无法同步”。

我的建议是：

• 给 OnlyOffice 单独分配一个子域名，比如office.example.com，不要和主站混在同一条路径下。独立子域名做证书、做反代、做隔离都方便。
• 端口尽量用标准 443。用非标端口也能做，但像 Portal、企业微信应用、钉钉 H5 等很多平台，打开页面时对非标准端口的兼容不太好。
• 80 端口要保留并做 301 跳转到 HTTPS。一是用户体验，二是 certbot 签发证书时经常需要走 HTTP 校验。
• 如果 OnlyOffice 在一个 Docker 网络里，要保证文档服务器对外端口固定，不能每次重启都随机变。Docker 的-p 443:443这种映射就够。

3. Nginx 反向代理方案：最省心也最灵活的配置路径

3.1 为什么我不把 SSL 直接怼进 OnlyOffice 容器

先说我个人的实践结论：除非是单机临时环境，否则我首选 Nginx 反向代理终结 TLS，而不是在 OnlyOffice 容器里直接启动 HTTPS。

原因有三点。第一，证书要集中管理。公司里往往不止 OnlyOffice 一个服务，Nginx 可能已经反代了 Wiki、网盘、API 网关等多个服务，证书统一放在 Nginx 层，到期续签、更换都只需要在一处操作。第二，OnlyOffice 的容器更新频率不低，每次升级镜像时，如果证书是挂在容器内部的，迁移成本就高；而证书在宿主机/反代层，升级容器几乎无感。第三，反向代理层可以顺手做安全控制、限流、日志审计，如果 OnlyOffice 后面要接多个系统，网关模式更灵活。

当然，如果你只是临时在内网部署一台机器，不想额外维护 Nginx，第四章的容器内 HTTPS 方案也可以，但先看完这章再决定。

3.2 Nginx 完整配置：一个 Server 块解决 80% 问题

假设 OnlyOffice 文档服务器在宿主机127.0.0.1:7000监听（Docker 映射出来的端口，取决于你的实际配置），证书已通过 certbot 生成在/etc/letsencrypt/live/office.example.com/。完整的 Nginx 配置如下：

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; client_max_body_size 1024m; location / { proxy_pass http://127.0.0.1:7000; 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 X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_connect_timeout 60s; proxy_read_timeout 60s; proxy_send_timeout 60s; } }

这段配置里真正管用的核心是两块：ssl_certificate那一组是证书；proxy_set_header那一组是让后端 OnlyOffice 感知到真实请求协议和域名。很多配置 HTTPS 后依旧出现回调地址错误的，基本就是这一组头没写全。

3.3 这些请求头参数为什么不能乱砍

proxy_set_header不是照着抄就完事的，建议理解每个参数的作用。

• Host $host：把浏览器访问的域名传给后端。OnlyOffice 内部生成的 URL 会依赖这个 Host，如果这里保留的是127.0.0.1:7000，文档里的链接就会全错。
• X-Forwarded-Proto $scheme：告诉后端“客户端实际是用 HTTPS 访问的”。OnlyOffice 看到这个头，才会在回调地址里生成https://而不是http://。这一项丢了，哪怕你地址栏是 HTTPS，它内部也觉得自己在跑 HTTP，很多莫名奇妙的保存失败就源于此。
• X-Forwarded-For和X-Real-IP：把真实客户端 IP 传递过去，方便 OnlyOffice 和上层日志分析定位安全问题。
• X-Forwarded-Host和X-Forwarded-Port：在反代非标准端口时可以修正回调地址。我们一般用标准 443 可以不写，但写上更稳。
• Upgrade和Connection "upgrade"：WebSocket 长连接升级协议，OnlyOffice 多人协作、文档实时保存都要靠它，后面第 5 章会展开讲。

另外，client_max_body_size 1024m千万别省略。默认值是 1m，用户上传一个大 PPTX 或 PDF 时，Nginx 会直接返回 413 Request Entity Too Large，表现就是“上传文件一直转圈，然后失败”。我遇到过一线上用户反馈，排查到最后就是这句话没加。

3.4 安全响应头：HSTS 可以加，CSP 不能乱加

在 Nginx 上顺手加安全响应头时，有两个经验要记牢。

HSTS（HTTP Strict Transport Security）可以加。加上之后，浏览器会强制以后都走 HTTPS 访问这个域名，防止被降级到 HTTP。配置如下：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

但要注意，一旦加了 includeSubDomains，这个域名下所有子域都必须支持 HTTPS，如果你还有别的子系统只在 HTTP 上跑，会被连带拦截。

CSP（Content Security Policy）就要特别小心了。OnlyOffice 编辑器前端会动态加载大量内联脚本、Web Worker、Blob 地址和 WebSocket 连接，如果你在反代层全局加一条比较严格的 CSP 规则，比如default-src 'self'，编辑器马上白屏，控制台全是 CSP 报错。我的做法是：不在 OnlyOffice 的域名上做 CSP 限制，或者只在集成方主站上做 CSP，单独给 office 子域名放行。如果确实要加，至少要给script-src加'unsafe-inline' 'unsafe-eval'，给connect-src加上wss:和当前域名，否则调试到怀疑人生。

4. Docker 容器直接启 HTTPS：不依赖外部反向代理的另一种选择

4.1 官方镜像通过环境变量启用 HTTPS

有些场景没有独立的 Nginx，或者就想一台 Docker 机器上把 OnlyOffice 跑起来。官方镜像本身内置了 Nginx 和 HTTPS 支持，通过环境变量就能开启 SSL。不同版本环境变量名可能有微调，但核心思路一致。

比较关键的几个环境变量是：

SSL_ENABLED=true SSL_CERTIFICATE_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.crt SSL_KEY_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.key

Docker 启动命令大致长这样：

docker run -d --name onlyoffice-document-server \ -p 443:443 \ -p 80:80 \ -v /srv/onlyoffice/certs:/var/www/onlyoffice/Data/certs \ -e SSL_ENABLED=true \ -e SSL_CERTIFICATE_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.crt \ -e SSL_KEY_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.key \ onlyoffice/documentserver

这里有个最容易踩的坑：开启 SSL 后，容器内的 Nginx 默认监听 443 端口，所以你映射端口时必须把宿主机的 443 映射到容器的 443，而不是像往常一样只映射 80。如果照着网上老教程写-p 8088:80，即使 SSL 变量配了也访问不对。另外建议把 80 也映射出来，方便做 HTTP 跳 HTTPS 和证书校验。

如果你是 docker-compose 部署，对应的服务片段可以写成：

services: onlyoffice: image: onlyoffice/documentserver container_name: onlyoffice-document-server ports: - "80:80" - "443:443" environment: - SSL_ENABLED=true - SSL_CERTIFICATE_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.crt - SSL_KEY_PATH=/var/www/onlyoffice/Data/certs/onlyoffice.key volumes: - /srv/onlyoffice/certs:/var/www/onlyoffice/Data/certs

4.2 自签名证书的生成和挂载

Docker 直接启 HTTPS 时，如果是测试环境，可以用自签名证书先跑通。生成证书的命令：

openssl req -x509 -nodes -newkey rsa:2048 \ -keyout onlyoffice.key \ -out onlyoffice.crt \ -days 365 \ -subj "/CN=office.example.com"

把生成的两个文件放到挂载目录/srv/onlyoffice/certs/下，文件名叫什么，环境变量就配置成什么。完成后重启容器：

docker restart onlyoffice-document-server

然后用浏览器访问https://你的地址，会看到证书不受信任的警告。这是因为自签名证书没有由受信任的 CA 签名，浏览器自然不认。

如果只是测试，点“高级”然后“继续前往”可以凑合用。但一旦你把这个地址嵌入到别的系统里，用户端是不能点“继续”的，因为 iframe 里根本没有那个确认按钮，整个页面会白屏或报错。所以再次强调，生产环境必须用真实证书。内网内部署如果一定要用自签方案，建议生成一个内部 CA，把 CA 证书通过域策略或 Apple Configurator 等工具批量分发到所有客户端，然后签发出服务端证书，体验会好很多。

4.3 直接容器内启 HTTPS 的限制

容器内直接启 HTTPS 并不是万能解。第一，证书续期比较麻烦。Let's Encrypt 证书每 90 天要续，如果挂在容器内，续期时要考虑重新加载容器配置，或者通过卷挂载让容器实时读到新证书。第二，升级容器时容易忘记备份证书目录，一旦镜像重建，证书可能丢掉。第三，If you 后面要加别的服务，或者要做负载均衡，容器内置的 Nginx 扩展性有限，不如独立反代层灵活。

我个人的判断是：一台服务器只跑 OnlyOffice 的情况下，容器内启 HTTPS 是可以接受的，尤其适合小团队内部知识库。但只要规划里还有“未来会在同一台机器上跑更多服务”，就老老实实加一层 Nginx 反代。

5. 集成第三方系统时最容易踩的 HTTPS 相关坑

5.1 回调地址协议不对：保存失败的“隐形杀手”

OnlyOffice 文档编辑完成后，是由前端通知后端调用文档服务器的回调接口，把编辑后的文件存回业务系统的。这个回调 URL 不是开发者在文档里写死的，而是 OnlyOffice 根据当前请求自动生成的。

开发者在 Spring Boot 项目里集成 OnlyOffice 时，经常会写类似下面这样的代码：

String documentServerUrl = "http://127.0.0.1:8088"; String configUrl = documentServerUrl + "/web-apps/apps/api/documents/api.js";

只要业务系统页面是 HTTPS，但这里的 documentServerUrl 还是 HTTP 的内网地址，编辑器就会被浏览器拦下来。即便不拦，OnlyOffice 向前端返回的配置里，也会把文档回调地址拼成http://127.0.0.1:8088/...，而业务服务器在 HTTPS 环境下无法正常回调这个内网地址，导致每次编辑完保存都失败，或者文档内容没持久化。

正确的做法是：集成代码里的 API 地址和业务页面保持同一个对外协议与域名。比如业务系统在https://oa.example.com，OnlyOffice 就配置为https://office.example.com，中间通过 Nginx 反代或网关转发。如果业务服务器和 OnlyOffice 在同一台内网机器，可以走内网 IP 通信，但对外暴露的回调地址一定要用 HTTPS 域名。

5.2 WebSocket 连不上：多人协作的光标为什么消失

OnlyOffice 的实时协作、光标位置同步、在线状态更新，依赖 WebSocket。当你用 Nginx 反代后，如果没有正确转发 Upgrade 头，浏览器建立 WebSocket 连接时就会失败。表现是：单机编辑看起来正常，一旦两个人同时打开同一文档，看不到对方光标，或者编辑内容很久不刷新。

Nginx 里必须显式写这两行：

proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

HTTPS 环境下，WebSocket 使用wss://协议，浏览器要求当前页面是 HTTPS，且 WebSocket 也是wss://，才允许建立连接。反代时X-Forwarded-Proto如果丢了，OnlyOffice 可能尝试用ws://去连接，浏览器又会拦截。所以这类问题排查时，优先看 Nginx 层有没有正确透传 Upgrade 头，再确认 X-Forwarded-Proto 是否保留。

5.3 Cookie 的 Secure 属性和 SameSite 在跨域集成里的迷惑行为

OnlyOffice 也是 Web 应用，会话管理依赖 Cookie。当你从 HTTPS 页面跨域集成 OnlyOffice 时，会遇到两类 Cookie 问题。

一类是Secure属性引起的。浏览器规定，设置了 Secure 属性的 Cookie 只能在 HTTPS 请求中发送。如果你的 OnlyOffice 反代配置好后，业务系统里登录状态时好时坏，很可能是因为 Cookie 被标了 Secure，但某些请求里地址还是 HTTP，比如回调地址、静态资源地址没有统一。排查方法：浏览器开发者工具里看 cookie 的 Secure 列，再对比网络请求里实际使用的协议。

另一类是SameSite。如果业务系统主站和 OnlyOffice 是不同域名，属于跨站场景。正常情况下跨站请求需要SameSite=None; Secure，不过移动端 Safari 和桌面端 Safari 对 SameSite 的处理又略有差异。我的经验是：能用同域尽量同域。比如把 OnlyOffice 反代到主站同一个域名下，像https://oa.example.com/onlyoffice/，省掉大量跨域 Cookie 摩擦。做不到同域，再考虑跨域方案，并且要统一调试 Cookie 的 Secure、SameSite 属性。

5.4 自签名证书下 JWT 链路一起抽风

OnlyOffice 从版本 7.2 开始，官方推荐启用 JWT 验证，防止文档服务器被未授权调用。配置好 HTTPS 后，很多人会遇到另一个报错：打开文档提示“无法下载文件”或 “Validation failed”。

先检查 JWT 是否配置一致。业务系统集成时，OnlyOffice 的 JWT Secret 要在文档服务器和业务系统两端配置成同一个值。比如 Docker 部署时加了：

-e JWT_ENABLED=true \ -e JWT_SECRET=my-super-secret-key \

那么 Spring Boot 集成代码里也要用同一个 secret 生成 token。如果两边不一致，或者只在文档服务器开了 JWT 而业务系统没带 token，就会出现上面那些诡异报错。这个错误表象是“下载文件失败”，但根因和 HTTPS 无关，纯粹是鉴权链路断了。

这里也提醒一下：有人为了省事，会去修改 OnlyOffice 前端连接器脚本绕过 JWT 校验。我强烈不建议这么干。一来升级容器后你就得重新改，二来文档服务器暴露在没有鉴权的公网上，等于谁拿到地址都能随意上传下载文件，安全风险极高。正确做法是两端把 JWT 配置对齐，让鉴权闭环。

5.5 一条命令实际验证证书与 TLS 链路

配置完成、遇到问题的第一步，永远是用命令把证书链和 TLS 握手状态看一遍。

测 HTTPS 是否通：

curl -vI https://office.example.com/

看有没有 SSL 握手成功、证书有效期、响应头是否正确。如果返回SSL certificate problem，说明证书链或主机名不匹配。

看证书详细信息和签发链：

openssl s_client -connect office.example.com:443 -servername office.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

重点看三行：subject 里的 CN 是否等于你要访问的域名，issuer 是不是受信任 CA，dates 里的有效期是否覆盖当前时间。如果是自签名证书，issuer 不会是常见的 CA 名称，而会是你自己或内部 CA 的 CN。

再看 443 端口是否真的开放、防火墙有没有拦：

telnet office.example.com 443

不通的话，先去查云安全组、宿主机防火墙和 Docker 端口映射，很多时候 HTTPS 配好了但端口没放出来，一切白搭。

6. 验证与日常维护：配置好 SSL 只是开始

6.1 配置完成后必须做一轮“文档生命周期”测试

很多同学把 HTTPS 配置好后，访问一下欢迎页、看到一个上锁图标就收工了。这是远远不够的。我建议每次配置或升级完，都按用户真实操作路径做一遍完整测试：

1. 访问https://office.example.com/healthcheck，返回true。
2. 打开欢迎页，确认静态资源和 API 脚本正常加载。
3. 上传一个带图片、表格的 Word 文件，在线打开，确认编辑器能渲染。
4. 修改一段文字，保存，等待“已上传”或“已存储”提示，再关闭页面重新打开，确认修改真的持久化了。
5. 用两个浏览器同时打开同一个文档，观察光标和内容是否实时同步，确认 WebSocket 正常。
6. 用浏览器开发者工具 Network 面板过滤ws，确认连接是wss://。
7. 如果是多语言环境，切一下界面语言，确认切换正常，没有因为资源加载失败导致部分语言显示不全。

这一套流程走下来，比只看true靠谱得多。

6.2 证书 90 天到期不可怕，自动续期要准备好

Let's Encrypt 证书默认有效期 90 天，很多人担心麻烦，其实自动化很容易。用 certbot 签发的证书，先手动测试一遍续期：

sudo certbot renew --dry-run

没问题后，配置自动任务。最简单的方式是 crontab：

0 3 * * * /usr/bin/certbot renew --deploy-hook "systemctl reload nginx"

--deploy-hook的意思是续期成功后才执行，把 Nginx reload 一下让新证书生效。如果你用的是 Docker 反代但 Nginx 跑在宿主机上，不需要改动容器；如果你在宿主机上用docker exec重启 Nginx，就改成对应命令。

如果用的是 Docker 容器内挂证书的方案，续期后可能要重启或 reload 容器内部的 Nginx，我在第 4 章提过这个痛点。生产环境如果一定要容器内挂证书，建议观察续期后的证书变更是否被容器内 Nginx 感知，不行就在续期脚本里加一句docker exec onlyoffice-document-server nginx -s reload。

6.3 走向更大的架构：TLS 终结层该放在哪里

当你的 OnlyOffice 不止一个节点，或者公司已经有统一的入口网关时，我建议把 TLS 终结层放在最前面，而不是每台机器上都放一份证书。

Kubernetes 环境里，Ingress 上配置证书是最常规的做法，Pod 内只跑 HTTP，Ingress 负责 TLS 卸载。云上部署时，SLB 或负载均衡器自带证书管理，直接把证书绑定到监听器，后端 ECS 不用开 443。这种模式的好处是证书集中管理、节点弹性伸缩时不用关心证书文件，而且可以先通过负载均衡做健康检查，把不健康的 OnlyOffice 节点自动摘除。

如果你只有一台机器，那 Nginx 反代层已经够用。再往后优化，可以顺手把 HTTP/2 开起来（Nginx 配置里那句listen 443 ssl http2就是），静态资源并行加载更快，多人编辑时体验会好一截。还可以尝试启用 OCSP stapling，减少用户浏览器证书验证的网络往返，不过这不是必须项。

我现在的习惯是：每次新部署 OnlyOffice，第一件事就是先把域名和 HTTPS 跑通，再往上叠加业务集成逻辑。顺序一旦反了，后面各种调用地址、证书信任、WebSocket 连不上的问题会一股脑涌上来，排查成本远超一开始就把 HTTPS 配好。这个顺序，建议你也试试。