前段时间我捣鼓了一个叫 GhostTrack 的开源网络信息查询工具顺手把它部署到了一台服务器上。折腾完之后的整体感受是这类自部署工具比直接用在线网页端要爽太多了。网格信息收集不再是一个一个页面手工切换也不再担心查询记录说没就没、数据全躺在别人服务器上。如果你也在做网络信息溯源、资产摸底、链路追踪这类工作GhostTrack 很值得花一个下午把它跑起来。这个项目本质上是把域名解析、IP 归属、端口探测、TLS 证书信息、历史变更记录这些网络公开数据聚合到一个统一的 Web 面板里并带有“追踪”能力它会记录每次查询的历史比对变化能在域名过期、证书到期、解析变更时主动提醒你。换句话说它把“查一下”变成了“持续盯着”而这一切都构建在自己服务器上数据可控、接口可扩展。适合的人群非常明确运维工程师、安全蓝队同学、SRC 信息收集爱好者以及所有喜欢折腾服务器的朋友。1. 为什么用服务器自建 GhostTrack1.1 这个工具到底解决了什么问题先聊一个最现实的问题市面上的在线网络查询工具还少吗不少各家都做得挺漂亮。但真正用起来痛点也是扎扎实实的第一功能太分散。查域名解析要开一个站查 IP 归属又要换一个站查端口和证书状态还得再换一个。信息收集本身就强调“多源交叉”这种割裂式查询会让你在十几个标签页之间来回切效率非常低。第二历史数据存不住。在线工具大多数只给你“当下”的结果你今天查了想对比三个月前这个域名解析指向哪里基本没戏。而网络信息追踪恰恰是最依赖历史记录的没有历史数据就无法做趋势判断。第三数据隐私不受控。这个点很多人容易忽略。你在别人平台上输入一堆域名和 IP 去做查询这些查询记录本质上已经不属于你了平台方如何使用这些数据是你完全无法控制的。对从事安全分析、SRC 信息收集的人来说这其实是个挺大的隐患。第四接口集成不方便。在线工具就算提供 API也大多是付费功能或者有严格的频率限制。自动化脚本想调一个批量查询接口经常被限得很难受。GhostTrack 这类自部署工具解决的问题就是这四点它把该有的查询能力聚合在一个面板里历史数据存在你本地的 SQLite 数据库所有记录都在你自己的服务器上而且完全开源你可以直接看源码也可以按需扩展接口。一句话总结它把“查询工具”升级成了“数据库 分析面板 告警系统”的组合体。1.2 部署形态与场景适配分析既然决定自建第一步要想清楚部署在哪。结合我自己的经验两种主流形态可以做个对比部署形态优点缺点适合场景公网云主机随时随地访问、可长期稳定运行、方便对接告警需购买服务器、需注意安全加固重度使用者、团队协作、长期追踪监控内网小主机NAS、旧笔记本、开发板零额外成本、数据完全在内网无公网地址时只能内网访问、家用宽带稳定性有限个人实验、内网资产梳理、学习研究就我个人的建议来说除非你只是纯粹想跑通流程感受一下否则直接上一台最低配的云主机是最省心的方案。GhostTrack 本身对资源要求不高1 核 1G 也能跑但考虑到系统本身和日常查询任务2 核 4G 的机器用起来会比较从容。这里要特意提醒一个坑如果你选择在云主机上部署服务器所在地区和数据合规问题需要有基本判断只处理合法合规的公开信息查询场景就够了。我个人只把 GhostTrack 用于自己业务范围内、已获得授权的信息资产梳理这一点在你上手之前需要有同样的认识。2. 环境准备与部署流程2.1 服务器选型与前置检查清单我这次部署用的是一台 2 核 4G 的云主机操作系统选的是 Ubuntu 22.04 LTS。这套组合是比较稳的Ubuntu 的软件源够新碰到问题也容易搜到答案。如果你更习惯 Debian 12 或者 CentOS Stream也完全可以部署步骤大同小异。系统准备好之后我建议花两分钟做一遍前置检查避免后续折腾半天发现是环境问题确认系统时间正确。这一点很多人会忽略时间偏了会导致证书校验失败、日志时间错乱后面排查起来非常闹心。确认 Docker 环境就绪。GhostTrack 官方推荐的部署方式就是 Docker这也是最省事的方式。确认防火墙 / 安全组放行了需要用到的端口。默认 Web 端口 8080如果要用 HTTPS 就额外放行 80 和 443。确认磁盘分区有余量。GhostTrack 会把查询历史存在本地 SQLite 里随着使用时间增长数据会越来越大建议给/opt这类部署目录预留至少 10G。装 Docker 没什么好说的官方脚本一行命令就能搞定。如果你用的国内机器记得顺手配置一下镜像加速器不然拉镜像会等到怀疑人生。curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun sudo systemctl enable --now docker docker --version提示有些云厂商的安全组规则默认是全关的你在系统里把防火墙关了也没用一定要去云控制台确认安全组放行了对应端口这属于云服务器特有的一个大坑。2.2 用 Docker Compose 一键拉起服务GhostTrack 提供官方的 Docker 镜像配合 Docker Compose 部署最省心配置文件也方便版本管理。下面是我实际使用的一份 compose 文件你可以直接抄作业version: 3.8 services: ghosttrack: image: ghosttrack/ghosttrack:latest container_name: ghosttrack restart: always ports: - 8080:8080 volumes: - ./data:/data environment: - GT_DB_PATH/data/ghosttrack.db - GT_LOG_LEVELinfo - GT_TZAsia/Shanghai healthcheck: test: [CMD, curl, -f, http://localhost:8080/healthz] interval: 30s timeout: 5s retries: 3逐个解释一下我为什么这么写。restart: always保证服务器意外重启后容器能自动拉起这对长期追踪任务来说是基本要求。./data:/data的数据卷挂载是整个部署的核心GhostTrack 的 SQLite 数据库、日志、导出文件都存在这里以后升级容器时数据不会丢。GT_DB_PATH指定数据库文件名GT_TZ是时区设置不设的话日志时间会跟本地时间差 8 个小时看日志时很容易犯迷糊。实际部署命令就三条mkdir -p ~/ghosttrack/data cd ~/ghosttrack vim docker-compose.yml docker compose up -d启动完成后用docker compose logs -f ghosttrack看看日志有没有报错。确认没有异常后浏览器访问http://服务器IP:8080就能看到登录界面了。第一次进入会让你创建管理员账号创建完之后记得立刻去设置里把默认密码策略打开强制使用强密码。2.3 反向代理与 HTTPS 配置强烈建议加装如果你的 GhostTrack 要长期用或者需要公网访问我强烈建议在它前面加一层反向代理并配好 HTTPS。这不光是为了好看更是为了安全面板上的查询记录和配置信息都是敏感数据不加密的 HTTP 协议等于在网络上裸奔。推荐用 Caddy 做反向代理因为它会自动申请和续期证书配置也极其简单。Caddy 的配置只有一个Caddyfilegt.example.com { reverse_proxy 127.0.0.1:8080 encode zstd gzip }然后启动 Caddy 容器让它映射 80 和 443 端口把gt.example.com解析到服务器 IP证书会自动搞定全程不需要手动干预。如果你更习惯 Nginx也可以手动配置但那你得自己处理证书申请和续期费时费力不说还容易漏掉续期任务。注意我用的是127.0.0.1:8080而不是服务器公网IP:8080。这是故意这么写的——反向代理和 GhostTrack 容器在同一台机器上走内网回环地址就够了没有必要把 8080 端口暴露到公网。配置好反代之后建议在云安全组规则里关掉 8080 端口的公网访问权限只留 80 和 443 给外部流量。另外一个小技巧部署完 HTTPS 后去 GhostTrack 面板的设置里把“外部基础 URL”改成https://gt.example.com否则后台生成的一些链接可能还是 http 开头的点击跳转时会报警告。3. 核心功能解析与实操要点3.1 一站式信息查询域名、IP 与证书状态GhostTrack 的主界面设计得很干净左侧是功能导航中间是查询输入框右侧是结果展示区。我第一次用的时候输入了一个域名点查询整个过程让我有点意外——它不只返回了域名当前的解析记录还自动交叉关联了 WHOIS 信息、常见子域名、关联 IP 的归属情况和端口开放状态最后还生成了一张简单的信息图谱。具体来说它的查询主要覆盖这几个层面域名层A/AAA/CNAME/MX/NS/TXT 记录、WHOIS 注册信息、注册商和到期时间。IP 层地理归属、网络运营商、同一 IP 上绑定的其他域名。服务层常见端口开放状态、TLS 证书链信息、证书有效期。图谱层把上面这些实体之间的关系可视化一眼看明白“哪个域名指向哪个 IP哪个 IP 上还有哪些域名”。实操的时候有一个心得这个工具特别适合做“由点及面”的扩展查询。比如你先查了一个主域名看到图谱里出现了好几个关联子域名接着点子域名再查一层往往就能把整个资产边界摸清楚。这种层层递进的查询方式在在线工具里几乎不可用因为各家数据不互通在 GhostTrack 里就是鼠标点几下的事。3.2 “追踪”到底是怎么实现的历史记录与变更检测GhostTrack 名字里的 “Track” 不是白叫的。它的追踪能力建立在两条线上一条是查询历史的完整留存另一条是基于历史记录的变更检测。查询历史这块它不像普通浏览器那样只留个缓存而是把每次查询的关键字段都结构化存进 SQLite。比如你月初查了一个域名记录下它指向 IP A月底再查一次指向 IP B。系统会自动把两次结果做对比在“变更记录”页面里标出哪一条记录从什么值变成了什么值。这个功能在做资产追踪时极其关键——域名抢注者最怕的就是这种持续对比的工具。变更检测的另一半是主动告警。你可以为特定的域名或 IP 设置监控任务系统按设定频率定时去重新查询一旦发现变化就把事件推送到你配置的 Webhook 地址。下面是我在“告警设置”页面里填写的一个示例配置{ events: [domain.expire, cert.expiry, ip.change, dns.change], webhook: https://你的通知服务地址/webhook/ghosttrack, threshold_days: 30 }翻译成人话就是域名快要过期了、证书还剩不到 30 天、IP 解析发生变化、DNS 记录有改动这些事件发生时自动往我配置的 Webhook 地址推送一条消息。Webhook 可以接很多地方企业微信机器人、钉钉群机器人、飞书机器人都可以。配置成功后你可以在“监控状态”页面看到每个任务的最近执行时间和下次执行时间。提示设置监控任务时频率别太激进。有些公共 DNS 服务器和 WHOIS 服务对频繁查询有限流策略过于激进的查询频率容易把自己的 IP 封掉。我实测下来域名类监控设成 4 到 6 小时一次IP 类设成 1 小时一次已经能满足绝大多数追踪需求。3.3 数据持久化与备份恢复前面说过GhostTrack 的数据都存在 SQLite 文件里挂在./data目录。这个设计的优点是小巧、零外部依赖但缺点也很明显单文件数据库怕磁盘损坏也怕误删除。所以数据备份这件事必须从一开始就养成分级习惯。最基础的备份就是直接复制数据库文件。我在宿主机上写了一个简单的备份脚本配合 crontab 做每日备份#!/bin/bash BACKUP_DIR/opt/backup/ghosttrack DATA_DIR/opt/ghosttrack/data mkdir -p $BACKUP_DIR cp $DATA_DIR/ghosttrack.db $BACKUP_DIR/ghosttrack-$(date %F-%H%M).db find $BACKUP_DIR -name ghosttrack-*.db -mtime 30 -delete脚本逻辑很简单把数据库文件复制到备份目录文件名带上时间戳同时自动清理 30 天前的旧备份。把这个脚本挂到 crontab 里每天凌晨两点执行一次0 2 * * * /opt/scripts/backup_ghosttrack.sh恢复的时候更简单把备份文件复制回./data/ghosttrack.db然后重启容器即可。整个恢复过程不需要任何额外工具这是单文件数据库的一个巨大优势。4. 常见问题与排查技巧实录4.1 容器反复重启日志提示“permission denied”这是我第一次部署时踩到的第一个坑。我按照文档把数据目录挂好启动容器结果发现它一直处于 Restarting 状态。docker compose logs一看日志里报的是 SQLite 数据库初始化失败提示没有权限。原因是宿主机上./data目录的属主和容器内进程的用户不匹配。解决方案非常简单先chmod改权限再重启chmod 777 ~/ghosttrack/data docker compose down docker compose up -d后来我查了一下 GhostTrack 的镜像文档容器内默认是以uid1000的用户运行的所以更稳妥的做法是sudo chown -R 1000:1000 ~/ghosttrack/data这个改完之后容器就稳定了。以后遇到类似的权限问题第一反应不是乱猜而是docker inspect看镜像里声明的用户信息。4.2 公网访问不通但本地用 localhost 正常服务器上明明一切正常本地 curllocalhost:8080也有响应但浏览器访问公网 IP 就是不通。这个问题的排查顺序非常固定我按以下四个步骤操作第一步确认服务端口有没有监听在0.0.0.0上ss -tlnp | grep 8080如果监听地址是127.0.0.1:8080那容器外的公网流量自然进不来需要检查 compose 文件里的 ports 映射是否写成了127.0.0.1:8080:8080。第二步确认云厂商安全组放行了端口。很多人会忽略这一步因为安全组和系统防火墙是两层东西安全组是云控制台里设置的系统防火墙是服务器内部的。第三步确认系统防火墙没有拦截端口。第四步如果是按我前面说的配置了反向代理检查 Caddy 或 Nginx 是否正常运行监听端口是否对应上了。这个顺序很关键如果你先查系统防火墙发现没开可能就以为万事大吉了结果云安全组还是拦着的彻底排查一遍往往只需要五分钟。4.3 查询接口偶尔超时有些域名查不到信息GhostTrack 的查询依赖上游数据源比如公共 DNS 服务器、WHOIS 服务、证书透明度日志。这些上游服务偶尔会抖动就会导致查询接口超时。我遇到的几次超时基本都是某个公共源临时限流导致的。解决方案有两个方向。第一个方向是做配置优化在面板的“数据源设置”里可以配置多个备用上游源当主源超时后自动切换备用源实测下来稳定性有明显改善。第二个方向是降低查询频率尤其是批量导入大量域名时建议分批导入每批之间间隔几秒避免短时间内对上游源造成冲击。另外有一个概念必须澄清GhostTrack 的价值不在于实时性而在于持续性和历史对比。对于偶尔一次的超时不需要过度反应下次查询时数据会自动补齐。如果某个域名长时间查不到信息先去查一下上游源的可用状态再确认这个域名是否真的存在公开记录。查不到信息有时候也是信息本身的一部分。4.4 查询结果和图谱不完整怎么办图谱不是凭空生成的它的底层逻辑是根据 DNS、IP 归属、WHOIS 这些公开数据去做关联。如果查询结果很“单薄”大概率是数据源没有覆盖到相关记录或者查询的目标信息本身就不活跃。这种情况下我建议先把查询目标换成域名本身看看基础解析记录有没有正常返回如果只是某个子域名查不到试着查询它的主域名再在主域名的图谱里找关联关系。GhostTrack 的图谱设计逻辑就是“由主到子、由面到点”的展开方式利用好这个机制能大大提升信息收集效率。网格工具自建的经验小结把 GhostTrack 跑通之后我最大的感受是工具本身不难难的是形成一套“持续追踪”的工作习惯。查询记录只有一次并不可靠真正有价值的是那些积累了几个月甚至半年的历史数据——这些数据能告诉你变化的方向、频率和趋势而这些恰恰是单次查询永远给不了你的。我目前的生产用法是把 GhostTrack 作为团队的安全资产底账系统每新增一个域名或 IP顺手录入监控任务证书快到期前 30 天Webhook 自动告警到群里每周五看一眼变更报告把异动记录单独提出来分析。整个流程跑顺之后基本不需要每天手动登录查看系统在后台默默守着资产状态只在需要的时候主动发声。如果你也打算部署这套工具我有两条实战建议。第一数据合规意识前置用 GhostTrack 只处理自己有权限查询、有业务必要性的公开信息它是一款效率工具不是让网络行为无限扩张的“放大镜”。第二先把备份做好再谈其他数据库文件是你追踪结果的唯一载体有了稳定的备份机制后续的一切分析才有根基。折腾完这一整套流程你会发现“信息查询与追踪”这几个字其实是由很长的时间线组成的日常工作而 GhostTrack 就是那个帮你把时间线攒起来的容器。