1. 为什么Arachni会慢：先认识瓶颈在哪
每次一提到Arachni，我的第一反应不是“功能强大”，而是“真能吃资源”。作为一款开源Web应用安全扫描器，它确实很能打：服务端漏洞检测、DOM审计、登录态扫描、分布式部署全都支持，尤其在测试Ajax页面和SPA应用时优势明显。但代价就是，一个默认配置跑起来，动辄几个小时，内存占用轻松冲破2G，中途还时不时因为目标站点响应慢而卡在某个路径上不动。
想要提升速度，第一件事不是急着改参数，而是先搞清楚Arachni的扫描流程到底在做什么。它大体分三个阶段：爬取阶段负责发现页面和接口，审计阶段往这些入口注入验证向量，DOM阶段用无头浏览器渲染页面并分析客户端逻辑。这三个阶段是交错推进的，资源占用也完全不同。爬取阶段主要吃网络带宽和HTTP并发，审计阶段吃CPU和内存，DOM阶段最夸张——每处理一个页面都要拉起一个浏览器实例，等它渲染、执行脚本、再收集事件和数据，单页成本可能是普通请求的几十倍。
理解了流程之后，瓶颈就很好定位了。默认配置下Arachni会启用所有审计模块，每一个check都有自己的payload库和匹配逻辑，叠加起来就是一个巨大的请求组合数；默认并发保守，而超时又很宽松，碰到响应慢的服务器，大量时间浪费在等待上；爬取范围不加限制，一堆静态资源、退出登录接口、CDN子域全部被拉进来；再加上DOM扫描对传统服务端渲染站点来说基本是在做无用功。这些因素叠加，扫描时间被无限拉长是必然结果。
我把平时调优过程中最常用的7个技巧整理了出来。它们不是孤立的参数调整，而是一套从网络层、计算层、范围控制到任务编排的完整优化路径。在多个中等规模目标上实测下来，单任务耗时普遍能压缩到原来的三分之一到四分之一，也就是标题里那个300%左右的概念。不过先把丑话说在前面：这些操作只针对你有权测试的目标，内部演练、授权渗透、自建靶场都没问题，未经授权去扫别人的系统，再快的扫描器也救不了你。
2. 动手优化前的准备：先量化再动手
很多人在Arachni上直接堆并发数，指望一个参数解决所有问题，结果要么把目标服务器压崩溃，要么触发防护机制导致大量误报。我的习惯是，优化前先花十分钟建立一个基线，后面每改一个参数，都能明确知道它到底带来了多少收益，而不是凭感觉判断。
基线记录的核心指标有四个：本次扫描发现并处理的页面总数、发送的HTTP请求总数、总耗时、内存峰值。Arachni的HTML报告里其实已经包含了相当详细的统计数据，包括每个目录的请求分布、响应时间曲线、错误请求数量。打开报告之后，先别急着看漏洞列表，先看请求分布——你会惊讶地发现，大量时间都花在了几个重复度极高的动态URL上，比如带排序参数的分页列表、带时间戳的查询接口，这些页面结构一样，但Arachni会把它们当成新页面反复爬取和分析。
有了这些数据，优化方向其实就自动浮出水面了。哪个目录请求量最大，大概率就是需要加排除规则的地方；哪个页面响应时间特别长，就该考虑调整超时参数或者在scope里限制它；如果报告显示DOM分析页面占比极高，而目标又是一个传统MVC架构的服务端渲染站点，那DOM这块的成本基本可以砍掉大半。
还有一个建议是先准备一个小型测试环境。不要直接在正式目标上一次一次试参数，风险太大。我自己习惯在本地放一个几十个页面的测试应用，先用默认配置跑一遍拿基线，然后每调整一个技巧就用time命令记录一次总耗时，对比数据说话。这样做的好处是，正式目标上的参数组合是已经被验证过的，上去就能直接跑，不用在真实环境里反复试探。
3. 技巧一：HTTP并发与超时，先解决“干等”的问题
Arachni默认的HTTP并发是25，这个数值对大多数普通目标来说偏保守。默认值考虑的是兼容性，追求的是稳定，但如果你扫的是自己维护的服务器或者内网测试环境，完全可以放开。我把并发调到50到80之间，扫描耗时立刻有肉眼可见的下降。
真正要注意的不是“调高”，而是“调到多高”。并发数是典型的木桶效应参数：目标服务器能接受的连接数、你的带宽、扫描机的内存，三者中最低的那个决定了上限。我遇到过把并发从50直接拉到200，结果目标防火墙把所有来源IP都临时拉黑，扫描直接报废，所有本应成功的请求全部超时，最终耗时不降反升。竞态和误报也会随着并发升高而变多——服务器来不及处理就返回5xx，扫描器会把5xx当成有效响应继续分析，导致大量无意义输出。
超时参数是另一个容易忽略但影响巨大的选项。Arachni默认的HTTP超时是60秒，这个值对正常业务站点来说太宽松了。一个页面如果5秒内没响应，基本说明它有问题，等60秒纯粹是浪费时间。我通常会把超时压到20到30秒，加上3次左右的重试上限，既不会因为单次超时就漏掉页面，也不会让一个慢响应把整条扫描链路拖住。
参数调整可以这样组合：
arachni http://target.example \ --http-max-concurrency=60 \ --http-timeout=30 \ --http-max-redirects=5这里有一个实操细节：如果目标本身是内网系统或者本地服务，响应速度很快，把并发调到100都没问题；如果是面向公网的站点，先做一次简单探测，看正常并发下目标资源是否吃紧，再决定最终数值。另外，带上有效的Cookie或者会话信息能明显减少重定向跳转，避免扫描器反复在登录页和跳转链路之间打转。Arachni支持直接指定Cookie，--cookie-jar可以加载浏览器导出的Cookie文件，尤其适合扫描登录后才能访问的业务系统，省下的时间非常可观。
4. 技巧二：裁剪审计模块和插件，砍掉九成无效计算
这是效果最明显的一个技巧，也是大多数人最容易忽略的。Arachni默认启用所有审计模块，意味着它会同时跑SQL注入、XSS、文件包含、命令注入、CSRF等一系列检测。每个模块都有自己的payload库，组合出来的请求数量是爆炸性的。可实际情况是，一个目标往往只有几个入口存在明显风险，全量模块跑完，产出的大多是低危信息类问题。
我的做法是区分场景。日常巡检和回归测试，只保留高价值漏洞模块：
arachni http://target.example \ --checks=sql_injection,xss,csrf,rfi,lfi,command_injection \ --audit-links --audit-forms这样一改，初始化的模块数从几十个降到个位数，请求总量可能直接减少一半以上。Arachni启动时加载所有检查器本身就要消耗不少CPU和时间，模块少了，前期准备阶段也变快了。只有遇到完整交付前的全量渗透测试，我才会把所有checks放开，并且提前预留足够长的时间窗口。
插件也是一样的逻辑。Arachni默认带的插件不少，有些像字典攻击、HTTP爆破之类的插件，在任何普通扫描中都会消耗大量请求额度，但产出有限。用--plugins指定只加载必要的插件，比如用来限制页面深度的、用于检查robots文件的，其余的一律不开。这里注意，插件和审计向量是两个维度：插件负责辅助决策，审计向量决定往哪些入口注入payload。如果不需要同时测所有参数，就把--audit-cookies和--audit-headers关掉，只保留--audit-links --audit-forms。Cookie和Header的审计会让请求数翻倍，而很多传统的HTTP-only站点压根不把参数放在这两个位置。
裁剪模块之后的另一个好处是误报率下降。模块少了，交叉验证的次数也随之减少，报告里充斥着各种“疑似低危”的噪音问题也会少很多。报告更干净，后续人工复核的时间成本同样在降低。
5. 技巧三：Scope范围限制，别让扫描器乱跑
Arachni默认全域名爬取，听起来合理，但真实站点里藏着大量你不希望它去碰的路径。最典型的就是退出登录接口、文件下载目录、静态资源路径、日志导出页面。这些路径要么没有漏洞探测价值，要么响应代价极高（比如一下子打包几个G的日志），把它们拉进扫描范围，纯粹是给自己添堵。
范围控制的重点是排除规则。Arachni支持通过正则表达式定义包含和排除规则，排除规则的效果立竿见影：
arachni http://target.example \ --scope-exclude-patterns=".*/logout,.*/download/.*,.*\.(png|jpg|css|js|svg)$"这里有一个值得注意的坑：排除规则写得太宽，会连正常业务路径一起挡掉，导致漏扫；写得太窄，又起不到效果。我一般先用爬虫阶段跑一遍，拿到一份真实URL列表，再回过头来精确调整排除规则。比如一个后台管理系统的URL大多以/admin/开头，就该优先保这个路径，同时排除掉/admin/logout和/admin/export这类出口。
页面深度也要限制。一个站点如果链接层级很深，比如A→B→C→D→E，Arachni会一层层爬下去，而深层页面往往只是同一种业务模式的重复。合理设置深度上限，比如限制在3到4层，可以避免扫描器陷入“越爬越深、越深越慢”的循环。子域问题同样需要关注。默认情况下Arachni不会跨子域，但一旦配置了包含子域的选项，就会把CDN、静态资源域、测试环境子域全部纳入扫描，流量瞬间成倍增长。判断是否需要包含子域，先想清楚目标到底是什么，很多站点的主业务都在www子域上，那子域扫描就是多余的成本。
还有一个容易被忽略的点是自动冗余路径。某些动态页面会在URL上带时间戳、排序字段等参数，生成出大量结构相同、内容几乎一致的页面。Arachni的冗余检测机制会尝试识别这类情况，但默认策略比较保守。如果报告显示某个URL变体数量特别大，可以在scope配置里对这类路径单独做限速或排除，防止扫描器在一类页面上无限消耗时间。
6. 技巧四：爬扫分离与快照续扫，把阶段资源错开
Arachni默认是边爬边扫，这种模式的好处是省时间，但坏处是网络请求和审计计算混在一起，资源被互相争抢。更合理的做法是把两个阶段拆开：先用一个轻量配置把目标的信息架构摸清楚，拿到一份完整URL清单；再把这个清单或者对应的爬取状态交给一个完整配置去审计。
实际操作上，Arachni本身没有一个直接的“crawl-then-audit”开关，但可以通过快照机制实现同样的效果。第一轮只开启爬虫相关的插件，禁用大部分checks，让任务快速跑完信息收集阶段，同时用--report-save-path保存扫描状态快照；第二轮使用恢复模式加载快照，切换到完整审计配置继续跑。这样第一轮的请求成本极低，第二轮在已经明确范围内的高密度审计也跑得更快更稳。
# 第一轮：轻量爬取，保存快照 arachni http://target.example \ --checks=none \ --plugins=page_depth,robots_txt \ --report-save-path=target.afsr # 第二轮：加载快照，完整审计 arachni --resume=target.afsr --checks=sql_injection,xss,csrf快照续扫的另一个价值在于防中断。大型目标跑到三分之一时，网络抖动、内存不足、目标服务器重启，都可能让整个任务失败。有了快照，从头再来的成本变成了从断点继续的成本，这本身就是巨大的时间节省。跑重要任务时我会额外设置一个定期保存快照的习惯，比如每检查完一个业务模块就手动存一次，防止意外。
这里有一个需要注意的细节：爬取阶段的范围一定要比审计阶段更宽。爬取阶段宁可多抓一些疑似无关的页面，也不能漏掉真实入口；审计阶段的排除规则可以收得更紧一些，重点是控制审计请求量。两轮配置的scope规则最好分别制定，不要直接复用同一套参数。
7. 技巧五：DOM渲染取舍，用不上就关掉
Arachni区别于普通扫描器的一大卖点是DOM审计能力，它能通过无头浏览器执行页面里的JavaScript，分析Ajax请求、事件监听器、客户端渲染产生的DOM状态，发现那些纯服务端扫描器完全看不出来的问题。但这个能力是重型武器，每个DOM页面都会拉起独立浏览器实例，执行脚本、等待定时器、收集事件，单页面的处理成本远超普通请求。
对于单页应用和重度依赖Ajax聚合页面的目标而言，DOM审计是必须保留的，否则大量客户端逻辑会完全处于盲区。但问题是，很多传统业务系统仍然是服务端渲染模式，页面返回就是完整HTML，客户端的JavaScript充其量做点表单校验。这种站点开DOM审计，等于每个页面都要白跑一遍浏览器渲染流程，纯粹是浪费。
我的建议是：先确认目标前端架构。如果确认没有明显的SPA特征，把DOM相关配置降到一个很低的水平。在Arachni的配置里，DOM爬取深度、无头浏览器并发数、渲染超时这些都是可以调整的：
scope: dom_depth_limit: 0 browser_cluster: max_concurrency: 2 worker_timeout: 30000dom_depth_limit: 0意味着不主动执行客户端DOM分析，整体扫描的内存占用能下降一大截。如果一个目标混合了SPA页面和传统服务端页面，可以折中设置深度限制在1到2，让浏览器集群只处理首屏渲染，不做深层事件探索。无头浏览器的并发数限制也值得注意，这个参数不是越高越好，浏览器实例本身内存消耗就大，并发一多，还没等扫描完成，内存先被吃干净。
调低DOM能力之后，还要留意某些漏洞类型的覆盖变化。比如部分CSRF问题依赖页面中动态生成的Token，Token又通常是在浏览器渲染后才写入表单的，如果关闭了DOM处理，这类问题可能会漏报。所以DOM取舍的本质是速度和覆盖率的权衡，需要结合目标特性来决定，不能无脑关闭所有DOM功能。
8. 技巧六：运行环境与GC参数，别让扫描机拖后腿
Arachni是Ruby应用，Ruby的垃圾回收机制在长时间、高负载运行下会明显影响性能。扫描器跑半小时之后，内存里积累了海量对象：响应对象、节点元素、审计结果、中间状态。默认GC参数是给通用Ruby程序用的，放到Arachni这种“内存黑洞”场景下，就会频繁地触发全量GC，而GC期间程序是停滞的。扫描耗时越长，这种现象越明显。
启动前设置几个环境变量，可以显著改善长时间运行的稳定性：
export RUBY_GC_HEAP_INIT_SLOTS=1000000 export RUBY_GC_MALLOC_LIMIT=100000000 export RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=2.0 arachni http://target.example ...RUBY_GC_HEAP_INIT_SLOTS控制初始堆槽位数量，设置大一些可以减少前期频繁扩容的次数；RUBY_GC_MALLOC_LIMIT提高malloc触发的阈值，减少不必要的GC调用。这些参数不是固定的标准答案，实际值需要根据扫描机的物理内存来调整。内存充足的机器可以放得更宽，内存紧张反而要降低数值，避免GC一次性回收压力过大。
内存问题的另一面是扫描机自身规格。我用过4G内存的云主机跑Arachni，默认配置下跑到一半就开始写交换分区，整个系统卡得像幻灯片一样。后来把并发降下来，DOM相关的深度限制调低，情况才有所好转。这里有个反直觉的经验：内存不足时，降低并发比提高并发更有效。并发一高，待处理的响应对象堆积如山，内存耗尽之后触发GC风暴，每个请求的等待时间反而变长，整体吞吐率断崖式下降。所以并发参数不是拍脑袋定的，要结合扫描机内存和目标响应速度一起算。
对于特别大的目标，我建议在系统层面加一道保险，用timeout命令限制最长时间，避免任务在夜里失控：
timeout 14400 arachni http://target.example --report-save-path=big.afsr四个小时仍然跑不完的情况下，说明范围或者并发设置还有问题，先停下来分析报告数据，而不是让扫描继续消耗资源。
9. 技巧七：任务切片与分治并行，别把鸡蛋放一个篮子里
单任务大包大揽地扫描一个巨型站点，是一个常见的错误思路。站点规模一大，总有一个慢路径会拖住整个流程：可能是某个重报表页面，某个需要长时间查询的动态接口，某个包含几千条记录的列表页。Arachni碰到这种页面会花大量时间等待和重试，而其他正常的业务模块只能排队，整体效率被明显拖低。
我现在的习惯是接到一个大型目标时，先花半小时画出业务模块地图，按功能拆成多个相对独立的入口，例如后台管理、门户展示、API接口服务分开，然后分别发起扫描任务，各自限制scope范围。这样每个任务的范围都小，单个任务跑完的速度快，任何一个任务出问题也不会影响其他任务。
# 任务A：只扫后台管理 arachni http://target.example/admin \ --scope-exclude-patterns=".*/logout,.*/export" \ --checks=sql_injection,xss,csrf \ --report-save-path=admin.afsr # 任务B：只扫API接口 arachni http://target.example/api \ --audit-links --audit-forms \ --checks=sql_injection,rfi,lfi \ --report-save-path=api.afsr多任务并行时要特别注意资源分配。两个Arachni任务同时跑，并发参数不能简单叠加，因为CPU、内存、带宽是共享的。我通常会把每个任务的并发都降一些，让总并发保持在单任务合理并发的范围内。例如单任务并发60，两个任务并行时各设35到40，总吞吐反而更高，因为避免了系统层面的资源争抢。
报告汇总也不难处理。每个任务独立生成报告，返回前用脚本解析各份报告里的漏洞列表，按风险等级合并，人工复核时按模块逐个确认即可。这个过程可以脚本化，把Arachni生成的JSON报告解析之后汇总到一个Excel或者Markdown表里，标注每个漏洞来自哪个模块，后续跟踪修复反而更清晰。
切片还有一个隐藏优势：可以分阶段交付。紧急的高风险模块（比如登录、支付、文件上传）可以先扫，中低风险模块后续跟上，不需要等全部扫完才能汇报问题。安全测试的时效性往往比完美覆盖率更值钱，先交结论，再补全细节。
10. 常见问题与排查技巧实录
优化过程中难免遇到各种异常情况，有些问题看起来像配置错误，实际上是资源或策略层面的矛盾。这里整理几个高频问题，都是我踩过的坑。
并发调高之后大量请求超时，是参数问题还是目标问题？先看错误码分布。如果超时的里面夹着大量403、429、503状态码，基本是触发了目标侧的策略限制，这时候不是降低并发这么简单，可能要考虑调整请求速度、降低频率、甚至添加延时。如果是单纯的超时增多，没有防护类状态码，那大概率是网络链路问题或者超时设得太紧，适当回调一些超时时间即可。
扫描过程中内存持续上涨最终OOM怎么办？立刻检查两个参数：并发数和DOM浏览器池并发数。内存OOM的元凶八成是这两个数太高。Arachni每个HTTP响应对象都保留在内存里做后续分析，对象数量与并发成正比；DOM浏览器更夸张，一个浏览器实例轻松占几百兆。先降DOM处理深度，再降HTTP并发，这是最快的止血方案。别再往上堆Ruby GC参数，物理内存不够，什么参数都救不了。
为什么同一个目标跑第二次，结果和第一次差异很大？这是正常现象。Arachni的爬取顺序、目标服务器响应排序、会话状态变化、页面内容动态渲染，都会影响请求路径和审计顺序。解决方式是把scope和排除规则固化成配置文件，每次用同一套规则执行，同时保证目标数据状态一致（比如用同一个测试账套）。安全测试结果本来就是快照性质的，重要的是可复现的稳定配置，而不是追求两次结果完全一致。
扫描器很多页面上显示“pending”但请求量很小，卡住了？这种情况多半是某个元素正在占用扫描线程：比如一个慢速的下载请求，或者一个无响应页面在等待超时。先用报告里的响应时间排序找到最慢的那批URL，把它们加进排除规则。实在定位不到的，直接杀进程，从快照恢复继续跑，比干等下去有意义。
目标封了IP，怎么继续？老实说，被封IP本身就是信号：扫得太激进或者目标防护策略太敏感。先把并发降下来，延长请求间隔，如果条件允许换个出口IP，从最近保存的快照恢复扫描。但最核心的改进是优化scope，把扫描限制到真正必要的路径上，而不是全站地毯式轰炸。一次合理规划过的扫描，比十次被封后的重试都高效。
11. 最后分享一点体感
整套优化技巧用下来，最大的感悟是“快”不是目的，“又快又稳又能覆盖该看的东西”才是。有一回我把一个目标的并发从50拉到150，结果目标直接把所有长连接都重置了，扫描耗时比优化前还长了三倍。后来回到80并发，加上合理的超时和重试，反而第二次就稳定跑完了。提速这件事，本质上是在“资源上限”和“覆盖率需求”之间找到那个平衡点。
一个值得长期坚持的小习惯：每次做参数实验，先拿一个几十个页面的小站点做对标，用time记录每个版本的实际耗时和内存峰值，形成一张自己的参数调优表格。下一次遇到新目标，直接表格里挑一套合适的方案再按目标特征微调，效率会高很多。
这套优化思路还可以继续往CI/CD方向扩展。把裁剪版的扫描配置固化成一个固定命令，塞进代码合入前的回归流程里，只跑核心高风险模块；到了上线前再做一次全量扫描。开发阶段五分钟就有结论，临上线再花几个小时跑深度检测，安全测试从“一天一次”变成“每次提交都跑”，效果和效率同时兼顾。扫描器换来的一次速度提升，最终省下来的是人的时间，这大概是所有性能优化里最有价值的部分。
