做医学影像相关项目的人，大概率都撞上过同一个问题：手里一堆DICOM文件，想拿给同事或客户看，发截图表达不清，让对面装一个阅片软件又太麻烦。我自己在项目里就被这事折腾过很多回，直到把 OHIF 和 Orthanc 这对组合在远程服务器上搭好，才算真正把“影像资料的展示和分发”变成了一个稳定可用的内部服务。
这篇博客就完整记录一次在 Ubuntu 22.04.2 远程服务器上从零搭建 OHIF + Orthanc 的过程。内容是面向实战的，包含我实际操作时用到的命令、配置文件、踩坑记录和排查思路。适合需要快速搭建医学影像 Web 阅片系统的医工工程师、科研人员，也适合刚接触 DICOM / PACS 概念、想找一套开源方案练手的同学参考。
1. 为什么是 OHIF + Orthanc：这个组合到底能解决什么问题
1.1 先把关键概念说清楚
在动手之前，我建议先花两分钟建立一个整体认知，不然配置的时候很容易“知其然而不知其所以然”。
DICOM 是医学影像领域的事实标准格式，几乎所有 CT、MR、DR、US 设备导出的数据都是 DICOM 文件。DICOM 跟普通图片最大的区别在于：它不只是图像，里面还带着患者信息、检查信息、设备参数、系列关系等一堆结构化数据。所以处理 DICOM 不能简单当 PNG / JPG 一样丢给浏览器。
PACS 是医学影像归档与通信系统的缩写，核心工作是存储、管理、传输 DICOM 数据。大型院内 PACS 通常很贵，实施周期也长，很多小团队或个人开发者根本用不上。
OHIF（Open Health Imaging Foundation）是一款开源 Web 医学影像查看器，浏览器打开就能看 DICOM 影像，支持 2D / MPR / MIP 等常见阅片模式，UI 做得也比较现代。它本身不存储数据，而是通过标准接口去后端拉取影像。
Orthanc 则是一个轻量级开源 DICOM 服务器，既能通过 DICOM 协议接收设备推送的数据，也能把 DICOM 文件转成 REST API 接口供 Web 前端调用，还额外支持 DICOMweb 标准（QIDO / WADO / STOW）。打个不那么严谨的比方：Orthanc 是影像仓库 + 接口服务，OHIF 是面向人的展厅，展厅不存货物，需要什么就从仓库里调。
1.2 选这套组合的理由
很多人会问，能用现成商业 PACS 为什么还要自己搭？我的选择理由主要有四点。
第一，完全开源。OHIF 的授权协议允许商用二次开发，Orthanc 同样开源，关键是可以不锁死在厂商生态里。
第二，接口标准统一。OHIF 通过 DICOMweb 和 Orthanc 交互，这套标准同样是主流商用系统的通用语言。我先在 Orthanc 上打通，以后想切换或对接真正的院内 PACS，改动成本也低。
第三，部署资源占用小。Orthanc 本身是 C++ 写的轻量服务，跑在一台 2C4G 的云主机上完全没压力。OHIF 构建完就是一堆静态文件，放到 Nginx 里就行。
第四，方便远程协作。部署在远程服务器上以后，只要有网络，同事在浏览器输入 IP 就能看片子，不再需要逐台安装阅片软件。
1.3 整体架构与数据流向
这套系统在实际运行中大概是这样的流程：
浏览器打开 OHIF 页面后，用户进入到影像列表；OHIF 会向配置好的 DICOMweb 地址发起查询请求，列出可用的检查；用户点击某个检查后，OHIF 再按序列、实例的粒度向服务端请求缩略图和完整像素数据；这些请求统一打到 Nginx 上，Nginx 再把/dicom-web或/wado路径反向代理给 Orthanc；Orthanc 在本地磁盘的存储目录里找到对应 DICOM 文件，处理后返回给前端。
整个链路里，Nginx 承担静态页面托管和反向代理两个职责，Orthanc 承担存储和协议转换职责，OHIF 只负责展示和交互。后面所有配置，都是围绕这条链路的打通进行的。
2. 环境准备：先把远程服务器收拾干净
2.1 远程连接：SSH 与 VSCode Remote-SSH 实操
远程服务器的第一道门槛，就是怎么进去敲命令。我日常用的方式有两种：直接终端 SSH，或者用 VSCode 的 Remote-SSH 插件。
终端 SSH 是最基本的：
ssh username@your_server_ip用密码登录时如果遇到Permission denied, please try again，先别急着怀疑密码错误。常见原因有三个：登录用户名不对，默认 root 可能被禁用而你还用 root 在试；密码输入时有不可见字符；服务器只配置了密钥登录，不接受密码认证。如果你手上已经有一对密钥，建议优先用密钥：
ssh-copy-id username@your_server_ip这条命令会把本地公钥追加到服务器的authorized_keys文件里，之后 SSH 就不再每次输密码了。
我个人更推荐在 VSCode 里安装 Remote-SSH 插件，因为后续需要编辑 Nginx 配置、JSON 配置文件、查看服务日志，直接在远程开发窗口里操作比纯终端方便太多。装好插件后在命令面板输入 “Remote-SSH: Connect to Host”，填上username@your_server_ip，第一次连接会出现“选择平台”提示，选 Linux 即可。连接成功后左下角会显示远程主机标识，然后就可以像在本地一样打开远程目录、执行终端命令了。
2.2 系统基础设置与端口放行
连接上服务器后，先把系统源和基础软件升级到最新：
sudo apt update sudo apt upgrade -y然后检查防火墙状态。很多云服务器默认开了 UFW 或类似防火墙，而 80、8042、4242 这些端口往往没有放行。既然我们要对外提供 Web 服务，先统一放行：
sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 8042/tcp sudo ufw allow 4242/tcp sudo ufw enable注意：如果服务器是云厂商的，光改系统防火墙还不够，还得去云控制台的安全组里同步放行对应端口。443 端口如果后面打算配置 HTTPS，也建议提前放行。
8042 是 Orthanc 的 HTTP 端口，4242 是 Orthanc 接收 DICOM 设备推送的协议端口。如果不需要设备往 Orthanc 里直接推数据，4242 甚至可以不对公网开放，只让内网设备访问就够了。从安全角度讲，暴露面越小越好。
3. 安装 Orthanc 并完成 DICOMweb 配置
3.1 两种安装方式怎么选
Orthanc 的安装路径主要有两种：用官方 apt 源安装，或者用 Docker 跑容器。我这里把两种方式都写出来，你可以按情况选。
方式一：官方 apt 源，适合想用 systemd 直接管理服务、日志直接进 journal 的场景。
curl -fsSL https://apt.orthanc-server.com/keys/orthanc.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/orthanc.gpg echo "deb https://apt.orthanc-server.com/ jammy main" | sudo tee /etc/apt/sources.list.d/orthanc.list sudo apt updateUbuntu 22.04.2 的代号是 jammy，所以源里写成 jammy。
然后安装：
sudo apt install -y orthanc orthanc-dicomweborthanc-dicomweb这个包必不可少，因为 OHIF 要走的 DICOMweb 接口由它提供。
方式二：Docker，适合不想污染系统环境的场景。
docker run -d \ --name orthanc \ --restart=always \ -p 4242:4242 \ -p 8042:8042 \ -v /opt/orthanc-db:/var/lib/orthanc/db \ jodogne/orthanc-plugins:latestorthanc-plugins镜像已经集成了 DICOMweb、Web Viewer、PostgreSQL 等常用插件，省去装依赖的麻烦。需要自定义配置时，把本地 JSON 文件挂载进去即可：
-v /opt/orthanc.json:/etc/orthanc/orthanc.json:ro我个人的建议是：临时测试用 Docker 最快，正式环境或长期维护用 apt 安装更顺手，systemd 能自动处理开机自启和崩溃拉起。这篇后续的操作以 apt 安装为例来写。
3.2 orthanc.json 关键参数解析
apt 安装后，主配置文件在/etc/orthanc/orthanc.json。修改之前先备份：
sudo cp /etc/orthanc/orthanc.json /etc/orthanc/orthanc.json.bak我整理了一份最小可用配置，建议直接在此基础上改：
{ "Name" : "OHIF+Orthanc", "Authentication" : true, "RegisteredUsers" : { "orthanc" : "your-password" }, "DicomServer" : { "Port" : 4242, "Aet" : "ORTHANC" }, "StorageDirectory" : "/var/lib/orthanc/db", "HttpPort" : 8042, "Plugins" : [ "/usr/share/orthanc/plugins/libOrthancDicomWeb.so" ], "DicomWeb" : { "Enable" : true, "Root" : "/dicom-web", "EnableWado" : true, "EnableQido" : true, "EnableStore" : true }, "Cors" : "*", "CorsHeaders" : "Authorization,content-type,accept,origin,x-requested-with", "CorsMethods" : "GET,POST,PUT,DELETE,OPTIONS", "CorsMaxAge" : 3600 }几个关键点分别说下。
Authentication设为true后，访问 8042 端口的所有接口都需要带上用户名密码。RegisteredUsers里的orthanc就是默认账号。实际部署时一定把密码换掉，默认的orthanc/orthanc相当于裸奔。
DicomServer.Aet是 Orthanc 在 DICOM 网络里的名字，类似病房门牌号。对接设备时，设备端也要配一个 Application Entity Title，两边要能互相认领。
StorageDirectory是 DICOM 文件的物理存储目录，后续做备份直接打包这个目录。
Plugins数组里加载了 libOrthancDicomWeb.so，这个插件负责把 DICOM 资源暴露为 web 接口。OHIF 能不能列表拉数据，全靠它。
DicomWeb.Root统一了 QIDO / WADO / STOW 三个接口的路径前缀。Orthanc 的 DICOMweb 默认挂在/dicom-web下，这也是我后面配置 OHIF 时主要引用的地址。
Cors系列配置是给跨域场景准备的。如果你用 Nginx 反代把前后端统一到同一个域名和端口，这部分其实可以不用开。但如果 OHIF 直接请求http://服务器IP:8042，前端和后端端口不一致，不开 CORS 的话浏览器会把请求拦截掉。
3.3 启动与验证
保存配置后重启服务：
sudo systemctl restart orthanc sudo systemctl status orthanc看到active (running)就说明起来了。然后验证接口：
curl -u orthanc:your-password http://localhost:8042/studies正常会返回一个空数组[]。再在浏览器里访问：
http://服务器IP:8042/app/explorer.html输入账号密码后，会进入 Orthanc 的 Web 管理界面，左侧能看到 Studies、Series、Instances 等栏目。此时还没有任何数据，属于正常状态。
4. 部署 OHIF 前端查看器
4.1 方式一：源码构建 OHIF
OHIF 官方仓库在 GitHub 的 OHIF/Viewers，构建前需要装好 Node.js 和 Yarn。OHIF v3 对 Node 版本要求比较严格，我用的是 Node 18，实测稳定。
推荐用 nvm 管理 Node 版本：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash nvm install 18 nvm use 18然后拉取代码并安装依赖：
git clone https://github.com/OHIF/Viewers.git cd Viewers yarn install这里如果网络访问 npm 源很慢，建议先设置镜像源再安装：
npm config set registry https://registry.npmmirror.com依赖装好后构建：
yarn run build构建产物会出现在platform/app/dist目录下。整个构建过程大概几分钟，服务器内存如果偏低，可能会比较吃力，建议至少 2G 内存。
4.2 方式二：Docker 镜像方式
如果不想长时间跟 Node 构建过程较劲，OHIF 官方也提供 Docker 方式部署。具体镜像名和版本以官方仓库发布为准。大体命令是：
docker pull ohif/viewer:latest docker run -d -p 80:80 ohif/viewer:latest容器内部本身就带 Nginx，启动后访问 80 端口就能看到 OHIF 页面。自定义后端地址时，通常需要挂载一份自己的配置目录进容器。这种方式胜在省事，缺点是想深度定制 UI、加入认证逻辑时反而不如源码构建灵活。
注意：无论哪种方式，OHIF 本身只是个前端壳子，没配好后端数据源时，页面里只会看到空列表或报错。所以构建部署只是第一步，真正的关键在下面的配置。
4.3 用 Nginx 托管 OHIF 静态文件
源码构建完成后，把产物搬到 Nginx 的站点目录：
sudo apt install -y nginx sudo mkdir -p /var/www/ohif sudo cp -r platform/app/dist/* /var/www/ohif/然后新建一个 Nginx 站点配置：
sudo nano /etc/nginx/sites-available/ohif基础配置这样写：
server { listen 80; server_name your_server_ip; root /var/www/ohif; index index.html; location / { try_files $uri $uri/ /index.html; } }try_files那行非常关键，因为 OHIF 内部是单页应用，路由由前端接管，如果直接访问某个子路径（比如/viewer），Nginx 匹配不到物理文件，就需要回退到index.html让前端自己解析路由。
启用站点并重载 Nginx：
sudo ln -s /etc/nginx/sites-available/ohif /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx浏览器访问http://服务器IP，应该能看到 OHIF 的初始界面。
4.4 配置 Nginx 反向代理避免跨域
我在前面提到，最简单省心的数据链路是通过 Nginx 反代 Orthanc，把前后端收敛到同一个域名端口下。这样不用开 CORS，后续加 HTTPS 也方便。在刚才的 Nginx 配置里再加两个 location：
location /dicom-web/ { proxy_pass http://127.0.0.1:8042/dicom-web/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /wado { proxy_pass http://127.0.0.1:8042/wado; proxy_set_header Host $host; }重点说明一下 proxy_pass 尾部斜杠的含义。当 location 是/dicom-web/且 proxy_pass 的末尾也有/时，Nginx 会用 proxy_pass 里的http://127.0.0.1:8042/dicom-web/去替换掉请求 URL 里的/dicom-web/前缀。比如浏览器请求/dicom-web/studies?limit=10，实际转发到 Orthanc 的地址是http://127.0.0.1:8042/dicom-web/studies?limit=10。这样 Orthanc 收到的路径和原始路径一致，逻辑上最清晰。
还有一种做法是把整个/orthanc/前缀代理到 8042：
location /orthanc/ { proxy_pass http://127.0.0.1:8042/; }这种写法的效果是/orthanc/dicom-web/studies会被转成/dicom-web/studies，等于把 Orthanc 的整体路径挂到了/orthanc底下。两条路都能走，我这里推荐第一种，因为 OHIF 里可以直接填/dicom-web作为根路径，不必额外加前缀。
改完配置后同样执行nginx -t和systemctl reload nginx。然后验证一下代理是否通：
curl http://localhost/dicom-web/studies -u orthanc:your-password如果返回空数组[]，说明代理链路已经打通。
4.5 OHIF 数据源配置
OHIF v3 的配置入口在构建目录的public/config/default.js文件，修改前也先备份。核心配置内容如下：
window.config = { routerBasename: '/', dataSources: [ { friendlyName: 'Orthanc', namespace: 'org.ohif.dicomweb', configuration: { name: 'orthanc', wadoUriRoot: '/wado', qidoRoot: '/dicom-web', wadoRoot: '/dicom-web', qidoSupportsIncludeField: true, imageRendering: 'wadouri', thumbnailRendering: 'wadouri', enableStudyLazyLoad: true, supportsFuzzyMatching: true, supportsWildcard: true, dicomUploadEnabled: true } } ], defaultDataSourceName: 'orthanc' };这里qidoRoot和wadoRoot都指向了相对路径/dicom-web，走的是 Nginx 代理，所以不会跨域。imageRendering和thumbnailRendering用wadouri模式，通过 WADO URI 方式拿图和缩略图，兼容性较好。
dicomUploadEnabled设为true后，OHIF 界面里会直接出现上传入口，不需要再跑到 Orthanc 后台去传文件，日常使用体验提升不少。
如果不用 Nginx 反代，而是让 OHIF 直接访问 Orthanc 的 8042 端口，那么这几个路径需要写成绝对地址：
wadoUriRoot: 'http://服务器IP:8042/wado', qidoRoot: 'http://服务器IP:8042/dicom-web', wadoRoot: 'http://服务器IP:8042/dicom-web',同时 Orthanc 的orthanc.json里必须像 3.2 节那样开启 CORS。我个人实测下来，跨端口访问的坑比较多，优先推荐 Nginx 反代模式。
配置改完后重新构建一次：
yarn run build sudo cp -r platform/app/dist/* /var/www/ohif/如果你把配置放在了构建目录里，每次修改配置后都需要重新拷贝产物到 Nginx 根目录。
提示：修改配置和构建时，务必确保当前目录在 Viewers 仓库根目录下。否则
yarn run build可能会因为找不到工作区而报错。
5. 联调与数据上传：让第一张 DICOM 片子成功显示
5.1 准备测试数据
手头没有 DICOM 文件的话，可以从网上找公开的示例数据集，或者用 DICOM 工具从已有设备导出。常见来源包括：
- 开源项目官方仓库里附带的小样本
- 一些医学影像算法比赛提供的历史数据
- 自己本地阅片软件导出的匿名化数据
我建议拿一份包含多个序列的 CT 或 MR 数据来测试，因为 OHIF 里序列切换、多平面重建这些功能需要多序列数据才看得出效果。
5.2 三种数据上传方式对比
数据上传有三条常用路径，我把它们整理成了表格：
| 方式 | 操作入口 | 适用场景 | 是否需要额外工具 |
|---|---|---|---|
| Orthanc Web 界面上传 | http://IP:8042/app/explorer.html，点击 Upload | 少量文件、零安装 | 不需要 |
| DICOM 协议推送 | 第三方工具 storescu 推送到 4242 端口 | 批量导入、模拟设备推送 | 需要 DCMTK |
| STOW-RS 方式 | 用 curl 直接 POST 到/dicom-web/studies | 脚本化集成、接口对接 | 不需要 |
Orthanc Web 界面上传最简单，适合首次测试。进入管理界面后找到 Upload 入口，把文件拖进去就行。DICOM 文件会显示接收进度，完成后左侧 Study 列表里就能看到数据。
如果你需要模拟真实设备推送流程，用 DCMTK 里的 storescu 命令比较合适。设备在医院 PACS 系统里投递影像时，底层走的就是这个流程：
storescu -v -aet OHIF_TEST 127.0.0.1 4242 /path/to/dicom/file.dcm其中-aet指定发出请求的应用实体名称，对方（Orthanc）会在日志里看到这个 AET。如果设备端和服务器端的 AET 配置不匹配，推送会被拒绝。
用 STOW-RS 方式适合写脚本批量导入。一个典型的 curl 命令类似这样：
curl -u orthanc:your-password \ -X POST "http://localhost/dicom-web/studies" \ -H "Content-Type: application/dicom" \ --data-binary @file.dcm注意这里的地址走了 Nginx 代理，所以路径是/dicom-web/studies。如果直接测 Orthanc 端口，则是http://localhost:8042/dicom-web/studies。
5.3 浏览 OHIF 验证全流程
数据上传完成后，打开http://服务器IP，会看到 OHIF 界面的左下角或顶部出现检查列表入口。点击进入，刚才上传的检查会列在 Local 数据源下面。
点击某个检查进入阅片界面后，正常情况下左侧会出现序列缩略图，中间主区域显示当前选择的影像。能走到这一步，说明整条链路已经通了。
如果列表能出现检查但点进去是空白，优先检查浏览器的开发者工具 Network 面板，看请求是否 4xx / 5xx，或者直接被 CORS 拦截。这是排查过程中最高频的问题。
6. 常见问题排查与避坑指南
6.1 远程连接与服务启动问题速查
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| SSH 提示 permission denied | 用户名不对 / 密钥未配置 / root 登录被禁用 | 确认用户名，检查服务器sshd_config中PermitRootLogin与PasswordAuthentication |
| 80 端口访问超时 | 防火墙未放行 / 云安全组未配置 | 检查ufw status，再到云控制台安全组确认端口 |
| 8042 无法访问 | 服务未启动 / 端口被防火墙拦截 | systemctl status orthanc，`ss -lntp |
| curl 返回 401 | 认证未通过 | 检查Authentication与RegisteredUsers，确认密码 |
| OHIF 页面能开但列表为空 | 数据源配置错误 / Orthanc 没有数据 | 用 curl 请求/dicom-web/studies验证接口，再核对 OHIF 配置 |
6.2 OHIF 空白 / 加载不出来的排查顺序
如果 OHIF 页面能打开但看不到影像，我一般按以下顺序排查：
先看浏览器开发者工具 Network 面板，找到studies这个请求，如果状态码是 401，说明账号密码没配对，或者请求代理到 Orthanc 时没带上认证信息。如果状态码是 404，多半是路径不对，比如qidoRoot写成了/orthanc/dicom-web，但 Nginx 并没有配置对应的代理前缀。
如果状态码是 200 但返回内容是text/html而不是 JSON，说明请求被 Nginx 的try_files规则拦截了，回退到了index.html。这种情况通常是因为 Nginx 配置里缺少了对/dicom-web的代理规则，或者 proxy_pass 路径拼接不对。这正是 Nginx 模式最容易踩的坑：location 规则和 proxy_pass 的尾斜杠不一致，导致代理转发的目标地址错误。
再往下就是 CORS。如果 OHIF 直接访问http://IP:8042，浏览器控制台会出现 “No ‘Access-Control-Allow-Origin’ header is present on the requested resource”。解决方式要么在 Orthanc 配置里开启 CORS，要么换成 Nginx 反代模式。
6.3 npm / Yarn 构建过程中的常见坑
OHIF 构建最容易翻车的地方是 Node 版本不匹配和网络问题。Node 18 是我验证过的版本，低于 16 直接跑不起来。如果已经装了旧版 Node，用 nvm 切换最方便：
nvm install 18 nvm use 18 node -vyarn install执行时间较长，如果发现卡在某个包上，大概率是网络问题。切换镜像源后重新执行即可。构建过程中如果磁盘空间不足，也会报出奇怪的错误，所以先跑一下df -h确认根目录剩余空间。
6.4 Nginx 配置后未生效
改完 Nginx 配置后一定要执行nginx -t检查语法，然后systemctl reload nginx让新配置生效。每次我忘了 reload，都会在浏览器里对着一堆 404 发呆好一阵。另外，别忘了确认站点链接存在：
ls -l /etc/nginx/sites-enabled/缺少sites-enabled下的软链接，Nginx 根本不会加载你的站点配置。
7. 进阶建议与扩展思路
7.1 给 Orthanc 加访问保护
默认的orthanc/orthanc账号口令测试够用，正式环境一定要改。可以创建多个用户，分别分配给不同角色：
"RegisteredUsers" : { "admin" : "strong-admin-password", "viewer" : "viewer-only-password" }不过在 Orthanc 自带的认证体系里，区分“只读”和“可写”权限需要借助配置项Authorization配合权限插件，没有开箱即用的角色体系。如果系统要对外开放，建议把 OHIF 放到 Nginx 后面再加一层 Basic Auth 或接入公司现有的 SSO。
7.2 数据备份与迁移
Orthanc 的数据分成两部分：配置文件和存储目录。DICOM 文件全部落在StorageDirectory指定的目录，里面除了原始文件，还有 Orthanc 维护的索引数据库。备份时停止服务后直接拷贝整个目录最稳妥：
sudo systemctl stop orthanc sudo tar -czf /backup/orthanc-backup.tar.gz /var/lib/orthanc/db sudo systemctl start orthanc迁移到新服务器时，把备份解压到相同路径，再安装相同版本的 Orthanc，即可恢复数据。如果数据量很大，建议考虑 PostgreSQL 插件，把索引放到 PG 里，管理性能和备份策略都会更灵活。
7.3 后续扩展思路
这套组合的扩展空间其实很大。OHIF 支持自定义扩展，可以接入自家算法服务，比如在阅片界面直接调用 AI 模型做病灶标注；Orthanc 侧可以通过 REST API 和 Webhook 与业务系统对接，实现影像上传后自动触发后处理流程；还可以顺带部署一个orthanc-webviewer插件，生成简单的 DICOM 网页预览链接，给患者或外院医生免登录查看。
我个人在实际操作中的体会是，这套系统最难的部分不是安装，而是把“前端配置、后端代理、跨域策略、数据来源”这四件事真正串起来。很多问题表面看起来是 OHIF 的 bug，最后追到底其实是 Nginx 路径拼接或 CORS 配置没对齐。如果你对 Nginx 和请求链路不太熟，建议照着我前面的步骤，先跑通 Nginx 反代模式，再逐步尝试改造成自己的域名、HTTPS 和鉴权方案。
另外再分享一个小技巧：排查期间可以开一个终端窗口持续跟踪 Orthanc 日志。apt 安装后执行sudo journalctl -u orthanc -f，Docker 方式则用docker logs -f orthanc。当 OHIF 报错时，Orthanc 的日志会直接告诉你请求有没有到达后端、路径是什么、返回了什么状态码，这比在浏览器里瞎猜高效得多。
