先说结论你在安装或者日常使用 ARLAsset Reconnaissance Lighthouse资产侦察灯塔系统的时候前端页面弹出来的timeout of 12000ms exceeded基本不是网络断了而是浏览器请求后端接口时默认 12 秒内没等到响应前端直接把请求掐了。这个报错在首次同步大量资产、批量导入域名、执行一轮完整指纹识别的时候特别常见。这篇文章我把它的来龙去脉、改哪里、怎么改、改完还会不会炸一次讲清楚。ARL 作为安全团队做资产梳理、攻击面收敛的常用工具部署起来其实不复杂但真正上手后你会发现卡住你的往往不是安装步骤本身而是这些藏在运行细节里的“小毛病”。12000ms超时就是典型的一个。网上相关的帖子很零散有说改前端的有说改后端的还有让直接重装 Docker 的。我把自己实际部署和排查的完整过程整理出来方便你直接照着操作少走弯路。适合看这篇文章的人正在部署 ARL、被这个超时报错折磨过的人已经装好但时不时报超时的人以及想搞清楚 ARL 内部请求链路、想彻底弄明白“为什么 12 秒就断”的人。1. 先理解这个报错它不是网络断了是前端在等你1.1 ARL 的安装形态和“12000ms”从哪来ARL 目前主流的部署方式是基于 Docker 的官方给的安装包会把前端一套 Web 界面和后端Python 写的任务调度、指纹识别、端口扫描模块打包成容器。你用浏览器打开管理页面操作时前端会向后端发送各种 API 请求比如添加资产、启动扫描、拉取任务状态。问题就出在这个“拉取”上。前端代码里写了一个默认的请求超时时间值是 12000 毫秒。简单说前端发出一条请求后如果在 12 秒内没有收到后端返回的数据它不会继续干等而是直接抛异常提示timeout of 12000ms exceeded。用生活里的例子类比你打电话给客服响铃 12 秒没人接系统自动挂断。电话本身没问题线路也没问题只是“等得不耐烦了”而已。这个 12000ms 不是后端任务的执行上限而是前端耐心值的上限。理解了这一点后面的排查思路就顺了。1.2 报错出现的典型场景我在不同环境下部署过 ARL这个报错出现的高频场景有这几类首次导入大量资产比如一次性粘贴几百个域名或 IP 段进去后端要分批解析、批量探测存活整体耗时很容易超过 12 秒。点击“资产同步”或“一键扫描”后前端轮询任务状态时恰好某个子任务卡在端口扫描或指纹识别上单次请求超过 12 秒。服务器配置偏低比如 2 核 4G 的机器上跑全端口扫描CPU 被打满后端响应自然变慢。前端页面停留在某个列表页长时间不操作会话过期后重新发起请求也可能触发。关键点在于这个报错并不代表安装失败更不代表 ARL 跑不起来。它只是表明“任务还在后端执行但前端没等到反馈”。有的朋友看到报错就去重装 Docker、重新拉镜像其实方向完全错了。2. 解决方案把超时阈值调大三步搞定2.1 第一步定位超时配置项先说通用的定位方法不管你用哪个版本、装在哪个目录这一招都管用grep -r 12000 /opt/ARL/app//opt/ARL是我常用的安装目录你换成自己实际解压或 clone 的路径即可。正常情况下你会在web.py或前端相关的配置里搜到类似这样的内容PING_TIMEOUT 12000或者在前端 JS 代码里const TIMEOUT 12000不同版本的 ARL 对这个值所在的文件有不同的组织方式。有的放在后端常量定义里有的直接写在前端请求封装里。所以与其背文件名不如直接全文搜索 12000 这个数字。2.2 第二步修改超时值找到之后把 12000 改成一个更合理的值。我个人的建议是60000也就是 60 秒。为什么是 60 秒因为 ARL 即便在处理批量资产添加时后端单次同步任务的耗时一般不会太长除非你一次性导入几千个目标。60 秒既能覆盖绝大多数正常任务的耗时又不至于让前端长时间无响应。如果你管理的资产量很大或者服务器性能较差可以直接调到 120000两分钟再往上就不太推荐了。实际修改时比如后端 Python 文件直接改数字即可PING_TIMEOUT 60000如果是前端构建产物里的 JS 文件同样直接替换数字然后记得重新构建前端。这一步很多人容易漏改了源码没重新编译页面加载的还是旧逻辑自然不生效。2.3 第三步重启服务并验证修改完成后重启 ARL 相关容器或服务。常见方式cd /opt/ARL docker compose down docker compose up -d如果你没有改动容器编排只是改了后端代码也可以直接重启后端容器docker ps | grep arl docker restart 容器ID重启完成后打开浏览器按Ctrl F5强制刷新页面清掉缓存再执行之前必现超时的操作看是否还会弹 12 秒的报错。这里要特别提醒强刷很重要。因为前端页面是 JS 应用浏览器会缓存之前的代码不清缓存的话你改的 60000 根本没被加载排查半天发现还是老代码在运行。3. 进阶如果调大 12000ms 后还超时问题往往不在超时值3.1 判断是“前端超时”还是“后端没完成”这一步很关键能帮你区分到底只是阈值太小还是后端任务真的卡死了。方法很简单看后端日志。ARL 后端通常把日志输出到 Docker 容器里查看方式docker logs -f 后端容器ID然后在前端页面触发一个之前会超时的操作观察日志。如果后续日志里出现了任务完成的记录比如“任务执行成功”“资产同步完成”之类的输出说明后端任务本身是正常的只是执行耗时超过了原定的 12 秒——这就是典型的“阈值太小”你改大后问题自然解决。反过来如果日志停在那儿等几分钟都没有后续说明任务卡住了。这时候你再怎么调大前端超时都是没用的因为后端根本没完成响应等多久都一样报错。3.2 ARL 部署时的资源瓶颈后端任务卡住最常被忽略的原因是资源不足。ARL 在做资产发现时会调用 Nmap 做端口扫描、调用爬虫模块做指纹识别、调用 DNS 解析库做子域名枚举这几件事全是吃 CPU 和内存的大户。我在 2 核 4G 的云主机上部署过一次导入 500 个域名后系统负载直接飙到 7 以上端口扫描任务排队等待单个请求超过一分钟都是常事。建议配置生产环境至少 4 核 8G。如果你只是在本地做实验那 2 核 4G 也可以凑合但要控制资产导入的规模分批添加别一次性塞几千条。此外Docker 容器的资源限制也要检查。如果你通过docker run或docker-compose.yml给容器单独设置了cpus或mem_limit比如限制为 0.5 核和 512M 内存那 ARL 的性能会被急剧压制再多的资源也白搭。查看方式docker inspect 容器ID | grep -A 5 HostConfig如果发现限制过严直接修改容器编排文件去掉限制或调大再重新创建容器。3.3 数据库与中间件状态排查ARL 依赖 MongoDB、Redis 和 Elasticsearch。这三个组件任何一个出问题都会让后端接口迟迟不返回。MongoDB存放资产、任务、指纹结果。如果磁盘满了写入会阻塞任务状态没法更新前端轮询自然超时。Redis做任务队列和缓存。Redis 内存满了触发淘汰策略或连接数打满都会导致任务调度卡住。Elasticsearch存放扫描结果索引。如果 ES 的索引数过多、分片异常查询性能会大幅下降。排查顺序我建议是磁盘空间 - Redis 内存 - ES 集群状态。df -h redis-cli info memory curl -s http://localhost:9200/_cluster/health尤其是磁盘空间很多人装完 ARL 就不管了日志和扫描结果不断累积某天突然发现什么操作都超时一看磁盘 100% 了。遇到这种情况清理磁盘反而是第一要务。4. 安装部署中的同类超时问题排查这个 12000ms 的报错解决之后你如果继续深入使用还会遇到其他形态的“超时”。我把安装部署和日常使用中比较高频的几个横向盘点一下方便你对症处理。4.1 Docker 拉取镜像超时ARL 安装过程中需要拉取多个 Docker 镜像包括 mongo、redis、elasticsearch、python 后端镜像等。由于镜像体积大网络稍有波动就容易出现拉取超时报错提示类似net/http: TLS handshake timeout或read tcp ... i/o timeout。这个和 ARL 本身的 12000ms 报错完全是两回事。解决办法是配置镜像加速器在 Docker Desktop 或/etc/docker/daemon.json里加上可用的加速地址然后重启 Docker 再重试拉取。4.2 Docker in WSL 环境问题如果你用的是 Windows WSL 环境安装 Docker 时可能遇到类似这样的报错a timeout occurred while setting up docker in wsl. restart docker desktop.这通常发生在新装 Docker Desktop、初次初始化 WSL 发行版的时候。处理办法比较暴力但有效完全退出 Docker Desktop然后在管理员权限的 PowerShell 里执行wsl --shutdown等几秒重新打开 Docker Desktop让它重新初始化 WSL。如果还是不行检查一下 WSL 版本确保用的是 WSL2同时升级到最新内核。这个问题的本质是 Docker Desktop 和 WSL 之间的通信握手中途卡住重启等于让双方重新握手。4.3 反向代理网关超时很多人会给 ARL 配一个 Nginx 反向代理方便统一端口、加 HTTPS。这种情况下会遇到另一个典型的网关超时504 Gateway Time-out还有像stream disconnected before completion: idle timeout waiting for sse这样的报错是代理层对长连接做了超时限制。ARL 前端在展示扫描进度时会通过 SSEServer-Sent Events或轮询方式从后端拿数据。Nginx 默认的proxy_read_timeout是 60 秒如果某个接口长时间没有数据返回Nginx 会主动切断连接前端就会收到断流或超时提示。解决办法是在 Nginx 的 server 配置里针对 ARL 的 location 调大超时location / { proxy_pass http://127.0.0.1:5003; proxy_connect_timeout 60s; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_buffering off; }重点在proxy_buffering offSSE 长连接场景下关闭代理缓冲能避免数据积压引起的不稳定。这个细节是我实际调 Nginx 时踩过坑才记下来的默认开着缓冲用 SSE 的接口偶尔会断流。4.4 部署前检查清单结合上面这些经验我列了一个部署前快速检查清单建议你在下载完 ARL 安装包之后、真正执行安装之前先过一遍检查项最低要求建议配置操作系统Linux 常见发行版均可Ubuntu 20.04 / 22.04CPU2 核4 核及以上内存4 GB8 GB 及以上磁盘可用空间20 GB50 GB 及以上Docker 版本20.10最新稳定版Docker Compose2.x最新稳定版端口占用5003、9200、6379、27017 未被占用通过ss -lntp确认这个清单不是摆设。我在一次部署中就是因为 9200 端口被其他 ES 实例占用ARL 自带的 Elasticsearch 容器启动失败导致后面所有任务都异常。提前检查端口占用能帮你节省大量排查时间。5. 实操心得我踩过的坑与建议配置5.1 一个完整可复现的配置参考如果你打算重新部署或者调整现有环境我把最终稳定运行的配置思路整理成了一份可参考的模板。前端超时统一设置为60000前端请求超时12000 - 60000 后端任务轮询超时同步调大至 60000 Nginx 反代 read timeout300s Docker Compose 中不限制内存上限或至少 8G部署完成后建议先导入一小批资产验证链路比如 10 个域名跑一轮完整扫描确认任务状态能正常刷新、扫描结果能正常展示再去导大批量资产。这样可以避免“一把梭”把问题混在一起不好排查。5.2 配置完还是慢的进一步优化如果你已经把超时调大但实际操作中还是觉得慢那问题就不是超时能解决的了要从性能和用法上做优化。分批导入资产一次性导入几千个域名大概率会让任务队列拥堵。建议拆分每批 200-300 个左右。减少并发任务同时启动多个扫描任务会互相争抢 CPU 和内存。ARL 界面里如果支持并发任务数配置调低一点先保证单个任务跑完。关闭不常用的插件ARL 支持自定义扫描插件插件越多耗时越长。日常资产梳理场景只保留必要的探测项全端口扫描这种重活不要每次都开。定时清理历史任务和日志定期删除过期的扫描任务记录清理 Docker 日志文件防止磁盘空间被吃掉。5.3 最后再分享一个排查时的小技巧当timeout of 12000ms exceeded出现时先别急着改代码。我建议你第一时间打开浏览器的开发者工具切到 Network 面板找到那条失败的请求看一下它的耗时分布如果请求发出的前几百毫秒就有响应状态码说明是后端直接返回错误重点查后端日志。如果请求状态一直停留在 pending直到 12 秒左右才失败说明是前端超时切断改阈值就对了。如果状态码是 504说明是 Nginx 层切断了要去调代理配置。这三步能帮你快速圈定问题范围省去在配置文件里来回翻找的时间。我刚开始排这个错的时候就是没看 Network 面板直接在代码里搜索超时配置结果折腾半天最后发现根本不是前端的问题而是容器内存限制把后端跑死了。回到最初的那个报错它的本质并不复杂一个 12 秒的默认等待时间配上一批需要更长时间才能完成的后台任务两者之间的冲突。你只需要根据实际场景把这道“等待的闸门”抬高到合理位置同时确保后端真的有能力在规定时间内完成任务。我的习惯是装好 ARL 后第一件事就把超时调到 60 秒省得后续使用过程中反复被这个报错打断。按照上面的方式调整完再配合合理的任务规划这个工具在资产梳理和攻击面收敛的日常工作中会顺畅很多。
ARL资产侦察系统前端请求超时“timeout of 12000ms exceeded”全面排查与解决
先说结论你在安装或者日常使用 ARLAsset Reconnaissance Lighthouse资产侦察灯塔系统的时候前端页面弹出来的timeout of 12000ms exceeded基本不是网络断了而是浏览器请求后端接口时默认 12 秒内没等到响应前端直接把请求掐了。这个报错在首次同步大量资产、批量导入域名、执行一轮完整指纹识别的时候特别常见。这篇文章我把它的来龙去脉、改哪里、怎么改、改完还会不会炸一次讲清楚。ARL 作为安全团队做资产梳理、攻击面收敛的常用工具部署起来其实不复杂但真正上手后你会发现卡住你的往往不是安装步骤本身而是这些藏在运行细节里的“小毛病”。12000ms超时就是典型的一个。网上相关的帖子很零散有说改前端的有说改后端的还有让直接重装 Docker 的。我把自己实际部署和排查的完整过程整理出来方便你直接照着操作少走弯路。适合看这篇文章的人正在部署 ARL、被这个超时报错折磨过的人已经装好但时不时报超时的人以及想搞清楚 ARL 内部请求链路、想彻底弄明白“为什么 12 秒就断”的人。1. 先理解这个报错它不是网络断了是前端在等你1.1 ARL 的安装形态和“12000ms”从哪来ARL 目前主流的部署方式是基于 Docker 的官方给的安装包会把前端一套 Web 界面和后端Python 写的任务调度、指纹识别、端口扫描模块打包成容器。你用浏览器打开管理页面操作时前端会向后端发送各种 API 请求比如添加资产、启动扫描、拉取任务状态。问题就出在这个“拉取”上。前端代码里写了一个默认的请求超时时间值是 12000 毫秒。简单说前端发出一条请求后如果在 12 秒内没有收到后端返回的数据它不会继续干等而是直接抛异常提示timeout of 12000ms exceeded。用生活里的例子类比你打电话给客服响铃 12 秒没人接系统自动挂断。电话本身没问题线路也没问题只是“等得不耐烦了”而已。这个 12000ms 不是后端任务的执行上限而是前端耐心值的上限。理解了这一点后面的排查思路就顺了。1.2 报错出现的典型场景我在不同环境下部署过 ARL这个报错出现的高频场景有这几类首次导入大量资产比如一次性粘贴几百个域名或 IP 段进去后端要分批解析、批量探测存活整体耗时很容易超过 12 秒。点击“资产同步”或“一键扫描”后前端轮询任务状态时恰好某个子任务卡在端口扫描或指纹识别上单次请求超过 12 秒。服务器配置偏低比如 2 核 4G 的机器上跑全端口扫描CPU 被打满后端响应自然变慢。前端页面停留在某个列表页长时间不操作会话过期后重新发起请求也可能触发。关键点在于这个报错并不代表安装失败更不代表 ARL 跑不起来。它只是表明“任务还在后端执行但前端没等到反馈”。有的朋友看到报错就去重装 Docker、重新拉镜像其实方向完全错了。2. 解决方案把超时阈值调大三步搞定2.1 第一步定位超时配置项先说通用的定位方法不管你用哪个版本、装在哪个目录这一招都管用grep -r 12000 /opt/ARL/app//opt/ARL是我常用的安装目录你换成自己实际解压或 clone 的路径即可。正常情况下你会在web.py或前端相关的配置里搜到类似这样的内容PING_TIMEOUT 12000或者在前端 JS 代码里const TIMEOUT 12000不同版本的 ARL 对这个值所在的文件有不同的组织方式。有的放在后端常量定义里有的直接写在前端请求封装里。所以与其背文件名不如直接全文搜索 12000 这个数字。2.2 第二步修改超时值找到之后把 12000 改成一个更合理的值。我个人的建议是60000也就是 60 秒。为什么是 60 秒因为 ARL 即便在处理批量资产添加时后端单次同步任务的耗时一般不会太长除非你一次性导入几千个目标。60 秒既能覆盖绝大多数正常任务的耗时又不至于让前端长时间无响应。如果你管理的资产量很大或者服务器性能较差可以直接调到 120000两分钟再往上就不太推荐了。实际修改时比如后端 Python 文件直接改数字即可PING_TIMEOUT 60000如果是前端构建产物里的 JS 文件同样直接替换数字然后记得重新构建前端。这一步很多人容易漏改了源码没重新编译页面加载的还是旧逻辑自然不生效。2.3 第三步重启服务并验证修改完成后重启 ARL 相关容器或服务。常见方式cd /opt/ARL docker compose down docker compose up -d如果你没有改动容器编排只是改了后端代码也可以直接重启后端容器docker ps | grep arl docker restart 容器ID重启完成后打开浏览器按Ctrl F5强制刷新页面清掉缓存再执行之前必现超时的操作看是否还会弹 12 秒的报错。这里要特别提醒强刷很重要。因为前端页面是 JS 应用浏览器会缓存之前的代码不清缓存的话你改的 60000 根本没被加载排查半天发现还是老代码在运行。3. 进阶如果调大 12000ms 后还超时问题往往不在超时值3.1 判断是“前端超时”还是“后端没完成”这一步很关键能帮你区分到底只是阈值太小还是后端任务真的卡死了。方法很简单看后端日志。ARL 后端通常把日志输出到 Docker 容器里查看方式docker logs -f 后端容器ID然后在前端页面触发一个之前会超时的操作观察日志。如果后续日志里出现了任务完成的记录比如“任务执行成功”“资产同步完成”之类的输出说明后端任务本身是正常的只是执行耗时超过了原定的 12 秒——这就是典型的“阈值太小”你改大后问题自然解决。反过来如果日志停在那儿等几分钟都没有后续说明任务卡住了。这时候你再怎么调大前端超时都是没用的因为后端根本没完成响应等多久都一样报错。3.2 ARL 部署时的资源瓶颈后端任务卡住最常被忽略的原因是资源不足。ARL 在做资产发现时会调用 Nmap 做端口扫描、调用爬虫模块做指纹识别、调用 DNS 解析库做子域名枚举这几件事全是吃 CPU 和内存的大户。我在 2 核 4G 的云主机上部署过一次导入 500 个域名后系统负载直接飙到 7 以上端口扫描任务排队等待单个请求超过一分钟都是常事。建议配置生产环境至少 4 核 8G。如果你只是在本地做实验那 2 核 4G 也可以凑合但要控制资产导入的规模分批添加别一次性塞几千条。此外Docker 容器的资源限制也要检查。如果你通过docker run或docker-compose.yml给容器单独设置了cpus或mem_limit比如限制为 0.5 核和 512M 内存那 ARL 的性能会被急剧压制再多的资源也白搭。查看方式docker inspect 容器ID | grep -A 5 HostConfig如果发现限制过严直接修改容器编排文件去掉限制或调大再重新创建容器。3.3 数据库与中间件状态排查ARL 依赖 MongoDB、Redis 和 Elasticsearch。这三个组件任何一个出问题都会让后端接口迟迟不返回。MongoDB存放资产、任务、指纹结果。如果磁盘满了写入会阻塞任务状态没法更新前端轮询自然超时。Redis做任务队列和缓存。Redis 内存满了触发淘汰策略或连接数打满都会导致任务调度卡住。Elasticsearch存放扫描结果索引。如果 ES 的索引数过多、分片异常查询性能会大幅下降。排查顺序我建议是磁盘空间 - Redis 内存 - ES 集群状态。df -h redis-cli info memory curl -s http://localhost:9200/_cluster/health尤其是磁盘空间很多人装完 ARL 就不管了日志和扫描结果不断累积某天突然发现什么操作都超时一看磁盘 100% 了。遇到这种情况清理磁盘反而是第一要务。4. 安装部署中的同类超时问题排查这个 12000ms 的报错解决之后你如果继续深入使用还会遇到其他形态的“超时”。我把安装部署和日常使用中比较高频的几个横向盘点一下方便你对症处理。4.1 Docker 拉取镜像超时ARL 安装过程中需要拉取多个 Docker 镜像包括 mongo、redis、elasticsearch、python 后端镜像等。由于镜像体积大网络稍有波动就容易出现拉取超时报错提示类似net/http: TLS handshake timeout或read tcp ... i/o timeout。这个和 ARL 本身的 12000ms 报错完全是两回事。解决办法是配置镜像加速器在 Docker Desktop 或/etc/docker/daemon.json里加上可用的加速地址然后重启 Docker 再重试拉取。4.2 Docker in WSL 环境问题如果你用的是 Windows WSL 环境安装 Docker 时可能遇到类似这样的报错a timeout occurred while setting up docker in wsl. restart docker desktop.这通常发生在新装 Docker Desktop、初次初始化 WSL 发行版的时候。处理办法比较暴力但有效完全退出 Docker Desktop然后在管理员权限的 PowerShell 里执行wsl --shutdown等几秒重新打开 Docker Desktop让它重新初始化 WSL。如果还是不行检查一下 WSL 版本确保用的是 WSL2同时升级到最新内核。这个问题的本质是 Docker Desktop 和 WSL 之间的通信握手中途卡住重启等于让双方重新握手。4.3 反向代理网关超时很多人会给 ARL 配一个 Nginx 反向代理方便统一端口、加 HTTPS。这种情况下会遇到另一个典型的网关超时504 Gateway Time-out还有像stream disconnected before completion: idle timeout waiting for sse这样的报错是代理层对长连接做了超时限制。ARL 前端在展示扫描进度时会通过 SSEServer-Sent Events或轮询方式从后端拿数据。Nginx 默认的proxy_read_timeout是 60 秒如果某个接口长时间没有数据返回Nginx 会主动切断连接前端就会收到断流或超时提示。解决办法是在 Nginx 的 server 配置里针对 ARL 的 location 调大超时location / { proxy_pass http://127.0.0.1:5003; proxy_connect_timeout 60s; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_buffering off; }重点在proxy_buffering offSSE 长连接场景下关闭代理缓冲能避免数据积压引起的不稳定。这个细节是我实际调 Nginx 时踩过坑才记下来的默认开着缓冲用 SSE 的接口偶尔会断流。4.4 部署前检查清单结合上面这些经验我列了一个部署前快速检查清单建议你在下载完 ARL 安装包之后、真正执行安装之前先过一遍检查项最低要求建议配置操作系统Linux 常见发行版均可Ubuntu 20.04 / 22.04CPU2 核4 核及以上内存4 GB8 GB 及以上磁盘可用空间20 GB50 GB 及以上Docker 版本20.10最新稳定版Docker Compose2.x最新稳定版端口占用5003、9200、6379、27017 未被占用通过ss -lntp确认这个清单不是摆设。我在一次部署中就是因为 9200 端口被其他 ES 实例占用ARL 自带的 Elasticsearch 容器启动失败导致后面所有任务都异常。提前检查端口占用能帮你节省大量排查时间。5. 实操心得我踩过的坑与建议配置5.1 一个完整可复现的配置参考如果你打算重新部署或者调整现有环境我把最终稳定运行的配置思路整理成了一份可参考的模板。前端超时统一设置为60000前端请求超时12000 - 60000 后端任务轮询超时同步调大至 60000 Nginx 反代 read timeout300s Docker Compose 中不限制内存上限或至少 8G部署完成后建议先导入一小批资产验证链路比如 10 个域名跑一轮完整扫描确认任务状态能正常刷新、扫描结果能正常展示再去导大批量资产。这样可以避免“一把梭”把问题混在一起不好排查。5.2 配置完还是慢的进一步优化如果你已经把超时调大但实际操作中还是觉得慢那问题就不是超时能解决的了要从性能和用法上做优化。分批导入资产一次性导入几千个域名大概率会让任务队列拥堵。建议拆分每批 200-300 个左右。减少并发任务同时启动多个扫描任务会互相争抢 CPU 和内存。ARL 界面里如果支持并发任务数配置调低一点先保证单个任务跑完。关闭不常用的插件ARL 支持自定义扫描插件插件越多耗时越长。日常资产梳理场景只保留必要的探测项全端口扫描这种重活不要每次都开。定时清理历史任务和日志定期删除过期的扫描任务记录清理 Docker 日志文件防止磁盘空间被吃掉。5.3 最后再分享一个排查时的小技巧当timeout of 12000ms exceeded出现时先别急着改代码。我建议你第一时间打开浏览器的开发者工具切到 Network 面板找到那条失败的请求看一下它的耗时分布如果请求发出的前几百毫秒就有响应状态码说明是后端直接返回错误重点查后端日志。如果请求状态一直停留在 pending直到 12 秒左右才失败说明是前端超时切断改阈值就对了。如果状态码是 504说明是 Nginx 层切断了要去调代理配置。这三步能帮你快速圈定问题范围省去在配置文件里来回翻找的时间。我刚开始排这个错的时候就是没看 Network 面板直接在代码里搜索超时配置结果折腾半天最后发现根本不是前端的问题而是容器内存限制把后端跑死了。回到最初的那个报错它的本质并不复杂一个 12 秒的默认等待时间配上一批需要更长时间才能完成的后台任务两者之间的冲突。你只需要根据实际场景把这道“等待的闸门”抬高到合理位置同时确保后端真的有能力在规定时间内完成任务。我的习惯是装好 ARL 后第一件事就把超时调到 60 秒省得后续使用过程中反复被这个报错打断。按照上面的方式调整完再配合合理的任务规划这个工具在资产梳理和攻击面收敛的日常工作中会顺畅很多。
