群晖Docker部署OnlyOffice：中文字体、字号与HTTPS配置实战

1. 为什么要在群里晖里折腾 OnlyOffice

先说说我为什么最终选择在群晖里部署 OnlyOffice 文档服务器。其实一开始我用的就是群晖自带的 Synology Office，平时自己写写表格、改改文档还凑合，但一旦牵扯到多人协作、在线预览 Office 格式文件，问题就来了。首先是格式兼容性，稍微复杂一点的 Word 文档，带个批注、带个修订记录、嵌套几个文本框，Synology Office 打开后排版就乱了。其次是协同编辑，同事发来一个几十页的标书，我改完他再改，来回传文件传到崩溃。

后来我调研了一圈，可选的方案无非是 Collabora Online、OnlyOffice、或者干脆把 NextCloud 和 OnlyOffice 组合起来。实测下来，OnlyOffice 对 Microsoft Office 格式的还原度是最好的，而且社区版免费、开源、功能也够用，文档权限控制、协同编辑、在线预览都支持得很好。最关键的是，它可以直接和群晖里的共享文件夹对接，或者和已有的 WebDAV、Nextcloud 实例打通，很适合家庭 NAS 和个人小团队使用。

不过 OnlyOffice 这个坑也不少。最典型的就是中文字体缺失，装完以后打开中文文档，要么满屏方块，要么字体被替换成系统默认的英文字体，格式直接乱掉。另一个就是字号问题，中文里常用的“初号、小一、五号、小五”这些中文字号，默认的字体配置里根本没有，导致文档里的字号设置全部错乱。再有就是只支持 HTTP 访问时，浏览器会提示不安全，而且内网穿透或者外网访问时，HTTP 明文传输也让人不放心。

所以这篇文章我打算完整记录一下，如何在群晖 NAS 上用 Docker 方式部署 OnlyOffice Document Server，重点解决中文字体缺失、中文字号错乱、HTTPS 访问这三个老大难问题。整个流程我在 DSM 7.2 环境下验证过，黑群晖同样适用，底层命令和思路是完全一致的。

2. 部署前的准备工作与容器选型

2.1 群晖 Docker 环境检查

动手之前，先把环境准备好。群晖从 DSM 7.0 开始，Container Manager 已经替代了原来笨重的 Docker 套件，界面更干净，但底层还是我们熟悉的 Docker 引擎。如果你的群晖还是老版本，装的是 Docker 套件也没关系，命令基本通用。

打开群晖的“套件中心”，确认 Container Manager 已经安装并处于运行状态。然后打开终端机功能，这一步很重要，因为后续很多操作通过 SSH 来执行会比在图形界面里点来点去高效得多。在“控制面板 - 终端机和 SNMP”里勾选“启用 SSH 功能”，端口保持默认的 22 即可。

用终端软件连上群晖：我习惯用 Xshell，如果你在本地 Windows 环境没有现成的 SSH 客户端，用 Windows 11 自带的 Terminal 也可以。连接时需要注意，群晖的默认账号是 admin 或者你自己创建的账户，但是要用 sudo 切换 root 权限才能执行 Docker 命令。

提示：群晖很多套件安装路径在 /volume1，Docker 相关的数据卷建议统一放到 /volume1/docker/onlyoffice 下面，方便备份和权限管理。

2.2 镜像选择：为什么不用 all-in-one 镜像

网上很多教程会直接让你拉取 onlyoffice/documentserver 这个官方镜像，确实省事，但实际使用中我发现有几个问题：

• 官方镜像体积很大，第一次拉取可能要花十几分钟，如果网络不稳定，很容易拉取失败。
• 内部集成了 PostgreSQL、RabbitMQ 等组件，一旦容器异常，日志排查起来非常痛苦。
• 升级时往往要连带数据库一起迁移，操作风险高。

所以我更推荐走拆分部署的路线：用一个轻量的 OnlyOffice Document Server 容器，搭配一个外部 PostgreSQL 数据库，或者干脆用 SQLite 模式先跑起来。对于小规模使用场景，SQLite 就够用，性能压力也不大，重点是容器更轻、升级更方便。如果后续用户多了、并发上来了，再迁到 PostgreSQL 也来得及。

我在实际部署中更倾向于用 Docker Compose 来编排，这样所有配置都固化在一个 yml 文件里，后续重建容器、迁移主机都非常方便。下面我就用 Docker Compose 的方式来演示。

2.3 目录规划

在 /volume1/docker/onlyoffice 下建立如下目录结构：

/volume1/docker/onlyoffice/ ├── data/ # 存放配置、证书、字体等 │ ├── certs/ # 存放 SSL 证书 │ └── fonts/ # 存放自定义中文字体 ├── logs/ # 容器日志输出目录 └── docker-compose.yml # 编排文件

群晖的 File Station 可以直接创建文件夹，也可以 SSH 进去用 mkdir -p 命令创建，我习惯用 SSH，一步到位：

sudo mkdir -p /volume1/docker/onlyoffice/{data/certs,data/fonts,logs}

3. 解决中文字体缺失问题

3.1 字体问题到底出在哪里

OnlyOffice 官方镜像默认只带了一些基础西文字体，像 Arial、Times New Roman 这类。它们没有包含中文字体，比如宋体、黑体、微软雅黑。这直接导致文档渲染时，所有中文字符都找不到对应字形，最终显示成一个个方块，术语叫 tofu（豆腐块）。

另外还有一层隐含的问题：即使你手动往系统里塞了中文字体，如果字体名称和文档里的字体名称对不上，OnlyOffice 依然会用默认字体渲染。比如 Word 文档里写的是“宋体”，但系统里只有名为 SimSun 的字体，虽然 SimSun 就是宋体，但名称对不上，渲染引擎就不认。所以我不仅要把字体文件放进去，还要确保字体名称映射也是正确的。

3.2 中文字体包的获取与处理

我整理了一套比较实用的中文字体清单，覆盖了日常办公的绝大多数场景：

字体文件从哪里来？最简单的方式是从自己的 Windows 系统里复制。Windows 的字体目录在 C:\Windows\Fonts，你可以在资源管理器里直接搜索 simsun.ttc、simhei.ttf 等文件名，拷贝出来。需要注意，ttc 是字体集合文件，里面可能包含多个字重，但 OnlyOffice 通常能正确识别。如果手头没有 Windows 系统，也可以去一些开源字体仓库下载思源黑体、思源宋体，这些字体本身就是开源授权的，用在服务器上更放心。

拿到字体文件之后，重命名成容易识别的英文名，然后上传到群晖的 /volume1/docker/onlyoffice/data/fonts 目录下。用 WinSCP 或者群晖 File Station 直接拖拽上传都可以。

3.3 字体安装的两种方案

第一种方案，在 Docker 启动时通过挂载卷覆盖字体目录：

volumes: - /volume1/docker/onlyoffice/data/fonts:/usr/share/fonts/truetype/custom:ro

然后把字体文件放入宿主机的 fonts 目录，容器内 /usr/share/fonts/truetype/custom 目录下就会出现这些字体，重启后 OnlyOffice 会自动扫描该目录。

这里需要留意一点，OnlyOffice 的字体扫描服务是 document server 里的一个独立进程，它启动时会调用 fontconfig 来刷新字体缓存。如果挂载完字体后没生效，需要进容器手动执行一下命令：

docker exec -it onlyoffice-document-server bash fc-cache -fv

第二种方案，直接在容器里拷贝字体，这种方式适合临时验证，但容器重建后字体会丢失，不建议作为长期方案。如果是临时想测试某个字体效果，可以这样：

docker cp /volume1/docker/onlyoffice/data/fonts/simsun.ttc onlyoffice-document-server:/usr/share/fonts/truetype/custom/ docker exec -it onlyoffice-document-server fc-cache -fv

3.4 字体名称映射的额外配置

字体文件放进去了，字也显示出来了，但还有一个潜藏的问题，很多文档里写的字体名是“微软雅黑”，而系统字体名可能是“Microsoft YaHei”。OnlyOffice 内部有一套字体名称映射表，但并不是所有中文字体都覆盖到了。

遇到这种情况，可以修改 /etc/fonts/fonts.conf 或 /etc/fonts/conf.d/ 下的配置文件，增加别名。一个比较常改的方式是在容器里创建一个自定义的字体别名文件：

vi /etc/fonts/local.conf

写入如下内容：

<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias> <family>微软雅黑</family> <prefer><family>Microsoft YaHei</family></prefer> </alias> <alias> <family>宋体</family> <prefer><family>SimSun</family></prefer> </alias> <alias> <family>黑体</family> <prefer><family>SimHei</family></prefer> </alias> </fontconfig>

保存后执行 fc-cache -fv 刷新。但并不建议每次都手动进容器改，因为容器重建后内容会恢复原样。更可靠的做法是把 local.conf 一起挂载到容器里，或者做成自定义 Docker 镜像。

4. 中文字号问题的处理细节

4.1 中文字号混乱的原因

OnlyOffice 默认的字号体系遵循西文排版习惯，也就是用磅值（pt）来定义字号。而中文排版里，我们习惯用中文字号来描述，初号、小初、一号、小一、二号、小二，一直到八号。这两者之间虽然有对应关系，但 OnlyOffice 的编辑器界面里，默认字号下拉框通常没有中文字号选项。

于是会出现一个很尴尬的情况：在 Word 里排好的文档，正文是小四号，到了 OnlyOffice 里可能显示成 12pt，虽然数值上是等价的，但下拉框显示不同，使用者会本能地觉得不对劲。更麻烦的是，如果文档的默认语言设置不对，字号下拉框可能显示空白或乱码。

4.2 字号与磅值的对应关系

先整理一下常见中文字号和磅值的对应表，方便后续配置：

OnlyOffice 的界面在绝大多数情况下是按磅值来识别字号的，比如 42pt 在下拉框里会显示成“初号”，但前提是文档的语言环境被正确识别为中文，并且界面本身的本地化翻译文件完整。

4.3 中文界面与地域设置

要让 OnlyOffice 正确显示中文字号，需要确保容器的语言环境设置为中文，并且 OnlyOffice 的本地化资源包含中文界面翻译。

在 docker-compose.yml 里，可以通过环境变量来控制区域：

environment: - LANG=zh_CN.UTF-8 - LANGUAGE=zh_CN:zh - LC_ALL=zh_CN.UTF-8

但需要注意，OnlyOffice 的官方镜像底层系统是 Debian，默认可能没有安装 zh_CN.UTF-8 语言包。如果直接设置 LANG=zh_CN.UTF-8，有时候会报 locale 不存在的错误。

处理方法是在启动容器后，进入容器安装语言包并生成本地化文件：

apt-get update apt-get install -y locales sed -i '/zh_CN.UTF-8/s/^# //g' /etc/locale.gen locale-gen

不过容器重建后这些设置又会丢失。更优雅的方案是自定义一个 Dockerfile，在官方镜像基础上把中文字体、语言环境、字库配置都固化进去。虽然多了一步构建，但一劳永逸。

下面给出一个简单的 Dockerfile 示例：

FROM onlyoffice/documentserver:latest RUN apt-get update && apt-get install -y locales fonts-wqy-zenhei fonts-wqy-microhei \ && sed -i '/zh_CN.UTF-8/s/^# //g' /etc/locale.gen \ && locale-gen \ && apt-get clean ENV LANG=zh_CN.UTF-8 \ LANGUAGE=zh_CN:zh \ LC_ALL=zh_CN.UTF-8 COPY ./data/fonts/ /usr/share/fonts/truetype/custom/ RUN fc-cache -fv

然后构建镜像：

sudo docker build -t onlyoffice-ds-cn:latest .

这样反复重建容器也不需要重新配字体和语言环境了。

5. HTTPS 访问的配置与实现

5.1 为什么必须开 HTTPS

OnlyOffice 的在线编辑器涉及文档内容的实时保存和协同编辑，文档数据在浏览器和服务器之间来回传输。如果走 HTTP，文档内容相当于明文在网络里裸奔，尤其是在内网穿透、异地访问的情况下，中间任何一个环节都有可能被截获。

另外还有一个非常现实的问题，现在很多浏览器对非 HTTPS 页面的限制越来越严格，比如 Clipboard 剪贴板访问、麦克风权限、摄像头权限等，在非安全上下文里都被禁用。OnlyOffice 的协同编辑功能在某些浏览器里需要用到这些 API，不开 HTTPS 就会出现功能异常。

还有一个容易被忽视的点：OnlyOffice 在 https 页面里被 iframe 嵌入时，浏览器会校验页面协议一致性。如果父页面是 https，嵌进来的 OnlyOffice 却走 http，会被直接拦截，白屏。所以一旦上级应用（比如 Nextcloud、群晖 Web Station）开了 HTTPS，OnlyOffice 也必须跟着上 HTTPS。

5.2 证书准备的三种方式

第一种方式，群晖自带的证书。如果你已经通过群晖的“控制面板 - 安全性 - 证书”申请或者导入了域名证书，可以在 Docker 容器里直接引用群晖的证书文件。

群晖证书默认存储在 /usr/syno/etc/certificate/ 目录下，不同的服务对应不同的子目录。其中 /usr/syno/etc/certificate/system/default/ 保存的是默认证书，包含 cert.pem、chain.pem、privkey.pem 三个文件。把这三个文件复制到 /volume1/docker/onlyoffice/data/certs/ 目录下就能直接挂载使用。

第二种方式，从域名服务商申请免费证书。如果你用的是阿里云、腾讯云这些，每年可以申请免费的 DV 证书，有效期通常是一年。下载 Nginx 格式的证书，其实就是 pem 格式的证书文件和 key 私钥文件，直接丢到 certs 目录。

第三种方式，acme.sh 自动续期。如果域名托管在 Cloudflare 或者 DNSPod，可以在群晖里装 acme.sh 来自动签发和续期 Let's Encrypt 证书。这个方案一劳永逸，证书快到期时自动续签，适合长期稳定运行的服务。我在实际部署中最终采用的就是这种方式，配合群晖的定时任务，每月自动检查一次证书有效期。

5.3 docker-compose 中配置 HTTPS

OnlyOffice 官方文档服务器镜像本身内置了 Nginx，所以可以直接通过环境变量开启 HTTPS。下面是我最终使用的 docker-compose.yml 配置：

version: "3" services: onlyoffice-document-server: image: onlyoffice-ds-cn:latest container_name: onlyoffice-document-server restart: always ports: - "443:443" environment: - LANG=zh_CN.UTF-8 - LANGUAGE=zh_CN:zh - LC_ALL=zh_CN.UTF-8 - JWT_ENABLED=true - JWT_SECRET=your-secret-key-here - JWT_HEADER=Authorization - TLS_CERT_PATH=/etc/onlyoffice/documentserver/certs/tls/cert.pem - TLS_KEY_PATH=/etc/onlyoffice/documentserver/certs/tls/privkey.pem - TLS_CA_CERT_PATH=/etc/onlyoffice/documentserver/certs/tls/chain.pem volumes: - /volume1/docker/onlyoffice/data/certs:/etc/onlyoffice/documentserver/certs/tls:ro - /volume1/docker/onlyoffice/data/fonts:/usr/share/fonts/truetype/custom:ro - /volume1/docker/onlyoffice/logs:/var/log/onlyoffice

需要注意，JWT_SECRET 一定要设置一个足够复杂的密钥，这是 OnlyOffice 用来校验 API 请求来源的，如果不设置或者设置得太简单，外部请求有可能绕过鉴权直接操作文档服务。生成密钥可以用以下命令：

openssl rand -base64 32

5.4 反向代理还是直接端口映射

上面用的方式是让容器直接监听 443 端口，适合 OnlyOffice 独占一个域名的情况。但我自己实际使用的时候，群晖上还跑了其他服务，如果每个服务都占一个 443 端口，肯定不行，所以更推荐用反向代理。

群晖自带的“登录门户 - 高级 - 反向代理”可以很方便地配置域名转发规则。比如：

这里有个细节：OnlyOffice 容器内部默认走 HTTPS 的话，反向代理目标端口应该是 443，但如果内部走 HTTP，反向代理目标端口就是 80。实际部署中我更倾向于让容器内部跑 HTTP，由群晖的反向代理统一接管 HTTPS，证书也都集中在群晖系统里管理，这样更符合群晖的使用习惯。

对应的 docker-compose.yml 可以简化为：

ports: - "8000:80"

然后环境变量里不需要再设置 TLS 相关的参数。反向代理负责把外部 HTTPS 请求转发到容器的 80 端口。

5.5 外网访问的防火墙策略

如果 OnlyOffice 需要对外提供服务，只处理容器端口还不够，群晖的防火墙规则必须同步放行。在“控制面板 - 安全性 - 防火墙”里，添加端口转发规则，把 443 或者自定义的映射端口放行。如果是用路由器拨号上网，还必须在路由器上做端口映射，把公网端口映射到群晖的内网 IP 和端口。

这里踩过一个坑：群晖防火墙默认的规则顺序很重要。如果你同时配置了“允许所有”和“拒绝特定端口”的规则，群晖是按照规则列表从上到下顺序匹配的，一旦命中了前面的允许规则，后面的拒绝规则就不会生效。所以最好把拒绝规则放在最前面。

6. 部署过程中遇到的典型问题与排查实录

6.1 文档安全令牌格式不正确

这个报错应该是 OnlyOffice 部署里遇到最多的一个问题了。现象是你通过自己的 Web 应用调用 OnlyOffice 编辑器，页面能正常打开，但一旦执行保存、协同编辑等操作，编辑器弹出“文档安全令牌的格式不正确”的提示。

根本原因在于 OnlyOffice 的 JWT 鉴权机制。当你设置 JWT_ENABLED=true 后，所有对 OnlyOffice API 的请求都必须携带合法的 JWT token，而且 OnlyOffice 要求请求的 body 里的 key、url 等参数也一并参与签名计算。如果你的后端在生成 token 时没有把文档的 downloadUrl、callbackUrl 等参数计算进去，或者算法不匹配，就会报这个错。

排查思路是这样的：

# 1. 先确认 JWT 密钥是否一致 # 后端集成 OnlyOffice 时，要确认配置的 secret 和 OnlyOffice 容器里的 JWT_SECRET 完全相同 # 2. 确认 token 生成算法是 HS256，很多语言的 JWT 库默认是 HS256，但也有默认 HS512 的，需要显式指定 # 3. 如果通过 Nginx 反代，确认请求头 Authorization 没有被剥离 # 有些反代配置会过滤掉 Authorization 头，导致 OnlyOffice 校验 token 时取不到值

这个报错在 Spring Boot 集成 OnlyOffice 时也特别常见。我在另一篇文章里详细写过 Spring Boot 如何正确生成 OnlyOffice 的 JWT token，核心逻辑是：把 body 里的 JSON 参数作为 JWT 的 payload，使用 secret 进行签名，然后把签名后的字符串作为 Authorization 请求头传过去。注意 JWT 库生成 token 时，报文中不能额外增加 iat、exp 等默认声明，否则验签时会因为 payload 不一致而失败。

6.2 编辑完再次打开提示“文件版本已更改,该页面将被重新加载”

这个问题的本质是 OnlyOffice 的协同编辑机制中，文档状态发生了冲突。常见触发场景是：你在一个浏览器标签页里打开文档编辑，又在另一个标签页用同样的文档 key 重新打开，此时 OnlyOffice 检测到同一文档有两个编辑会话，会强制刷新其中一个页面。

还有一种情况是回调地址配置不对。OnlyOffice 在文档保存、用户离开等时机，会向后端发送回调请求。如果回调地址访问不通，或者回调数据校验失败，OnlyOffice 会误判文档状态，然后在下一次打开时提示文件版本已更改。

排查方法：

• 查看 OnlyOffice 容器的 Nginx 日志和 DocumentServer 日志，看有没有关于保存回调的报错。
• 确认回调 URL 在 OnlyOffice 容器内能够访问。很多人卡在这一步：OnlyOffice 容器里的网络和宿主机网络是隔离的，如果回调地址写的是 localhost，OnlyOffice 容器内部请求 localhost 访问到的是它自己，而不是你的后端，自然就回调失败了。
• 多个浏览器标签页测试时，记得每个标签页用不同的文档 key，或者直接关闭其他标签页再重新打开。

6.3 中文字体显示为方框

字体显示为方框，核心还是字体文件没有生效。按我上面的方法挂载字体之后，如果依然显示方框，按以下顺序排查：

# 1. 查看容器内字体目录挂载是否成功 docker exec -it onlyoffice-document-server ls -la /usr/share/fonts/truetype/custom/ # 2. 检查字体是否被系统识别 docker exec -it onlyoffice-document-server fc-list | grep -i "simsun\|yahei\|simhei" # 3. 刷新字体缓存 docker exec -it onlyoffice-document-server fc-cache -fv # 4. 重启容器 sudo docker restart onlyoffice-document-server

还有一点，OnlyOffice 文档服务器启动的时候会缓存字体列表，修改字体文件之后必须重启容器才能生效。不要改了字体文件就直接打开编辑器页面刷新，那样大概率还是旧的字体缓存。另外如果用了多个 Document Server 实例做负载均衡，每台机器上的字体必须保持完全一致，否则同一份文档在不同服务器上渲染出来的效果可能不一样。

6.4 群晖重启后 OnlyOffice 无法访问

这是个很典型的容器依赖问题。Docker 容器设置了 restart: always 之后，群晖开机时容器会自动启动，但 OnlyOffice 容器内部的后端服务依赖于 PostgreSQL、RabbitMQ 等外部组件。如果容器启动时数据库还没就绪，OnlyOffice 就会一直处于初始化失败的状态。

如果你用了外部 PostgreSQL，建议在 docker-compose.yml 里给容器加上健康检查和依赖关系：

services: onlyoffice-document-server: depends_on: postgres: condition: service_healthy

PostgreSQL 服务定义里的健康检查可以这样写：

healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"] interval: 10s timeout: 5s retries: 5

如果你用的是 SQLite 模式，出现这种情况的概率会低很多，但还是建议容器启动后等待几秒再访问页面。

6.5 群晖没有公网 IP 时的外网访问

很多人的群晖是放在家里的，运营商没有分配公网 IP，这时候想从外面访问 OnlyOffice，就需要内网穿透方案。常见的选择是 frp、ZeroTier、Tailscale。

我个人的建议是优先考虑组网方案，比如 Tailscale 或者 ZeroTier。这样在手机和笔记本上安装对应的客户端，就可以像在内网一样直接访问群晖的 OnlyOffice 服务，不需要在公网暴露端口，安全性和稳定性都好很多。

如果一定要通过 frp 这类工具把 443 端口暴露到公网，记得在 frps 和 frpc 的配置里都开启 TLS 加密，否则即使 OnlyOffice 自己配了 HTTPS，frp 隧道中间那段仍然是明文传输，HTTPS 就形同虚设了。

7. 前端集成与域名映射的几个实用技巧

7.1 用域名还是 IP 访问

OnlyOffice 在前端集成时，需要在配置对象里指定 documentServerUrl，也就是 OnlyOffice 服务器的地址。这里强烈建议直接使用域名，而不是 IP。原因在于 OnlyOffice 的协同编辑功能会通过 WebSocket 和浏览器建立长连接，如果你的域名解析指向了内网 IP，但浏览器实际访问时走的可能是公网 IP，WebSocket 的跨域校验很容易出问题。

域名解析可以配置成 split DNS，也就是内网和外网解析到不同的地址，但保持同一个域名。这个需求在群晖的 DDNS 功能里可以直接配置，把群晖的 DDNS 域名解析到内网地址，或者在内网 DNS 服务器里加一条解析记录，优先指向群晖的内网 IP。

7.2 iframe 嵌入时的跨域设置

OnlyOffice 的前端是默认被设计成通过 iframe 嵌入到父页面里的。如果你把 OnlyOffice 的编辑器页面嵌入到自己开发的系统里，需要在 OnlyOffice 的 default.json 配置里设置跨域白名单。

打开容器内的配置文件：

docker exec -it onlyoffice-document-server cat /etc/onlyoffice/documentserver/default.json

找到类似这样的部分：

"server": { "token": { "enable": true, "secret": "your-secret-key" } }

但很多跨域问题其实不是出在 OnlyOffice 服务端，而是父页面没有正确设置 iframe 的权限属性。建议在 iframe 标签里加上：

<iframe src="https://office.example.com/web-apps/apps/api/documents/api.js" allow="clipboard-read; clipboard-write; fullscreen" style="width:100%; height:100%; border:0;"> </iframe>

允许 clipboard 权限很重要，否则复制粘贴功能在某些浏览器里会失效。

7.3 集成到群晖 Web Station 或 Nextcloud

如果你只是想在群晖里给文件管理器加一个在线预览功能，最简单的方案是把 OnlyOffice 作为文件预览器嵌入到 Web Station 里。群晖 Web Station 支持虚拟主机，你可以在同一个站点下挂载一个子路径，指向 OnlyOffice 的反向代理规则。

如果你用的是 Nextcloud，可以直接安装 OnlyOffice 官方连接器应用，然后在 Nextcloud 设置里填写 OnlyOffice 服务器的地址和 JWT 密钥。连接器会自动处理文档 URL 的签名问题，不用自己写代码。这里最容易踩坑的还是 JWT 密钥不一致，安装完连接器后，务必在 Nextcloud 的 OnlyOffice 设置页面里填入和 OnlyOffice 容器相同的密钥。

7.4 群晖防火墙屏蔽境外 IP

如果你对外提供 OnlyOffice 服务，而只希望国内用户访问，可以考虑在群晖防火墙层面直接屏蔽境外 IP。群晖的防火墙支持地理位置规则，但默认规则库可能不够准确，更可靠的方式是定期从一些免费 IP 库下载国内 IP 段列表，然后在防火墙里添加“允许来源来自国内 IP 段”的规则，其他来源一律拒绝。

这个方案我在实际用下来效果不错，攻击日志数量明显减少。但要注意，动态 IP 库需要定期更新，如果过期了可能导致正常用户无法访问。我一般是每周日同步一次 IP 数据，然后重载防火墙规则。

8. 写在最后的运维心得

整套部署流程跑通之后，OnlyOffice 在群晖里运行得非常稳定，中文字体和字号问题解决后，文档渲染效果和本地 Office 基本没有肉眼可见的差别。我用了大半年，保存、协同编辑、版本历史这些核心功能都没有出过大毛病。唯一需要留意的就是容器升级，每次升级前，务必备份好 data 目录和 docker-compose.yml，然后对比一下新版本的配置项有没有改动。

内存方面，OnlyOffice 文档服务器是个内存大户，我的印象中默认配置下 4GB 内存的轻量云服务器能跑，但最好预留 2GB 以上的内存给容器。群晖如果内存不大，比如只有 2GB 的入门机型，建议不要在同一台设备上同时跑太多容器，否则 OnlyOffice 的渲染进程容易被系统杀掉。

最后分享一个小技巧：给 OnlyOffice 容器加上内存限制，防止极端情况下它把群晖的内存吃满。在 docker-compose.yml 里可以这样写：

deploy: resources: limits: memory: 4G

这样即使某个时刻并发编辑文档的用户很多，也不会影响群晖上其他服务。从踩坑到稳定运行，整个过程其实并不复杂，核心就三件事：字体放对位置、密钥保持一致、HTTPS 走对链路。把这三点做好，OnlyOffice 在群晖上就基本不会给你添乱了。