绵羊料理作为一个经常和 PDF 打交道的人，我其实被各种“PDF 编辑器”折磨了很多年。要么打开就弹广告，要么导出还带水印，要么想把扫描件文字识别出来却得开会员。后来我在 GitHub 上发现了一个叫 Stirling-PDF 的开源项目，亲自在 Windows 上部署完用了一段时间，确实有“相见恨晚”的感觉。它本质上就是一个自托管的 PDF 工具箱，部署好之后，你把文件传到网页里就能合并拆分、压缩转换、OCR 识别、加签加水印，功能非常全。更关键的是，它跑在你自己的电脑上，数据不出内网，没有在线工具那种隐私负担，局域网里的同事也能一起用。这篇文章就把完整的 Windows 部署过程、外部访问方案和一路上踩过的坑都写出来，给正准备入手的你做个参考。
1. 为什么在 Windows 上部署一个私人 PDF 工具箱
1.1 从一段被 PDF 工具折磨的经历说起
我最早处理 PDF 的方式，和大多数人差不多：搜一个“免费 PDF 在线转换”的网页，传上去，等待上传，再下载结果。直到有一次，我把一份带客户信息的合同扫描件传到一个在线识别网站，第二天就收到了精准的推销电话，从那以后我对在线工具就一直有戒心。后来我买了一台性能还不错的 Windows 台式机，平时就做做文件整理和数据处理，于是我开始琢磨：能不能在这台机器上自己搭一套 PDF 处理服务，所有转换动作都在本地完成，不用把文件传到别人的服务器上？Stirling-PDF 就是在这个背景下进入我视野的。
Stirling-PDF 是一个基于 Spring Boot 的开源项目，它的定位就是“PDF 处理瑞士军刀”。我在本地实际用下来，日常能想到的场景它基本都覆盖了：合并多个 PDF、按页拆分、压缩体积、把图片转成 PDF、把 PDF 转成 Word，这些是最基本的；高级一点的还有 OCR 文字识别、添加水印、插入页码、表单填写、数字签名、加密解密、元数据清理、页面裁剪和旋转。整个界面是网页形式，不需要安装客户端，用浏览器打开就能操作，对非技术同事也很友好。
相比买年费动辄几百块的商业软件，Stirling-PDF 免费且开源，代码托管在 GitHub 上，你可以自己审查逻辑，不放心的时候甚至可以断网使用。把它部署在 Windows 上，还有一层好处：Windows 桌面生态里有大量扫描、打印、Office 文档工具，文件在本地流转非常自然。无论是个人使用，还是放在一个小团队内部做集中式 PDF 处理，这个方案都够用。
1.2 Stirling-PDF 到底能干什么，和在线工具相比强在哪
我整理了 Stirling-PDF 里最常用的几类功能，你感受一下它的覆盖面：
- 文档操作：合并、拆分、旋转、裁剪、删除页面、重新排序、按大小或页码分拆。
- 内容处理：添加文本、图片水印，插入页码标题，添加页眉页脚，清理元数据。
- 转换能力：PDF 转图片、图片转 PDF、PDF 转 Word、Word 转 PDF、PDF 转 CSV，以及 HTML 转 PDF。
- 高级功能：OCR 文字识别、PDF 表单填写、页面签名、加密解锁、书签整理、颜色校正。
- 界面体验：多国语言支持（包括简体中文），拖拽上传，批量任务处理，操作记录自动保存。
这些功能如果是用在线工具来做，单次处理一个文件就够烦了，批量处理基本是付费专享。而 Stirling-PDF 是本地算力在处理，不会限速，也不会因为你一周处理几百个文件就逼你开会员。我实测把一个 50 页的 PDF 转成 Word，在普通台式机上也就几秒钟，速度比上传到云端再下载快非常多。
另外一个容易被忽略的点是隐私。很多行业的数据是不能传到外部服务的，比如合同、体检报告、企业内部规范文件。本地部署意味着整个处理链路只经过你的 Windows 机器，文件不会被第三方看到，这一点对注重数据安全的人来说是决定性的优势。
1.3 我最终选择 Docker 方式部署的三个理由
Stirling-PDF 的官方文档提供了两种主流安装方式：一个是直接用 Docker 镜像跑容器，另一个是下载 Jar 包然后用 Java 环境启动。我在 Windows 上两种方式都试过，最后长期使用的是 Docker 方式，理由有三点。
第一，环境隔离。Stirling-PDF 依赖 Java 运行时、OCR 引擎、LibreOffice 组件，如果直接跑 Jar 包，Windows 上缺一个依赖就启动失败，而且容易跟你现有的 Java 环境互相干扰。Docker 镜像把这些依赖全部打包好了，拉下来就能跑，不用关心底层库的版本冲突。
第二，升级与回滚方便。这个项目更新很快，几乎每周都有新版本。用 Docker 部署，升级就是拉新镜像、重启容器两条命令；如果用 Jar 包，你要手动下载新包、覆盖旧包、重启进程，遇到问题还得找回上一个版本，麻烦不少。
第三，配置管理更清晰。端口映射、数据目录挂载、环境变量、OCR 语言包，这些用 Docker Compose 写进一个文件里，整个服务的配置一目了然。换机器迁移的时候，把这个文件带上，另一台机器上很快就还原出一模一样的环境。
当然，Docker 方式也有代价，那就是需要先安装 Docker Desktop，对资源占用有一点要求。如果你不想装 Docker，我后面也会给出一套纯 Jar 包的备选方案，两条路都能走到目的地。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的准备：Windows 环境与能用的“容器化”方案
2.1 Windows 下部署的几种形式
先说结论：在 Windows 上部署 Stirling-PDF，本质上就是想办法让它跑起来，而它是个 Java 服务，所以最低要求是有一个能运行 Java 17 的环境。围绕这个目标，大致有三条路：
| 部署方式 | 依赖 | 适合场景 | 我的评价 |
|---|---|---|---|
| Docker Desktop | WSL2 或 Hyper-V | 长期使用、想省心升级 | 最推荐，配置清晰 |
| 直接跑 Jar 包 | JDK 17 | 不想装 Docker、资源紧张 | 可用，但依赖自己处理 |
| Windows 自带的 WSL 里跑 Linux 服务 | WSL 发行版 | 熟悉 Linux 命令的老手 | 多一层抽象，不推荐新手 |
如果你问我到底选哪个，我的建议很直接：只要你的 Windows 是 10 64 位或 Windows 11，并且内存不小于 8GB，就优先选 Docker Desktop。Stirling-PDF 容器本身占用不大，但 Docker Desktop 会额外吃掉一部分内存，8GB 也能跑，只是建议 16GB 更舒服。
前置条件方面，你还需要确认电脑的 BIOS 里已经开启了虚拟化功能。判断方法很简单：打开任务管理器，切到“性能”标签，看右下角“虚拟化”是否显示“已启用”。如果没启用，需要重启电脑进 BIOS，找到 Intel VT-x 或 AMD-V 选项打开。这一步不做，后面的 WSL2 和 Docker Desktop 都装不上。
2.2 安装并完成 Docker Desktop 基础设置
Docker Desktop 对 Windows 的支持已经很成熟，整个安装过程唯一需要留神的就是 WSL2 组件。我的安装顺序是这样的：
先确认 Windows 功能里勾选了“适用于 Linux 的 Windows 子系统”，然后以管理员身份打开 PowerShell，执行一次 wsl --install，系统会自动安装好 WSL2 的内核，并默认设置成 WSL2 版本。装完以后重启一次电脑，然后在命令行里输入 wsl --status 或 wsl -l -v，能看到已安装的发行版和版本号，就说明 WSL2 已经就绪了。
接下来去 Docker 官网下载 Docker Desktop 安装包，双击安装，全程保持默认选项即可。安装完成后，打开 Docker Desktop，在设置里我建议做两件事：第一，在 General 里勾选“Use the WSL 2 based engine”，确保它跑在 WSL2 上；第二，在 Resources 里给 Docker 分配一个合理的内存上限，我是分配了 4GB，留给 Windows 自身足够余量。
启动之后，可以在 PowerShell 里跑一句 docker version，如果输出了 Client 和 Server 两段信息，就说明 Docker 引擎已经正常工作了。这时候你其实已经完成了最难的一步，后面的 Stirling-PDF 部署反而是最简单的。
2.3 不装 Docker 的备选路线：JDK 17 + Jar 包
如果你确实不想为一个小工具装一个 Docker Desktop，那也有一条干净的路：去 GitHub Releases 页面下载 Stirling-PDF 对应的 .jar 文件，然后准备一个 JDK 17 环境。Windows 上安装 JDK 的方式没什么特别的，下载安装包后配置好 JAVA_HOME 环境变量，命令行里输入 java -version 能输出版本号即可。
启动 Jar 包的逻辑是最小化的：在 jar 文件所在目录打开终端，执行 java -jar Stirling-PDF-xxx.jar，服务默认监听 8080 端口，浏览器访问 http://localhost:8080 就能看到界面。这个方式适合临时体验一下，或者你机器上已经有 Java 环境的情况。它的麻烦在于后续更新和 OCR 语言包都要手动处理，长期使用没有 Docker 那么省心。
我个人还是建议：只要机器性能允许，就选择 Docker 路线。接下来的实操步骤我也会完全围绕 Docker 来展开，因为这是最不容易出错、也最容易复现的一条路。
3. 部署 Stirling-PDF 的完整实操记录
3.1 一条命令跑起第一个容器
镜像拉取这一步，理论上只需要一条命令就能完成。我先说最简单的 docker run 形态，适合你只是想快速验证一下的场景。
在 PowerShell 或 CMD 里执行：
bash复制docker run -d --name stirling-pdf -p 8080:8080 -v C:/docker/stirling-pdf:/app/trainingData stirlingpdf/stirling-pdf:latest
这条命令做了什么，我拆开给你解释一下：
-d：让容器在后台运行，不会占住你的终端。--name stirling-pdf：给容器起个名字，后面查看日志、停止容器都用这个名字。-p 8080:8080：把宿主机的 8080 端口映射到容器的 8080 端口，浏览器访问http://localhost:8080就能到达 Stirling-PDF。-v C:/docker/stirling-pdf:/app/trainingData：把 Windows 上的C:/docker/stirling-pdf目录挂载到容器内的/app/trainingData，这个目录是官方建议用来放 OCR 语言包的，提前挂载好以后加语言包就不用重建容器了。
第一次执行时，Docker 会去拉取镜像，几十秒到几分钟不等，取决于你的网络。拉取完成后容器会自动启动，你可以用 docker ps 确认状态，如果看到 stirling-pdf 的 STATUS 是 Up，就说明跑起来了。浏览器打开 http://localhost:8080，界面默认是英文的，可以在页面右上角的语言菜单里切换成简体中文。
这里提醒一下：首次启动时容器内部会做一些初始化和依赖准备，如果立即访问页面提示“连接被拒绝”，稍等 10 到 20 秒再刷新一次就好，不需要过多担心。
3.2 用 Docker Compose 固化你的部署
docker run 适合快速验证，但如果你打算长期用，我更推荐把配置写进 docker-compose.yml 里。这样以后每次启动只需要一条 docker compose up -d，所有参数都在文件里，不容易忘。
我在 C:/docker/stirling-pdf/ 目录下新建了一个 docker-compose.yml，内容如下：
yaml复制version: "3.8"
services:
stirling-pdf:
image: stirlingpdf/stirling-pdf:latest
container_name: stirling-pdf
ports:
- "8080:8080"
volumes:
- ./trainingData:/app/trainingData
- ./extraConfigs:/app/configs
- ./logs:/app/logs
environment:
- DOCKER_ENABLE_SECURITY=false
- LANGS=zh_CN
- TZ=Asia/Shanghai
restart: unless-stopped
我特别说明几个环境变量的作用：
DOCKER_ENABLE_SECURITY=false：表示不启用容器内部自带的登录鉴权，因为我会在外部访问层做安全控制，这里先关掉避免双重认证。LANGS=zh_CN：把默认语言锁定为简体中文，打开页面就是熟悉的菜单。TZ=Asia/Shanghai：设置时区，保证日志时间戳跟本地时间一致。
在配置文件所在目录执行 docker compose up -d，Docker 会拉取镜像并启动容器。以后需要停止服务就执行 docker compose down，升级镜像就执行 docker compose pull 然后再 up -d，非常顺手。
我另外还创建了 extraConfigs 和 logs 两个挂载目录。前者可以放自定义设置文件，方便以后调整自定义样式或者功能开关；后者保存运行日志，排查问题时不用进容器内部，直接开本地文件就能看。
3.3 访问、验证和第一份任务测试
部署完成不代表万事大吉，我建议你实际跑一个完整任务来验证服务没毛病。我第一次用的时候就选了一个最简单的合并操作：准备两个 PDF 文件，在页面里选择“合并”功能，把文件拖进上传区域，调整好顺序提交，几秒钟后就能下载到合并结果。
再测一个稍微有点技术含量的任务：把 PDF 转成 Office Word 文档。这个功能在 Stirling-PDF 里实际是通过容器内置的 LibreOffice 组件完成的，点击“转换”菜单，选择“PDF 转 Word”，上传文件后等进度条走完即可。如果这个功能能正常返回可下载的 .docx 文件，说明容器内部依赖基本完整，后面遇到更复杂的操作也不用慌。
验证完本机访问之后，我习惯性看一眼容器日志。命令是 docker logs stirling-pdf，正常启动的日志尾部会看到类似的字样，比如 Started 或者 Tomcat started on port(s): 8080。如果日志里出现大段异常栈，就对照第 6 章的常见问题去排查。
4. OCR、数据持久化与常用配置的细节拆解
4.1 OCR 中文识别：不是“开箱即用”的坑
Stirling-PDF 的 OCR 功能是基于 Tesseract 实现的，默认镜像里只带了英文语言包。也就是说，你直接上传一份中文扫描件，点击“OCR 识别”之后识别出来的大概率是乱码或空白。我刚开始不知道这一点，还以为是镜像坏了，折腾了好一阵才找到原因。
解决办法是额外下载中文语言包，并把语言包放到挂载的 trainingData 目录里。具体操作是：去 Tesseract 的 tessdata 仓库下载 chi_sim.traineddata（简体中文）文件，把它放到 C:/docker/stirling-pdf/trainingData 目录下。如果你还经常处理繁体中文，可以把 chi_tra.traineddata 也一起放进。
放好之后，重启容器让语言包生效：
bash复制docker restart stirling-pdf
回到界面里，打开 OCR 功能，在语言选项里选“chi_sim”，再上传一份中文扫描 PDF 做识别，就能看到识别出的可搜索文本了。这里还要提醒一句，OCR 对扫描图片本身的清晰度很敏感，分辨率低于 150dpi 的扫描件识别率会明显下降，尽量保持原始文件清晰再提交。
4.2 数据持久化的正确姿势
很多新手部署完 Stirling-PDF 后会遇到一个情况：升级容器之后，之前处理的文件记录和自定义设置全没了。原因是容器是临时的，默认数据都写在容器内部，容器一删除就跟着消失。解决这个问题的核心就是挂载目录。
除了上面提到的 trainingData，我建议至少把 configs 和 logs 也挂载出来。前者保存 Stirling-PDF 的应用配置，后者保存运行日志。我在 Compose 文件里已经写好了这两个挂载项，如果你的 docker run 命令里没加，后面补上就行。
还有一个实操细节：不要在宿主机上随便建一个中文路径或带空格的路径去挂载。Docker 在 Windows 下对路径里的中文支持偶尔会出幺蛾子，最保险的办法就是用纯英文目录。我用的 C:/docker/stirling-pdf 就是全英文路径，部署以来没出过路径问题。
4.3 常用环境变量与性能调优参数
Stirling-PDF 支持不少环境变量，这里列几个我实际用下来比较有感的：
| 环境变量 | 作用 | 我的建议值 |
|---|---|---|
LANGS |
默认语言 | zh_CN |
TZ |
时区 | Asia/Shanghai |
DOCKER_ENABLE_SECURITY |
是否开启内置登录鉴权 | 配合外部安全机制时设为 false |
APP_LOCALE |
界面区域设置 | 不设，跟随语言 |
SYSTEM_DEFAULTLOCALE |
默认区域 | 不设 |
性能方面，容器自身对 CPU 的消耗并不夸张，但 OCR 和 PDF 转 Word 这类任务会瞬时吃满 CPU。如果你电脑本身内存不大，建议在 Docker Desktop 设置里给足内存，至少 4GB。我在 8GB 内存的机器上试过，日常单文件转换没什么问题，但连续处理多个大文件时能感觉到明显卡顿。后来换到 16GB 内存的机器，才真正体会到本地部署的流畅感。
如果你发现单个 PDF 处理时间特别长，还可以从另一个角度优化：优先用轻量的 PDF 操作功能，比如合并拆分、加水印，这些操作不会调用 LibreOffice，速度非常快；而转换类任务相对较重，能少用就少用。
5. 从本机到局域网再到公网：外部访问的实施方案
5.1 先让局域网里的设备访问到它
Stirling-PDF 部署好之后，如果只有本机能访问，那它就只能服务你一个人。大多数个人和团队场景下，你会希望同一局域网里的手机、平板、同事电脑也能访问到。
这一步的核心就是 Windows 防火墙要放行 8080 端口，以及你启动容器时使用了正确的端口映射。检查方法是在另一台设备上，浏览器输入 http://Windows主机局域网IP:8080，如果打不开，先在本机命令行里执行 ipconfig，确认主机的 IPv4 地址是多少。比如你看到的 IP 是 192.168.1.100，那其他设备访问地址就是 http://192.168.1.100:8080。
如果访问不通，九成是 Windows 防火墙拦住了入站流量。解决办法是到“控制面板 - Windows Defender 防火墙 - 高级设置”，新建一条入站规则，允许 TCP 8080 端口通信。这里要注意别为了省事直接关掉整个防火墙，只放行单个端口更安全。我在实际配置时只放行了 8080 这一个端口，其他入站端口保持不变，最大程度减少暴露面。
当你能在手机浏览器上用局域网 IP 打开 Stirling-PDF 并成功处理一个文件后，局域网访问这一步就算完成了。
5.2 通过公网访问：端口映射、DDNS 与域名
讨论公网访问前，我必须先划一条线：如果你为了让处于不同网络的人访问到服务，去搭建某种隐蔽传输通道，这是完全没有必要、也可能触碰安全底线的操作。正规做法是通过家里的路由器或云主机做端口映射，把请求引导到你的 Windows 机器上，并且必须做好访问控制。
最基础的公网访问方案，是在路由器上设置端口映射。比如你家的宽带有一个公网 IP，你在路由器后台把外网的某个端口（如 8080）映射到 Windows 主机的内网 IP 和 8080 端口。设置完成之后，外部设备输入 http://公网IP:端口 就能访问到 Stirling-PDF。
大多数家庭宽带的公网 IP 是动态变化的，所以还需要配一个 DDNS 动态域名服务。路由器一般都自带 DDNS 功能，绑定一个域名之后，即使公网 IP 变了，域名始终能解析到最新地址。
这里要给两个提醒：一是很多宽带运营商默认不提供公网 IP，你需要自行联系服务商确认；二是如果服务是通过家宽对外发布的，只应服务于自己的可信设备，绝不要写成公开的“免费工具站”给别人用，否则一旦被滥用，最终风险还是落到自己身上。
5.3 安全加固：HTTPS、访问控制与反代建议
公网访问一旦开通，就等于把服务暴露到了整个互联网的扫描器面前。所以先别急着开放端口，先把安全措施做足。
我推荐的架构是：不要直接把 Stirling-PDF 的 8080 端口映射到公网，而是在前面加一层 Nginx 或者 Caddy 做反向转发。这层转发可以把外部请求通过 HTTPS 加密传输，同时在转发时校验访问者身份。我自己的实现里，用一台云服务器当作入口，云服务器上跑了 Nginx，配置了从公网域名到家里 Windows 主机 8080 端口的转发，并开启了 HTTP Basic 认证。外部用户访问时，必须先输入用户名和密码，认证通过后才会把请求转发到真正的 Stirling-PDF。
如果你只是个人或小团队使用，我建议在 Nginx 配置里加一条类似的认证配置（示意片段，具体以你的部署环境为准）：
nginx复制location / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://你的Windows主机IP:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
这个文件里的密码建议用足够复杂的强密码，并定期更换。另外，HTTPS 证书可以申请免费的 Let's Encrypt 证书，Caddy 甚至可以自动申请和续期，比手工管理证书省心很多。这样整套链路就是“客户端 -> HTTPS 加密入口 -> 带认证的反向转发 -> Stirling-PDF”，数据在传输过程中不会被明文截获。
5.4 不推荐把 8080 裸奔到公网
我见过一些教程，教人直接把容器端口映射到路由器上，然后抛出一个公网地址就说“部署完成”。在我看来，这种“裸奔”做法非常危险，尤其是 Stirling-PDF 这种工具，它允许用户上传文件、进行文档处理，暴露在公网上很容易被恶意刷量、上传非法内容，甚至被人利用程序漏洞。
如果你想在公网使用，请务必坚持几个原则：
- 只用 HTTPS 访问，不用明文 HTTP。
- 入口处一定加身份认证，不能用“谁拿到网址谁就能用”的方式。
- 不要用默认的 8080 端口直接做公网映射，可以把外部端口换成高位随机端口，降低被扫描到的概率。
- 定期查看访问日志，发现异常请求后及时封禁来源 IP。
如果你对网络配置不熟悉，我的建议更简单：先只做局域网访问，不急于开放公网。大部分日常场景，比如家里多台设备使用、小办公室共享，局域网已经完全够用了。公网访问是“锦上添花”，不是“必须完成”，安全永远排在便利前面。
6. 常见问题与避坑清单
6.1 启动失败排查
Docker 容器启动失败是我遇到过最多的一类问题。如果你执行 docker ps 发现容器没在运行，先用 docker logs stirling-pdf 看日志。常见的失败原因有三个：
一是端口被占用。你可能本来就在 8080 端口上开了别的服务，容器启动时会直接报端口冲突。解决办法是换一个宿主机端口，比如把 -p 8080:8080 改成 -p 8090:8080，然后访问 http://localhost:8090。
二是 WSL2 资源不足。Docker Desktop 在低配机器上偶尔会启动失败，日志里会出现内存分配相关的异常。这时去 Docker Desktop 设置里调大内存上限，或者关掉一些没有在用的容器和程序，腾出资源再重启。
三是镜像还没有完全拉取。如果你是在网络不太稳定的环境下执行安装，镜像可能只拉取到一半，启动时因为缺少文件报错。删掉容器和镜像，重新拉取一次即可。
6.2 端口占用与资源不足
这个问题虽然基础，但真的容易忽略。我建议部署前先执行 netstat -ano | findstr :8080 看看本机 8080 端口有没有被占用。如果被占用，最简单的办法就是换个端口。修改端口之后，前面提到的防火墙放行规则、路由器端口映射也要同步更新，否则外部还是访问不到。
资源不足的问题在 OCR 和转换任务上表现最直观，表现就是页面一直转圈，或者任务进度条卡住不动。如果你经常处理大 PDF，建议在 Docker Desktop 里把 CPU 和内存配额放宽，并且尽量在电脑空闲时段处理重任务，避免同时开着浏览器几十个标签页跟容器抢资源。
6.3 OCR 不生效或乱码
OCR 中文识别乱码，绝大多数情况是语言包没有正确加载。检查点有三个：语言包文件是否在挂载目录里、文件名是否准确、容器是否已经重启。文件名必须是 chi_sim.traineddata，不能改成其他名字；挂载目录如果不对，容器内看不到语言包，重启也没用。
还有一种情况是，OCR 识别出来了，但识别结果里夹杂着大量方块字符。这通常是扫描图片对比度太低或字体过于花哨造成的。我会把扫描件放到图片编辑软件里，先做一遍灰度增强，再转成 300dpi 的 PDF 提交识别，准确率会明显提升。
6.4 外部访问不通
如果你完成端口映射后，从外网依然访问不了，先不要急着怀疑 Stirling-PDF 本身，按照顺序排查：
- 本机防火墙是否放行了映射使用的公网端口。
- 路由器端口映射是否正确保存，且内外端口没有写反。
- 路由器上的 DDNS 域名是否已经解析到最新公网 IP。
- 运营商是否封禁了相关端口，比如常见的 80、443 端口在部分宽带环境下不可用。
我自己的情况是卡在“外网访问时，微信偶尔提示网络异常”，排查了半天才发现是路由器把外网访问请求从内网回环时被自己拦截了。后来改用云服务器转发的方案，反而一次就成功了。所以如果你反复配置还是不通，与其在路由器上死磕，不如考虑换一个更成熟的转发架构。
最后再说点实际操作中的心得
我用了数月 Stirling-PDF，最大的感受是：自托管工具的价值，不只是“免费”和“功能全”，更重要的是“数据始终在自己手里”。以前在线工具随便传文件，处理完还要担心文件残留；现在所有处理都在本地 Windows 机上，即使断网也能正常用，这种踏实感用过就回不去了。部署这件事本身不复杂，最花心思的其实是外部访问和安全加固。如果你只是自己用，建议永久停留在“局域网访问”这个阶段就好；如果确实需要在外面用，也务必把 HTTPS 和强认证做扎实。最后一个小建议：多关注 Stirling-PDF 的 GitHub Releases 页面，这个项目迭代很勤，隔一两个月更新一次版本，用 Docker 方式升级特别省事。希望这篇操作记录能帮你顺利把服务跑起来，少踩几个我当年趟过的坑。