1. 从一次 DICOM 服务部署说起Orthanc 的 Web 层到底在做什么如果你正在做医学影像相关的后端开发大概率绕不开 Orthanc 这个名字。它是一款开源的轻量级 DICOM 服务器能把 PACS 里那些复杂的 DICOM 协议操作包装成一套 RESTful API 暴露出来。而撑起这套 HTTP 接口的正是它内置的 Web Server——Mongoose。很多刚接触 Orthanc 的朋友会有一个疑问我明明装的是 DICOM 服务器为什么配置文件里全是 HTTP 端口、静态目录、路由这些 Web 概念原因很简单Orthanc 的设计思路是把 DICOM 服务C-STORE、C-FIND、C-MOVE 这些和 Web 服务放在同一个进程里Mongoose 负责监听 HTTP 请求把/instances、/patients、/tools/find这类路径映射到内部的 DICOM 数据操作上。你通过浏览器或 curl 访问的每一个接口背后都是 Mongoose 在解析请求、Orthanc 在查库、再拼成 JSON 返回。这篇文章聚焦的是 Orthanc 内置 Web Server 的 Mongoose 配置骨架。我会把监听端口、路由规则、静态资源目录这几块配置拆开讲清楚给出可以直接复制的配置片段然后带你走一遍启动日志检查和 HTTP 接口连通性验证的完整动作。目标很明确让你看完之后能自己动手把 Orthanc 的 Web 层跑起来并且知道出问题时该看哪里。适合谁看正在部署 Orthanc 做 PACS 对接的后端工程师、需要给影像系统加 REST 接口的全栈开发、以及想理解 Orthanc 内部 Web 层工作方式的技术爱好者。不需要你精通 C但至少要能看懂 JSON 配置和基本的 HTTP 请求。2. 前置准备TaoToken 与 Orthanc 环境的关系在动手改配置之前先把两件事理清楚一是 Orthanc 本身的安装二是如果你后续要用大模型辅助排查配置或生成接口调用代码TaoToken 能帮你省不少事。Orthanc 的安装方式很多Linux 下可以直接用包管理器Windows 下有预编译的 zip 包Docker 镜像也很成熟。我建议先用 Docker 跑一个最小实例避免本地依赖污染docker run -p 8042:8042 -p 4242:4242 \ -v /your/data/path:/var/lib/orthanc/db \ jodogne/orthanc-plugins这里8042是 Orthanc 默认的 HTTP 端口4242是 DICOM 端口。启动后浏览器打开http://localhost:8042就能看到 Orthanc Explorer 的界面。这个界面本身就是 Mongoose 提供的静态资源加 API 组合。那 TaoToken 在这里扮演什么角色当你在调 Orthanc 的 REST 接口时经常需要写一些脚本去批量查询、转换 DICOM 标签或者让模型帮你解释某个接口的返回结构。这时候一个稳定的模型调用入口就很实用。TaoToken 提供统一的 API 接入你可以在它的控制台里创建 API Key然后用在你的调试脚本或 IDE 插件里。具体操作路径是这样的先到 TaoToken 控制台 注册并创建一个 API Key然后在 API Keys 管理页 复制你的密钥。如果你习惯在命令行里用 curl 调模型可以直接参考 接入文档 里的示例。需要说明的是TaoToken 的 API 端点是https://taotoken.net/api这个地址不加任何 UTM 参数直接用于程序调用。而上面那些带参数的链接是给你在浏览器里点开看文档和配置用的。如果你后续要做长期的编码辅助比如让模型帮你写 Orthanc 的 Lua 脚本或者 Python 调用代码可以考虑 Coding Plan它更适合持续性的开发场景。临时验证模型输出的话模型对话 页面就够用了。3. 可复制的 Mongoose 配置骨架端口、路由与静态目录Orthanc 的配置文件通常叫orthanc.json放在/etc/orthanc/或者 Docker 容器里的/etc/orthanc/。Mongoose 相关的配置项都集中在HttpServer和Http这两个段落里。下面这份配置是我在实际部署中反复调整后留下的骨架你可以直接拿去改。{ HttpServer: { Enabled: true, Port: 8042, BindAddress: 0.0.0.0, Threads: 4, RequestTimeout: 30, KeepAlive: true, SslEnabled: false, SslCertificate: , SslKey: , RemoteAccessAllowed: true, AuthenticationEnabled: true, RegisteredUsers: { orthanc: orthanc_password } }, Http: { StaticResources: { Enabled: true, RootDirectory: /usr/share/orthanc/explorer }, IndexFile: index.html, AllowDirectoryListing: false, HttpHeaders: { Access-Control-Allow-Origin: *, Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, Access-Control-Allow-Headers: Authorization, Content-Type } } }逐项拆解一下关键参数。Port是 Mongoose 监听的 HTTP 端口默认 8042你可以改成任何未被占用的端口。BindAddress设为0.0.0.0表示监听所有网卡如果只想本机访问就改成127.0.0.1。Threads控制 Mongoose 的工作线程数DICOM 查询并发高的时候可以适当调大但不要超过 CPU 核心数的两倍。StaticResources这一段是静态资源目录的配置。RootDirectory指向 Orthanc Explorer 的前端文件所在目录Docker 镜像里通常是/usr/share/orthanc/explorer。IndexFile指定默认索引文件Mongoose 会按顺序查找index.html、index.htm等。AllowDirectoryListing建议设为false避免暴露目录结构。HttpHeaders里的 CORS 配置很关键。如果你的前端页面和 Orthanc 不在同一个域名下不加这些头浏览器会直接拦截请求。我试过在本地开发时忘了配这个前端一直报跨域错误排查了半天才发现是这里的问题。路由方面Orthanc 的 REST 路由是内置的不需要你手动写映射规则。Mongoose 收到请求后Orthanc 会根据路径前缀分发到不同的处理器。比如/instances开头的走实例查询/tools/find走 DICOM 查询工具/system返回服务器状态。你唯一需要关心的是静态资源和 API 的优先级——Orthanc 会先匹配 API 路由匹配不到再去静态目录找文件。如果你需要自定义路由比如把某个路径重写到另一个接口可以在Http段里加UrlRewritesUrlRewrites: [ { From: /api/v1/(.*), To: /$1 } ]这个配置会把/api/v1/patients重写成/patients方便你做版本化的接口前缀。4. 启动日志检查与 HTTP 接口连通性验证配置改完之后重启 Orthanc然后盯一下启动日志。日志里会明确告诉你 Mongoose 有没有成功绑定端口、静态目录有没有加载。用 Docker 的话直接看容器日志docker logs -f orthanc_container_name正常的启动日志里应该能看到类似这样的行W: HTTP server listening on port 8042 I: Using static resources from /usr/share/orthanc/explorer I: Orthanc version: 1.12.1如果端口被占用日志里会出现bind: Address already in use这时候要么换端口要么把占用端口的进程杀掉。如果静态目录路径写错了会看到Cannot open directory之类的警告但 API 部分仍然能工作只是 Explorer 界面打不开。日志确认没问题后开始验证 HTTP 接口。先用最简单的/system接口探活curl -u orthanc:orthanc_password http://localhost:8042/system返回的 JSON 里会包含Version、DatabaseVersion、DicomAet等字段。如果返回 401说明认证配置生效了但你没带用户名密码如果返回 404说明路由没匹配上检查一下 Orthanc 版本和接口路径。接着验证 DICOM 相关的接口。假设你已经通过 DICOM 端口上传了一个实例可以用/instances列出所有实例curl -u orthanc:orthanc_password http://localhost:8042/instances返回的是一个实例 ID 的数组。拿到 ID 后查具体实例的标签curl -u orthanc:orthanc_password http://localhost:8042/instances/{instance_id}/tags这个接口会返回 DICOM 标签的 JSON 表示。如果你看到PatientName、StudyDate这些字段说明 Mongoose 的请求转发和 Orthanc 的 DICOM 解析都正常。再验证一下静态资源。浏览器打开http://localhost:8042/应该能看到 Orthanc Explorer 的界面。如果页面空白或者 404检查RootDirectory路径是否正确以及IndexFile指定的文件是否存在。最后测一下 CORS 头有没有生效curl -I -X OPTIONS http://localhost:8042/system \ -H Origin: http://localhost:3000 \ -H Access-Control-Request-Method: GET返回头里应该包含Access-Control-Allow-Origin: *。如果没有说明HttpHeaders配置没被加载检查一下 JSON 格式有没有写错。5. 本篇常见错误排查配置 Orthanc 的 Web 层时有几个坑我踩过不止一次这里集中列出来你遇到问题时可以对照着查。端口冲突导致启动失败。最常见的就是 8042 被其他进程占了。用netstat -tlnp | grep 8042或者lsof -i :8042查一下找到占用进程后要么杀掉要么在配置里换一个端口。注意 Docker 场景下还要检查宿主机的端口映射有没有冲突。认证配置写错导致 401 循环。RegisteredUsers里的用户名密码要和请求时带的一致。有些朋友在配置里写了AuthenticationEnabled: true但请求时忘了加-u参数结果一直 401。另外注意密码里如果有特殊字符JSON 里要转义。静态目录路径不对导致 Explorer 打不开。Docker 镜像和源码编译安装的静态文件路径不一样。Docker 通常是/usr/share/orthanc/explorer源码编译可能在/usr/local/share/orthanc/explorer。用find / -name index.html -path *orthanc*找一下实际路径。CORS 配置不生效。检查HttpHeaders是不是写在了Http段里而不是HttpServer段。这两个段落的层级不一样写错位置配置不会报错但也不会生效。另外注意 JSON 的逗号多一个少一个都会导致整个配置解析失败。修改配置后没重启。Orthanc 不会热加载配置文件改完必须重启进程。Docker 下用docker restart裸机用systemctl restart orthanc。日志级别不够看不到关键信息。默认日志级别可能过滤掉了 HTTP 相关的调试信息。可以在配置里加Verbosity: verbose重启后能看到更详细的 Mongoose 请求日志。如果你在排查过程中需要让模型帮你分析日志或者生成测试脚本可以到 模型对话 页面把日志贴进去问。长期做 Orthanc 二次开发的话Coding Plan 更适合你持续调用模型辅助编码。6. 继续深入从配置到源码把 Mongoose 的配置骨架跑通之后你对 Orthanc 的 Web 层应该有了一个直观的认识。它本质上就是一个轻量级 HTTP 服务器加一套路由分发逻辑把 REST 请求翻译成 DICOM 操作。这套设计的好处是部署简单、依赖少一个进程同时搞定 DICOM 和 HTTP。如果你还想往下挖下一步可以看 Mongoose 的事件循环是怎么和 Orthanc 的主循环整合的。Orthanc 在启动时会创建一个 Mongoose 上下文然后在主循环里调用mg_mgr_poll处理网络事件。DICOM 的 SCP 监听和 HTTP 监听跑在同一个事件循环里这也是为什么 Orthanc 的资源占用能控制得比较低。实际部署中我建议把 HTTP 端口和 DICOM 端口分开暴露HTTP 走反向代理加 TLSDICOM 端口只对内网开放。Mongoose 本身支持 SSL但生产环境更常见的做法是前面挂 Nginx 或 Traefik 做证书终止Orthanc 只监听本机 HTTP。配置调优方面Threads和RequestTimeout是两个值得关注的参数。并发查询多的时候线程数不够会导致请求排队超时设得太短大实例的标签查询容易中断。可以先按默认值跑观察日志里的请求耗时再调整。最后提醒一点Orthanc 的配置文件是 JSON 格式不支持注释。改的时候建议用jq校验一下语法jq . /etc/orthanc/orthanc.json /dev/null echo JSON valid语法没问题再重启能省掉很多无谓的排查时间。