上周帮同事搭了一个临时影像归档点，需求不难：把CT、MR设备导出的DICOM文件集中存起来，方便几个人在Windows工作站上直接查看和调取，不需要上完整PACS那么重的方案。我第一反应是Orthanc，开源、轻量、Windows下直接跑，一个exe加一个JSON配置就能干活，中间接触到的坑位正好整理成这份记录。
Orthanc是一款开源的轻量级DICOM服务器，原生支持标准DICOM协议，自带Web管理后台和REST API，部署形态非常简单，尤其适合小规模影像归档、设备调试、数据中转这类场景。这篇会从Windows环境下的安装开始，把配置文件解析、设备对接、常见故障排查完整过一遍，给准备用Orthanc做影像管理的人提供一份可复现的实操参考。
1. Orthanc是什么？为什么Windows环境适合用它
1.1 一个轻量级的医学影像服务器
Orthanc不是全功能PACS，它更像是“DICOM数据的中转站和仓库”。它能够做的事情，我用一句话概括：通过DICOM协议接收影像设备发送的CT、MR、DR等图像，存储到本地，然后通过浏览器或REST API进行查询、预览和导出。
它和传统PACS的差异，主要在设计思路上。完整PACS往往包含复杂的RIS集成、工作列表、胶片打印中心、高级影像后处理，部署一套下来的资源占用和人天成本都不低。Orthanc的定位是“轻”：单个Windows程序、一份配置文件、一个存储目录，就可以在办公室电脑或小型服务器上运行。它在医学影像调试、第三方设备对接、科研数据收集这些场景里非常常见。
国产的或者在采购流程中的大型PACS系统，往往要求独立机房和专门的运维人员，而Orthanc可以在普通办公电脑上落地。对医院信息科的工程师或独立技术顾问来说，这种“几分钟起一个DICOM服务”的能力很实用。
1.2 为什么选Windows而不是Linux
从社区使用占比来看，Orthanc在Linux服务器上更主流，很多人会用Docker部署，一条docker run命令就能拉起来。但实际项目里确实存在大量Windows环境。原因主要有三个：
- 设备厂商提供的很多影像工作站软件只支持Windows，工作流上绕不开；
- 医院或小团队已有的服务器就是Windows Server，再单独引入Linux虚拟机的运维成本不划算；
- 部分设备的DICOM导出工具只兼容Windows共享路径或指定服务环境，用Windows做归档点更顺。
Windows上跑Orthanc，性能上确实不如Linux在大并发下的表现。但如果只是小规模存储、几台设备对接、内部查阅，差距基本感知不到。Orthanc本身对资源要求极低，空闲状态下内存占用通常在几十MB级别，这点在Windows服务器上完全可接受。
2. Windows下的安装与首次启动
2.1 下载正确版本的安装包
Orthanc官方发布页面提供了多平台的二进制包，Windows平台下载的是zip压缩包。这里要注意，不要下载Wrong的版本（比如Linux的AppImage），Windows包解压后是这样一层结构：
Orthanc-win64/ │ ├── Orthanc.exe ├── LICENSE ├── README.txt └── Resources/ ├── Configuration/ │ ├── Orthanc.json │ └── Samples/ └── WebViewer/ └── ...解压后直接双击Orthanc.exe就能运行，但是建议不要真的直接双击。原因有两个：一是控制台窗口会一直挂着，不便于系统管理；二是没有指定配置文件和存储目录的情况下，Orthanc默认会在当前目录写数据，极容易把项目目录搞乱。
官方提供的Orthanc.exe是一个自包含可执行文件，依赖的外部组件很少。如果系统提示缺少MSVC运行库，去下载vc_redist.x64.exe装一下即可，绝大部分Windows 10/11和Windows Server 2016以上版本都自带运行库，这步通常不会踩坑。
2.2 目录规划与初次启动验证
我的习惯是建一个独立目录，跟解压目录分开，例如D:\OrthancData，里面再分storage、index、logs三个子目录。然后通过命令行指定配置启动：
D:\Orthanc\Orthanc.exe D:\OrthancData\orthanc.json命令行参数第一个整形路径就是配置文件的路径。如果这个文件不存在，Orthanc会直接报错退出，所以实际操作中可以先在解压目录的Resources\Configuration里找到官方示例Orthanc.json，复制到D:\OrthancData下再启动。
第一次启动成功的标志是控制台打印出这两行关键信息：
Starting the DICOM server on port 4242 Starting the HTTP server on port 8042看到这两行，说明DICOM服务和Web服务都起来了。然后用浏览器访问http://127.0.0.1:8042，如果弹出认证窗口，默认用户名和密码是orthanc/orthanc，顺利进入首页就说明安装成功。需要注意的是，不同版本默认认证策略可能不一致，如果没弹认证框也不是版本问题，先确认配置文件里AuthenticationEnabled的值。
2.3 把Orthanc注册为Windows服务
开发调试时可以开一个命令行窗口跑，但生产环境不可能依赖用户手动启动程序。我建议把Orthanc注册成Windows服务，开机自启，掉线自动重启。官方文档推荐NSSM（非吸吮服务管理器），也可以用Windows自带的任务计划程序。
NSSM的注册命令非常简单，管理员权限打开CMD：
nssm install Orthanc "D:\Orthanc\Orthanc.exe" "D:\OrthancData\orthanc.json" nssm set Orthanc AppDirectory "D:\Orthanc" nssm set Orthanc AppStdout "D:\OrthancData\logs\stdout.log" nssm set Orthanc AppStderr "D:\OrthancData\logs\stderr.log" nssm start Orthanc注册成服务后，服务账户默认是LocalSystem，有权访问本机目录。但要特别注意存储目录的NTFS权限，如果Orthanc在写入D:\OrthancData时提示“Access denied”，就需要手动给LocalSystem或Everyone添加写权限。NSSM方式比任务计划程序的兼容性更好，对进程退出后的自动重启处理也更稳定，是Windows服务化部署的常规做法。
3. 核心配置文件orthanc.json逐项拆解
3.1 先了解配置文件的基本结构
Orthanc的配置文件是JSON格式，结构不复杂，但容易因为少一个逗号或者多一个引号导致服务无法启动。Windows下还要注意路径分隔符，JSON标准要求反斜杠转义，所以Windows路径的写法是"D:\\OrthancData\\storage"，这一点初用者很容易忽略。
一个最基础的配置文件大概长这样：
{ "Name": "my-orthanc", "DicomAet": "ORTHANC", "DicomPort": 4242, "HttpPort": 8042, "AuthenticationEnabled": true, "RegisteredUsers": { "admin": "yourpassword" }, "StorageDirectory": "D:\\OrthancData\\storage", "IndexDirectory": "D:\\OrthancData\\index", "DicomModalities": { "CT-DEVICE": { "AET": "CT1", "Host": "192.168.1.50", "Port": 11112 } } }Name字段是服务在DICOM环境中的身份标识，主要用于日志和自描述。DicomAet是AE Title，相当于DICOM世界的“主机名”，DICOM设备之间通信会用它互相识别。DicomPort和HttpPort分别是DICOM协议和HTTP协议对外服务的端口。大多数场景下，默认的4242和8042不需要改。
3.2 认证、存储路径这些必改项
AuthenticationEnabled决定Web界面和REST API是否启用身份认证。Orthanc默认是启用认证并带默认用户orthanc/orthanc，生产环境必须修改。如果只是在内网临时调试，关掉认证固然方便，但风险很高，因为8042端口暴露时，任何人都能查询和下载影像数据。标准做法是打开认证，并删除或修改默认账户：
"AuthenticationEnabled": true, "RegisteredUsers": { "myuser": "mysafe-password" }修改后，访问Web界面或调用REST API时使用新用户名密码。RegisteredUsers支持多用户，不同用户可以分配不同密码，但Orthanc没有内置细粒度的权限体系，所有用户默认权限等同。如果需要更细的权限控制，要么通过反向代理实现，要么用Orthanc的Lua脚本扩展，后者成本略高，小团队一般用不着。
StorageDirectory和IndexDirectory是Orthanc的数据核心。StorageDirectory存放DICOM文件本体，IndexDirectory存放索引数据库文件（默认SQLite）。两目录务必放在可靠磁盘上，最好是NTFS格式的本地盘，不要放U盘或网络映射盘，数据库文件在网络存储上容易出现锁冲突和损坏风险。规划时要注意空间上限，Orthanc是全文检索的仓库型服务，哪怕只存了几千个序列，索引和文件增长也很快。
3.3 扩展配置：数据库、查询与隐私保护
Orthanc默认用SQLite作为索引数据库，适合单机小规模场景。数据量较大（例如超过几十万实例）时，SQLite的查询性能会显著下降，此时可以切换PostgreSQL。在Windows上配置PostgreSQL比Linux要多几步，需要单独安装数据库服务并创建专用库，然后在配置文件里指定连接字符串：
"IndexDirectory": null, "PostgreSQL": { "Enable": true, "Host": "127.0.0.1", "Port": 5432, "Database": "orthanc", "Username": "orthanc", "Password": "orthanc" }切换数据库前必须确认一件事：Orthanc是否启用了DicomModalitiesInDatabase、DicomInstancesInDatabase等选项。如果之前跑了很久并且索引目录已经有大量数据，不可以直接切换，需要做数据迁移或重新对接设备发送数据。
查询限制方面，有几个参数我建议一开始就设置好：
LimitFindResults：限制C-FIND查询返回条数，默认0代表不限制，建议设为200，防止某个设备一次查询把所有数据拉走，拖垮服务器；LimitFindInstances：按实例数量限制查询范围，设为0表示不限制；DicomScpTimeout：设置DICOM SCP接收超时时间（秒），默认30，如果设备传输大文件经常中断，可以适当调大但要警惕异常连接占用资源。
隐私保护上有两个容易被忽视的配置。一个是DicomEchoChecksFind，它控制发起C-ECHO时是否需要带查询参数，很多设备实现不规范，建议保持默认。另一个是KeepAliveTimeout，它决定HTTP长连接保持时间，Web界面长时间挂机就会用到，默认30秒够用。真正的隐私保护要靠访问控制，也就是认证和网络层ACL，Orthanc自身没有用户权限分级。
4. 与影像设备对接和日常使用
4.1 设备端怎么配置AE Title和地址
DICOM对接的核心是双方协商AE Title、IP、端口。以一台CT设备为例，设备操作界面里通常有“DICOM设置”或“传输目标”的菜单，需要填写三项：
- 目标AE Title：填写Orthanc配置里的
DicomAet，也就是“ORTHANC”； - 目标IP地址：安装Orthanc的Windows主机IP；
- 目标端口：4242（与Orthanc配置的
DicomPort一致）。
同时设备自身也要有一个AE Title，例如“CT1”，这个值需要同步填到Orthanc配置的DicomModalities里面。只有双方都收录了对方的AE Title和地址，DICOM通信才能建立，相当于一次双向白名单确认。
DicomModalities格式如下：
"DicomModalities": { "CT-DEVICE": { "AET": "CT1", "Host": "192.168.1.50", "Port": 11112 } }这里的“CT-DEVICE”不是协议层概念，只是Orthanc内部给这台设备起的别名，便于在REST API里识别。Port填设备上DICOM接收端口，通常设备厂商默认是11112，但不同厂商不同型号可能不同，一定要从设备端确认。配置完后，可以先用curl调用REST API做一次C-ECHO：
curl -u myuser:mysafe-password http://127.0.0.1:8042/modalities/CT-DEVICE/echo返回{}代表连接成功，如果报错，按第5部分排查网络和防火墙。
4.2 用REST API和Web UI管理影像
Orthanc的Web界面默认在根路径/，登录后可以浏览患者、检查、序列和实例四种层级。界面虽然朴素，但对小团队来说够用。看到单个实例时，可以直接下载DICOM文件或转成PNG缩略图，免去额外装阅片软件。
REST API是比Web界面更常用的管理方式，因为可以脚本化批量操作。几个最常用的接口：
# 获取所有患者 curl -u myuser:mysafe-password http://127.0.0.1:8042/patients # 获取指定检查下的所有实例 curl -u myuser:mysafe-password http://127.0.0.1:8042/studies/{study-id}/instances # 上传单个DICOM文件 curl -u myuser:mysafe-password -X POST http://127.0.0.1:8042/instances --data-binary @image.dcm上传接口支持单次或批量上传，也支持FileSender方式（multipart/form-data）。批量导入历史DICOM目录时，我习惯用Orthanc的/instances接口循环POST，速度尚可，而且能直接获得新入库实例的唯一标识。
查询时注意URL里{study-id}不是设备上的“检查号”，而是Orthanc生成的内部ID，形如f4ab3c9e-1c2d-4c1a-8e5f-...。开发脚本时，先调用/studies拿到ID列表，再对每个ID做二次查询，不要试图用检查号在Orthanc REST API里直接检索，两者不是同一个概念。
4.3 开启DICOMweb和Web viewer
Orthanc从1.2版本开始支持DICOMweb，允许通过HTTP协议进行DICOM查询和检索，而不必依赖传统DICOM C-FIND/C-MOVE。这个功能在Windows下基本是“零配置”，由一组配置项控制：
"DicomWeb": { "Enable": true, "Root": "/dicom-web/" }启用后，浏览器输入http://127.0.0.1:8042/dicom-web/studies就能用GET请求查到检查数据，非常方便前端集成。要注意DICOMweb的启用会额外占用HTTP端口连接，如果Web界面已经有大量并发请求，建议单独用反向代理或分配不同端口。
Orthanc自带的/viewer路径也是一个亮点，可以在浏览器里直接以影像序列方式查看DICOM数据，不用安装任何插件。http://127.0.0.1:8042/viewer/study/{study-id}即可打开某个检查的视图界面。对Windows环境的小团队来说，这个内置查看器省了很多事，日常阅片基本够用，不需要额外部署专业图像工作站。
5. 常见问题与排查技巧实录
5.1 启动闪退、端口占用与防火墙
启动失败是最常见的问题，尤其是第一次使用的用户。闪退一般分三种原因：
配置JSON格式错误：在配置文件里多了一个逗号或整行最后少了一个逗号，Orthanc启动时解析失败就会退出。排查方式是把配置文件内容复制到任意JSON在线校验工具里检查一下，一般能快速定位到具体行。
端口被占用：装了其他医学软件或系统自带服务占用了4242或8042端口。CMD下执行：
netstat -ano | findstr 4242查到占用进程的PID后，再用tasklist /FI "PID eq [PID]"看是哪个程序，没问题的话可以换Orthanc端口或在系统服务里关掉冲突进程。
缺少运行库：前面提过，vcruntime140.dll缺失时程序会闪退，安装微软VC++运行库即可解决。还有一种情况是杀毒软件拦截了exe启动，需要在杀毒软体里把Orthanc目录加入白名单。
设备无法发送影像：Orthanc服务器正常启动后，设备端提示“设备和服务器握手失败”。检查Windows防火墙，确认入站规则放行了4242端口：
netsh advfirewall firewall add rule name="Orthanc DICOM" dir=in action=allow protocol=TCP localport=4242HTTP端口8042如果需要进行远程Web访问，也要一并放行。实测下来，Windows Server系统自带防火墙默认是全部拦截的，所以这一步不是可选项而是必做项。
5.2 中文路径、权限和日志排查
Windows上另一个高频坑是中文路径。Orthanc对UTF-8兼容性尚可，但当路径包含中文且系统区域设置不是UTF-8时，索引目录可能写入失败或乱码。稳妥方案是所有路径统一使用英文字母：
D:\OrthancData\storage D:\OrthancData\index D:\OrthancData\logs尤其是在注册为Windows服务后，服务账户的工作目录和解压目录不同，配置使用绝对路径才能避免找不到文件。
日志排查方面，Orthanc在命令行窗口会打印运行日志，但服务方式下看不到控制台。可以通过配置文件的"LogDirectory"字段把日志输出到文件：
"LogDirectory": "D:\\OrthancData\\logs"然后在日志文件里搜索ERROR或WARNING关键字，定位报错信息。日志级别默认是info，够用；如果需要更细的调试，可以临时把"Verbose": true加上，但生产环境不建议一直开着，日志量大而且影响性能。
5.3 性能与大影像量的取舍
Orthanc在Windows上的性能瓶颈通常不在程序本身，而在磁盘I/O和索引方式。遇到查询卡顿或接收影像超时，优先检查三件事：
- 存储目录所在盘是否是机械硬盘。机械盘在大量小文件DICOM写入时非常吃力，建议至少用7200转的企业盘或SSD；
- SQLite索引文件是否和DICOM文件在同一分区。尽量把索引目录放在独立的SSD上，可显著加快查询响应；
- 是否开启了
StoreDicomInstances之外的插件。如果加载了Osimis WebViewer等插件，内存消耗会明显增加，小内存Windows机器要谨慎。
如果影像量真的很大，Orthanc单机方案会很快到瓶颈。这时候可以先检查索引数据库是否切到PostgreSQL，再考虑横向扩展。但Orthanc设计上就不是一个分布式集群，它提倡多实例共享DICOM传输地址，然后用上层的DICOM路由做负载分摊。这种思路在小团队里反而比强行搞集群简单，毕竟大多数场景根本没有那么高的并发需求。
一条针对Windows服务化部署的建议：把Orthanc的进程优先级和服务恢复策略设置好。在NSSM里配置AppRestartDelay为5000毫秒，这样即使进程异常退出，5秒内能自动拉起，比Windows服务默认的恢复策略可靠得多。我见过不少服务长期运行后被系统补丁重启或内存波动干掉的情况，有了这个配置，至少能少跑几趟机房。
另一个容易踩的坑是Orthanc的数据库占用增长。有人把Orthanc当成“中转站”，传完数据不清理，导致索引越来越大，最后Windows磁盘满了才发现。我的习惯是在配置里设置"StoreDicomInstances": false，如果任务只是做C-FIND调度或临时路由，就不把数据落盘；但如果目标是归档，必须保持true并定期做数据导出备份，Orthanc本身不提供自动清理策略，这块责任得运维自己扛。
最后再分享一个小经验：改动配置文件前，先备份一份原始JSON，改动后用Orthanc.exe --dry-run（部分版本支持预检）或先在前台启动观察日志，确认无误再注册为正式服务。多次实测下来，这套流程在Windows上非常稳定，大多数问题都是配置上的一两个小失误，而不是Orthanc本身的问题。
