这个 ARL 二开版确实能打，但二开全藏在一个非默认分支里

先说结论：代码是真的，功能是真的，二开也是真的。但它把二开藏在一个非默认分支里，你 git clone 下来的那份，跟上游一模一样。

这话可能不中听，但材料摆在这儿——我把两个仓库的每一个 blob 的 SHA 都比对过了。

本来我准备直接写”这个二开版有多强”，结果第一步就卡住了：它的 main 分支 HEAD 停在 2026 年 10 月 23 日，提交信息、内容、README 字节数，全部与上游 owl234/ARL-Next 的 v1.4.3 标签完全一致。

所以我先讲这件事，再讲它到底加了多少东西。因为顺序反过来，你装完会发现货不对板。

一、默认分支 = 上游 v1.4.3 的原样镜像

我把两边的 git tree 拉下来逐个文件对 SHA：

• 分叉仓库 buddingworld/ARL-Next2 的 main：640 个文件
• 上游 owl234/ARL-Next 的 main：686 个文件
• 其中 545 个文件 SHA 完全相同，0 个是分叉独有的文件

最直接的证据是 README：分叉仓库的 README 是 30464 字节，上游 v1.4.3 标签下的 README 也是 30464 字节，diff 出来是完全一致，一个字符都没改。

再看提交历史。分叉仓库 main 上最近 20 个提交，我逐个拿去上游 API 查，20 个全部返回 200——它们本来就是上游的提交。作者分布是 owl234 15 个、WeilianC 5 个（都是上游的 merge PR）。

也就是说，这个”二开版本”的默认分支，本质上是上游代码的一份定时快照。

那二开的东西在哪？在 HSBranch 分支。

这个分支比 main 领先 17 个提交，最后一次提交是 2026-11-04。你要用二开功能，得先 git checkout HSBranch，或者干脆从 Releases 里找有没有打包好的。

这一步没人告诉你，但它决定了你装完之后看到的界面跟作者截图一不一样。

二、真正的二开清单，我全列出来

HSBranch 相对 main 改了 51 个文件。剔除前端资源和国际化文件，真正有技术含量的是这几块：

① 0.zone（零零信安）接入，做子域名和公众号/小程序资产。

新增了 dns_query_plugin/zerozone.py 和一个客户端。我读了源码，接口是 POST https://0.zone/api/data/，鉴权用请求体里的 zone_key_id 字段——不是 HTTP 头，这个细节踩过坑的人应该懂。代码注释里还写了跟 yaklang 的 spacengine/zone 实现交叉核对过，查询语法是 字段==值 这种形式。

而且它把小程序、公众号的资产拆成了”ICP 备案”和”0.zone”两条路，字段补齐后给了专用列。这个改动很务实——ICP 只查得到备过案的，0.zone 能补到没备案的。

② 天眼查凭据不可用时的兜底：走微信小程序端接口。

这块是 11 月 4 日最后一个提交，也是这篇标题里”打通天眼查”最硬的部分。

代码在 tycMiniClient.py，走的是 capi.tianyancha.com/cloud-tempest/app/searchCompany，请求头带 Version: TYC-XCX-WX、xweb_xhr: 1，UA 伪装成微信小程序客户端。作用只有一个：拿公司名换 GID。

作者自己在注释里写得很坦白：

接口实测匿名可用（无需 Authorization），但属于非公开接口，可能触发风控或随时失效，故仅作兜底。

这句话我给它点赞。做安全的人肯在代码里写清楚”这是非公开接口、会失效、只当兜底”，比写一堆”业界领先”强一百倍。

③ 多用户与用户管理。

加了 UserManagePanel.vue，改 user.py 166 行。普通用户看不到用户管理入口。对一个团队共用的资产平台来说，这是刚需——原来 ARL 只有一个 admin，谁登录都是上帝视角。

④ 源码模式部署文档（A 模式，完全脱离容器）。

新增 deploy/source/ 一整套：四个 systemd unit（web / worker / osint / puppeteer）、nginx 配置、start-worker.sh，加一份 648 行的 README。

这份文档的质量超出我预期。它明确写了四件事：

• 服务必须以 root 运行，因为 nmap 的 SYN 扫描和 massdns 发 DNS 包都要 raw socket 权限。非 root 会让 nmap 静默降级成 TCP connect 扫描——更慢、结果更少，而且不报错。
• RHEL/CentOS 系 SELinux Enforcing 下会踩四个坑，每个坑的现象和真实原因都列了表：203/EXEC 是 user_tmp_t 上下文、nginx -t 报权限、5173 不在 http_port_t 里、登录接口 502 是 httpd_can_network_connect 关着。
• Ubuntu 的 chromium 是 snap 包装壳，路径行为不一致，建议换 Debian 或 RHEL 系。
• 源码模式下一键更新和备份恢复是有意移除的，Basic Auth 那个开关会置灰——因为它调的是 updater 守护进程。

能把这些写出来，说明作者真在一台裸机上从头装过一遍。这类文档比功能更值钱。

⑤ 任务批量导出加”子域名:IP”模式，移除”支持作者”入口。

后者是个小细节但挺说明态度——把打赏弹窗删了。

三、架构上，它确实解决了一个真问题

抛开二开，这个项目的底子是上游 ARL-Next 的重构，我读 README 和配置文件确认了下面这些。

经典 ARL 的老毛病是做大规模扫描时任务队列堵死、跑久了内存涨、假死。这个重构版的解法是把队列劈开：

• arltask_light：空间测绘、单点更新、WIH 接口挖掘
• arltask / arltask_heavy：常规扫描、风险巡航、Nuclei、PoC
• arlgithub：CVE 监控、GitHub 代码泄露

三条队列三组 worker，互不干扰。重扫描把 heavy 堵死，不影响轻量任务。

更关键的是 OSINT 走的是 HTTP 直调，根本不进 Celery 队列。备案查询和企业图谱采集天生慢、容易超时、还会被 WAF 拦，扔进扫描队列就是灾难。它被拆成独立微服务（端口 16181），Backend 用 HTTP 调它，带 5 秒超时保护。

配套的还有几个：截图渲染单独一个 Puppeteer 微服务（5005）并做了请求计数轮转；autoheal 探针定时探活 worker 容器、异常自动重启；MongoDB 7.0 高频写入走 bulk_write 批量接口，核心集合配联合唯一索引。

这套组合拳是”用工程把不稳定因素隔离开”，思路正确。它不假死不是因为玄学，是因为慢的东西被挪出了队列。

四、天眼查那条链路，到底怎么串起来的

标题里说”打通天眼查/ICP → 资产发现 → 漏洞扫描 → 威胁情报追踪”，这条链路在代码里确实存在：

① 输入企业工商全称 → 自动检索匹配天眼查 GID ② 股权穿透，对外投资逐层下钻，构建集团多级图谱 ③ ICP 备案检索，覆盖网站 / APP / 小程序 / 快应用四类（注意是四类，很多工具只做网站） ④ 资产发现：域名 → IP → 端口 → 指纹，内置 8800+ 条 Web 指纹库 ⑤ 漏洞扫描：Nuclei 模板 + Python 原生引擎的 PoC / 弱口令 / 服务识别插件池 ⑥ 威胁情报：CVE 同步 + GitHub 代码泄露监听，用数据库原子更新锁去重

结果落到”资产组”这个统一容器里，13 个维度的画像抽屉从资产组往下钻。

这个设计比”一个企业一个任务”要好——它是按组织架构组织的，集团下面挂子公司，子公司下面挂资产组，资产组里才是资产。做红队或者做甲方资产清点的都懂，这个层级关系才是真实的。

不过有一点要说清楚：天眼查和 ICP 都是外部依赖，会失效。 天眼查的企业查询要凭据，ICP 那边有限流熔断（上游 v1.4.3 专门做了工作区分级熔断、请求间 8-15 秒消峰、被创宇盾 WAF 拦了就剔除代理 IP）。

所以这类平台的一贯命运是：装完第一天好用，第三个月开始一半功能报错。 这不是代码问题，是数据源问题。用之前先想清楚你能不能持续维护这些凭据。

五、部署之前，有五件事你得知道

这部分我按”会不会咬到你”排序。

① 镜像来自作者的个人阿里云 registry。

部署命令是这么写的：

crpi-laul1izptqrf0tkf.cn-beijing.personal.cr.aliyuncs.com/owl234-arl-prod/arl-web:latest

personal.cr.aliyuncs.com 是阿里云个人版镜像服务。这意味着：镜像由作者个人构建推送，你拉的是他构建的产物，不是从源码在你机器上编译的。

好处是快、是稳、是绕过跨国网络——文档里明说这是为了规避 Docker Hub 拉取失败。坏处是供应链不透明：你没法验证镜像里的二进制跟你看到的源码一致。

对内部靶场、内网资产梳理，这个风险可以接受。对生产环境，我建议你自己 build 一遍。

② 容器以 root 运行。

不是它想 root，是 nmap 的 SYN 扫描和 massdns 需要 raw socket。这是能力需求，不是设计缺陷。但你得知道你的扫描容器是 root 权限、能发原始数据包。

③ 默认口令 admin / arlpass，端口 5173 直连公网。

Nginx 前面有一层 Basic Auth（默认 admin / arl_next），但默认是关闭的。

这两个加起来意味着：你把 5173 开到公网、不改密码，等于把你自己的资产大盘挂在互联网上给人看。而且这个平台本身能扫别人——被人反手拿去当跳板，责任是你的。

最少做三件事：改两个密码、开 Basic Auth、前面套 WAF 或只允许固定 IP。

④ start-prod.sh 会改你的宿主机。

它会自动配 Swap、装或补 Docker 与 Compose 插件、调内核参数。自动化部署脚本都这么干，省事，但它动的是宿主机级别的配置。跑之前看一眼脚本内容，不亏。

⑤ 协议是 GPL-3.0。

内部使用随便用。但如果你基于它做二开然后对外分发（包括 SaaS 之外的分发形式），GPL-3.0 要求你开源。企业里做定制的话，这一点法务要先过一遍。

六、还有个版本落差，比分支问题更值得注意

除了”二开在 HSBranch”这件事，还有个更隐蔽的：分叉仓库落后上游不少。

我算了从分叉 main 的 HEAD 到上游 main 的差距：41 个提交、141 个文件。上游最新是 v1.4.5（2026-11-05），分叉停在 v1.4.3（2026-10-23）。

这 41 个提交里有几块是硬货：

• MCP 治理中心：上游把 MCP 从”只注册一个 get_asset_profile 工具”升级成了 SSE 远程直连 + Stdio 桥接双模，加了细粒度 Scope 专用密钥、工具级开关、速率配额、调用审计日志，工具也扩到 get_enterprise_profile 等五个维度。
• 备份还原的路径穿越防护：这是个安全修复。上游 v1.4.4 专门加固了归档包解压的路径校验，强制在沙箱内解压，防的是”特制压缩包覆盖宿主机关键文件”。这条不分叉过来，等于留了个已知洞。
• 会话 Token TTL 与截图鉴权：截图和升级包下载改成签名凭据，加了 MongoDB TTL 自动清理。
• 集团生命周期管理：集团删除、下属资产组解散或划转。
• 老旧内核（< 4.19）容器兼容性加固。

分叉仓库的 README 里还写着”MCP 仅注册单一工具 get_asset_profile“——这话在 v1.4.3 是准的，在 v1.4.5 已经过时了。你读它的 README，读到的是两个月前的上游。

这不是黑它。二开本来就该基于某个版本冻结，然后自己往前走。问题是它没有把这件事写在显眼位置，也没有定期 rebase 上游的安全修复。

你要是重度用它，建议自己在 HSBranch 上 rebase 一遍上游 main，把那几个安全修复吃进来。冲突肯定有，但比留着洞强。

落到不同人身上

做红队 / 打点的：值得试。天眼查股权穿透 + 四类 ICP + 0.zone 补漏，这个组合在开源工具里不多。装在内网一台 4 核 4G 的机器上，把默认口令改掉，够用。

甲方做资产清点的：先想清楚数据源怎么维护。天眼查凭据、0.zone key、ICP 查询的代理池，三个都得有人管。不然三个月后就是个摆设。另外注意，二开版落后上游 41 个提交，其中含安全修复，上生产前自己决定要不要 rebase。

想学二开的：这个仓库是个不错的样本。不是因为它代码多牛，是因为它把”二开该怎么写文档”示范了一遍——deploy/source/README.md 那 648 行，把 SELinux 四个坑、snap 的 chromium、raw socket 权限全写清楚了。这比功能本身更有教育意义。

纯路人：别装。这东西装完你得有资产要扫才有意义，没资产扫它就是个吃内存的网页。

做安全建设的：注意那个”落后上游 41 个提交”的教训。开源二开最常见的死法不是功能不够，是跟不上上游的安全修复。任何基于开源做的内部平台，都得有个人定期 rebase，否则你维护的是一个越来越脆的定制分支。

最后

这个项目给我的感觉是：作者是干活的，不是写 PPT 的。

证据不在功能列表里，在注释里。天眼查那个兜底客户端，注释写”非公开接口、可能触发风控、随时失效、仅作兜底”；0.zone 插件，注释写”官方未完整公开字段名，所以把查询模板做成可配置，解析时对多个候选字段做容错”。这种话只有真被接口变过的人写得出来。

但它也有开源二开的通病：默认分支没跟上、二开藏在分支里、README 停在两个月前。

这不是恶意，这是精力问题。一个人维护一个二开分支，光是让扫描别崩就已经耗尽力气了，哪有空天天 rebase 上游。

所以用的人得自己长个心眼：clone 完先 git branch -a，看看有没有别的分支；装完先对一下版本号；上生产前跑一次 diff,看看上游这期间修了什么安全洞。

开源工具的成熟度，从来不是看 star 数，是看你有没有能力读懂它藏在哪儿。