用ConquestDICOMServer搭建DICOM测试靶场：从C-ECHO到C-MOVE全流程实战-北京尧图网络

简介面向开发者和系统管理员的 DICOM 通信测试工具包围绕 Conquest DICOM Server 提供完整的本地化部署与验证环境。Conquest 作为开源 DICOM SCP支持接收和存储医学影像、提供 worklist 工作列表服务并可通过匿名化脚本保护患者隐私适合在新设备接入 PACS 前做兼容性测试、性能评估或数据迁移演练。压缩包约 22.28MB文件总数未标注但包含批处理脚本、DICOM 字典、核心 DLL、可执行程序及 7-Zip 命令行工具等常用组件可协助快速启动服务、自动更新、Web 安装调试及数据匿名化处理。已有 718 人学习该资源适用于需要深入理解 DICOM 网络通信或维护医疗影像系统的中高级技术人员。通过这套工具可实际模拟 DICOM 设备交互掌握 SCP 配置、工作列表查询、日志监控等关键技能有效提升系统集成与故障排查效率。1. 为什么测试DICOM设备时我建议先搭一个 ConquestDICOMServer 当靶子开发DICOM客户端时最容易犯的错是一上来就在身边部署一套“正式配置”的PACS服务器。这个路线听着稳实际很痛安装流程长、数据库约束多、大多数日志默认关闭出了问题你会分不清是服务器没响应、网络中断还是自己发出的报文结构不对。这几年我验证DICOM Store、Query、Retrieve 和 Echo 链路反而固定用一个轻量级工具ConquestDICOMServer。它单进程就能跑配置文件是纯文本数据库可以选内置SQLite几分钟就能从空系统搭出一个能收图、能查、能取回的DICOM服务端非常适合当被测客户端的“测试靶子”。这篇笔记就从搭建、参数调优到常见坑给出一条照着做就能复现的路线。2. 用 ConquestDICOMServer 搭最小测试环境下载、配置和第一次 C-ECHO这一步的目标很单纯在十分钟内得到一个能正常应答的DICOM服务端。别急着调参数、别急着换数据库先把最小闭环跑通后面所有调试才有参照物。2.1 测试环境为什么选 Conquest而不是搭完整PACS完整PACS通常需要独立的数据库服务、多个后台进程和一套管理界面而你在测试DICOM客户端时真正需要的往往只是一个“行为符合DICOM协议的服务端”能接受Association、能收 C-STORE、能被 C-FIND 查到、能被 C-MOVE 取回。其他功能在这个阶段全是干扰项。我选 Conquest 做测试靶子有三个理由。第一重置成本极低配置写在文本文件里SQLite 数据库就是一个文件出了问题停掉服务删掉数据文件几秒就回到干净状态。第二日志可控调试级别调高后每个 Association 的建立和断开都能落到日志文件里不用抓包就能定位大部分问题。第三协议覆盖够用C-ECHO、C-STORE、C-FIND、C-MOVE 这套最常见的 DICOM 服务都能跑足够覆盖大多数客户端联调场景。对比维度完整PACSConquest测试环境部署时间小时级通常还要建库分钟级解压改配置即可配置文件分布在Web页面和多个服务配置中核心集中在 dicom.ini重置方式重新初始化数据库和服务停服务后删除数据库文件与图像目录日志默认不开放或级别很低打开 Debug 直接落文件协议覆盖全量常用 DICOM 服务全覆盖这张表不是为了贬低完整PACS而是提醒你测试阶段少背锅比功能齐全更重要。我见过不少同事在完整PACS上调环境配置花了三个小时最后发现客户端连不上根本不是代码问题而是服务端多实例端口冲突。用最小服务端做验证这类问题能少一大半。2.2 第一份配置文件dicom.ini 里需要改的五个地方不同平台的安装包不一样安装完成后核心配置文件基本都叫 dicom.ini部分版本会在首次启动时自动生成。打开它我一般只动五个内容端口、AETitle、SQLite 路径、是否落盘图像、调试级别。下面这份是我常用的最小配置形状。; 测试专用基础配置 TCPPort 5678 ; 主服务监听端口 AETitle CONQUESTSRV ; 服务端对外AE名称 SQLite D:\dicomsrv\data\dicom.db ; 测试库路径纯英文路径更稳 KeepImages 1 ; 保存接收到的DICOM文件Retrieve依赖它 Debug 2 ; 排错时连接级日志稳定后调回0每行的作用这样理解TCPPort 决定服务端监听在哪个端口我习惯用 5678 作为默认值因为高位端口不涉及系统权限冲突。AETitle 是服务端面向客户端的名字客户端发起连接时填的 Called AE 必须和它完全一致。SQLite 指向数据库文件位置Conquest 会用这个文件存 DICOM 数据的索引路径里不要带中文和空格否则容易出现启动即报错。KeepImages 决定接收到的图片是只写数据库索引还是同时把 DICOM 文件保存到磁盘做 Retrieve 相关测试时这条必须为 1。Debug 是给排错用的通道稳定运行时调回 0日志量差别很大。启动方式各平台不一样Windows 安装后一般会注册成服务或提供图形管理界面Linux 通常直接跑 dgate 进程。启动成功后观察日志里是否出现类似 Listening on port 5678 的字样比只看界面靠谱得多。如果这块都过不去先回到配置文件检查路径和端口不要继续往下做 Echo。2.3 用 echoscu 打通第一条 C-ECHO 链路服务起来以后最该做的第一件事不是推图而是发一条 C-ECHO。Echo 是 DICOM 最基本的握手客户端发起 Association服务端回一个成功状态。Echo 通了说明 TCP 层和 Association 协商都没问题后面做 Store、Query 才有意义。# 发一条C-ECHO验证Association能建立 echoscu -d -aet TEST_CLIENT -aec CONQUESTSRV 127.0.0.1 5678这条命令里-aet TEST_CLIENT 是本端AE随便取一个名字即可-aec CONQUESTSRV 是服务端的AE必须严格等于 dicom.ini 里配置的 AETitle大小写都不能错127.0.0.1 是服务端地址5678 是端口-d 打开调试输出能直接看到 DICOM 协议层的请求和响应。如果一切正常回显里能看到成功的状态码连接被 Accept。如果出现 Association Rejected不要先怀疑客户端代码去检查两件事AETitle 是否完全一致服务端进程是否真的在监听这个端口。先确认这两点再去看协议细节。Echo 成功以后你才算真正拿到了一个“能用”的测试靶子下一步才是把参数调明白。提示本机 Echo 都没通的话不要急着换端口、改数据库或调 Debug先确认服务进程和 AE 名九成问题都在这里。3. ConquestDICOMServer 的参数怎么设AETitle、端口、数据库和存储的边界最小环境跑通后真正的关键是理解 dicom.ini 里那几个参数为什么这么设。测试环境调参只有一个标准让每一个认证场景都能映射到明确的配置上而不是“改一改试试看能不能跑”。3.1 AETitle看似只是一行名字其实是连接的第一个安检口AETitle 全称是 Application Entity TitleDICOM 协议用它来寻址和协商 Association。它不是一个可以随便乱填的昵称长度有限制字符集有限制而且大小写敏感。我在测试里见过最多的连接失败就是服务端写着 CONQUESTSRV客户端填了 conquestsrv或者多了一个空格结果连接直接被拒。从协议行为看服务端的 AETitle 相当于一扇门客户端发起连接时必须准确报出名字名字对不上后面的 C-ECHO、C-STORE 根本不会开始。因此测试环境里我建议把所有参与设备的名词统一写入一份小表格比如客户端叫 TEST_CLIENT、服务端叫 CONQUESTSRV不要凭记忆填。多套测试环境同时存在时别都用 CONQUESTSRV 这个名字。我习惯在名字里带项目代号例如 AEDEMO1、AEDEMO2否则多个服务端在同一局域网里会互相踢连接排查起来很混乱。AE Title 是纯文本但它在 DICOM 里的作用相当于网络世界的门牌号值得多花一分钟保持一致。3.2 端口怎么选默认 5678 之外还要考虑多环境错开Conquest 默认监听 5678这个端口在老版本里几乎成了 DICOM 测试的代名词。单机联调时用它最省事因为所有客户端默认配置都指向它。但如果同一个局域网里有多套测试环境端口冲突就会变成第一个坑。我的做法是第一套环境直接用 5678第二套起加偏移比如 5679、5680。端口改完后客户端连接参数、防火墙放行规则、Conquest 的监听配置三处必须同步改少一处就是跨机器连不上的结果。这里经常翻车的地方是Windows 防火墙只放行了默认的 5678换到 5680 以后本机通、跨机器不通看日志又一切正常很难定位。参数测试建议值影响范围AETitleCONQUESTSRV 或项目代号客户端 Called AE 必须一致TCPPort5678多环境错开监听端口、防火墙放行、客户端地址SQLite纯英文路径下的文件地址索引存储位置重置时直接删文件KeepImages排错阶段建议 1是否落盘DICOM文件影响RetrieveDebug排错 2稳定 0dgate.txt 日志量磁盘占用端口选择还有一个原则尽量不用 1024 以下的系统端口也不要用其他软件高频占用的端口。DICOM 测试客户端一般不会特别处理端口冲突错了直接超时这种行为容易被误判成“服务端挂了”。我一般会在改完端口后先跑一次本机 Echo再跑一次跨机器 Echo两次都通才认为端口切换完成。3.3 数据库选 SQLite 还是 MySQL测试阶段边界在哪Conquest 支持多种数据库后端但测试阶段我强烈建议先留在 SQLite。它的优势是零运维配置里写一条 SQLite 路径服务起来自动建库重置就是停服务、删文件、再启动几十秒回到干净状态。SQLite 是单文件数据库查询逻辑简单出问题时可以直接用数据库工具打开看索引不用绕到数据库服务器上查日志。MySQL 适合什么场景多人同时压测、需要所有人看到同一份测试数据、或者测试环境被多个客户端共享时MySQL 确实比 SQLite 稳。但它的代价也摆在明面上要建库、要建账号、要处理网络权限DICOM 层面的问题还会和数据库连接问题搅在一起定位难度直接翻倍。维度SQLiteMySQL初始化成本配置文件写路径即可需要手工建库、授权并发能力单写多读足够单机联调多连接并发更稳重置方式删库文件重启清理数据表或重导备份故障排查一个文件逻辑简单故障点可能在数据库连接层一个人测试时上 MySQL多半是给自己找麻烦。我见过有人折腾半天连不上最后发现是 MySQL 账号 host 限制没放开这跟 DICOM 协议一点关系都没有。测试环境要的是可控和可重置SQLite 在这两点上远比 MySQL 合适。3.4 KeepImages 和 Debug 日志两个最容易被忽略的设置KeepImages 这个参数很特殊它藏得深但决定了 C-MOVE 能不能取回数据。当 KeepImages 为 0 时Conquest 收到 C-STORE 的图片后只写数据库索引不把 DICOM 文件落盘。此时你用 C-FIND 能查到记录因为索引在但 C-MOVE 要求服务端把文件传回来时服务端没有文件可传结果就是查询有数据、取图拿不到。我做测试的习惯是一开始就把 KeepImages 设为 1让每个推入的 DICOM 文件都能在图像目录里看到实体文件。这样验证链路时多了一种手段直接数磁盘上的 .dcm 文件对比数据库记录数量能快速判断服务端是在正常收图还是只登记了索引。Debug 日志是另一个常被忽略的点。Conquest 的日志文件通常是 dgate.txtDebug 为 0 时只记关键事件为 2 时会记录每个连接的细节。排错时开 2日志里能看到 Association 的建立、拒绝、释放全过程。不排错时记得调回 0否则经常跑测试的机器磁盘会被日志撑满。这个文件是排错第一现场出问题先翻尾部比抓包快得多。4. 用 ConquestDICOMServer 最常见的 5 类问题排查从AET、端口到取不回图测试环境的问题没有太多玄学大多是配置映射错了。下面这五类我都实际遇到过每一条按“现象、原因、解决”来拆。4.1 Echo能通Store却返回 Association Rejected现象echoscu 一切正常改用 storescu 推图时报出 Association Rejected 或类似拒绝信息客户端日志停在连接建立阶段。原因C-ECHO 是基础服务很多发行版默认开放C-STORE 则依赖服务端是否启用了对应的 SOP Class 服务。如果服务端只开了基础服务没开存储Echo 自然通推图就会被拒。解决回到 dicom.ini找到与 Store 服务相关的开关确认存储服务已启用同时确认图像目录存在且有写权限。改完配置后重启服务再跑一次 storescu。记住Echo 通不代表所有服务都开了这是两码事。4.2 本机Echo通跨机器Echo超时现象在服务端本机用 127.0.0.1 测试正常换到局域网另一台机器上测试就超时TCP 层看起来都不通。原因最常见是防火墙只放行了部分端口或网络类型特别是 Windows 默认防火墙对入站连接的控制较严另一可能是 Conquest 配置里绑定的地址还是 localhost没有监听真实网卡。解决先把防火墙规则里对应 TCP 端口放行注意区分专用网络和公用网络再确认 dicom.ini 里绑定的地址不是仅回环地址。改完以后从另一台机器重新发 C-ECHO通了才算是真正对外提供服务。4.3 服务启动后立即报错日志出现SQLite相关异常现象服务进程起来一下又退出dgate.txt 或控制台出现数据库相关报错界面状态显示异常。原因SQLite 路径写到了带中文或空格的目录里部分内置包在路径解析上确实不给力启动时数据库初始化失败服务只能退出。这个坑看起来像配置错实际是基础环境问题。解决把安装目录和数据目录全部换成纯英文、无空格的路径例如 D:\dicomsrv\data\dicom.db。改完删除旧的数据库文件重新初始化不要试图在原路径上反复改配置换路径是成本最低的做法。4.4 C-STORE推图成功但C-MOVE取不回文件现象用 storescu 推图返回成功C-FIND 也能查到记录但 C-MOVE 请求后客户端收不到图片或服务端日志显示无法发送文件。原因KeepImages 被设成了 0。服务端只保存了索引没有把 DICOM 文件写到磁盘。查询能走索引完成取图需要文件实体时就没有东西可发。解决把 KeepImages 改为 1推入新图后去图像目录看是否真的生成了 .dcm 文件如果之前推进去的老数据只有索引没文件重新推一遍。这个坑很隐蔽因为它不会破坏前面的服务只会在 Retrieve 阶段暴露。4.5 中文病人信息变成问号或乱码现象客户端用中文填 PatientName查询回显变成 ??? 或乱码数据库里存的文本也不对。原因Conquest 对部分文本字段按单字节字符集处理客户端发送时使用的字符集和服务器不一致时中文字段就会在传输中丢失信息。解决测试数据统一用英文或拼音避免把中文字段作为验证重点如果必须验证中文流程需要确认客户端是否正确声明了 DICOM 字符集。保守方案是在测试环境里回避中文文本把重点放在图像传输和查询取回逻辑上这能省下大量字符集排查时间。5. 我把 ConquestDICOMServer 当测试工具的日常批量推图脚本与文件级验证服务端稳定后我不再只用图形界面手动验证而是把回归流程脚本化。手动点按钮验证一次可以反复点十次就是浪费。# 批量C-STORE遇到失败打印文件名和状态 for f in /data/dicomsamples/*.dcm; do storescu -aet TEST_CLIENT -aec CONQUESTSRV 127.0.0.1 5678 $f || echo FAIL $f done这段脚本把整个测试样本目录逐个推给 Conquest失败了会指出具体是哪个文件。顺序执行速度一般但足够冒烟。样本多了以后脚本只用作回归入口判断系统是否健康的最终标准是文件落盘情况而不是推图是否返回成功。# 统计服务端实际落盘的DICOM文件数 find /data/dicomsrv/images -type f -name *.dcm | wc -l“服务端说成功”不如“磁盘上数得到”可靠。如果客户端推了 100 张Conquest 日志显示 100 次成功但磁盘文件数不到 100那就要回到 KeepImages 参数查一遍看看是否发生了只写索引不落盘的情况。这个习惯帮我在回归测试里抓到了不少“看似成功”的假阳性。上一段时间我为了一个 MOVE 取不回来的问题查了很久日志显示查询有结果服务端就是回不了文件。折腾到深夜才发现是之前调参时把 KeepImages 改成 0 忘了改回去数据库里有索引磁盘上没有文件。从那以后我每次动完配置文件都会顺手看一眼这个参数再开始测试宁可多花十几秒确认也不要半夜怀疑 DICOM 协议本身。希望帮到你。本文还有配套的精品资源点击获取

用ConquestDICOMServer搭建DICOM测试靶场：从C-ECHO到C-MOVE全流程实战

相关推荐

Node.js+Vue构建大学生国学自主学习平台：环境配置到部署全指南

astropy 坐标变换性能优化：数组化 SkyCoord、广播机制与大批量 obstime 的天体测量插值

DevSpace 命令行指南：devspace render 渲染部署清单而不触碰集群

更多资讯

Windows上部署Diffy：差分测试工具实现接口回归对比

React Native开发OpenHarmony应用：大文件上传断点续传实践

Linux 下 chmsee 阅读 CHM 文档：编译依赖、中文乱码修复与替代方案

Unity鱼眼Shader实战：从投影原理到性能优化

OpenClaw 安装卡在 libsignal？两个模块的编译与排查指南

Alation MCP Server接入实战：让AI Agent读懂企业数据元数据

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？