1. 项目概述：为什么Nuclei能让安全测试效率翻倍
Nuclei这个工具，我在安全测试圈子里逢人就会推荐。它和传统的漏洞扫描器完全是两个思路——别的扫描器是内置一堆规则然后帮你跑完出报告，Nuclei则是把安全检测逻辑全部拆成了一个个模板文件，想测什么就加载什么，灵活性完全不在一个层级。
先说它解决的核心痛点：安全测试里大量的检测其实是重复劳动。比如检查某个站点是否存在未授权访问、测试某个服务是否暴露了调试接口、验证一批IP是否有风险端口开放，这些工作如果用传统方式，要么人工一个个试探，要么写一堆脚本反复调整，耗时又枯燥。Nuclei用一个统一的模板描述语言，把这些检测逻辑固化下来，一条命令就能批量跑几百上千个目标，还天然支持多线程并发。
3天时间能不能从零到精通？我接触过不少刚入门的开发者和安全爱好者，我的结论是能，但前提是学习路径要对。第一天搞定模板语法和运行机制，第二天学会编写和调试自己的模板，第三天拿真实业务场景练手并跑通一个完整的扫描流程，这个节奏是可行的。当然，精通是个相对概念，三天可以让你达到"能独立编写模板、能排查常见问题、能设计检测方案"的水平，再往深走就需要持续积累了。
这篇内容适合谁？一是做安全测试、红队评估的从业者，二是负责公司业务安全、需要做自查的开发和运维同学，三是对漏洞原理有一定了解但想提升检测能力的安全爱好者。如果你只是听说过Nuclei但没系统用过，或者用过基础功能但不太会写模板，那这篇内容正好对症。
2. 核心机制：Nuclei模板为什么能成为行业标准
2.1 模板的本质：把检测逻辑变成可复用的描述语言
Nuclei整个产品设计最聪明的地方，就是把"检测逻辑"这个抽象的概念，具象成了一个YAML格式的模板文件。任何一次检测，本质上都可以拆成这么几个部分：先发什么请求、请求长什么样、怎么判断结果、匹配到了说明什么问题、风险等级多高。
比如说你想检测某个管理后台是否存在弱口令，传统做法是打开浏览器，找到登录页面，输入用户名密码试一下，或者写一段Python脚本模拟登录过程。用Nuclei模板的话，做的事情其实一模一样，只是换了一种描述方式：指定目标URL，构造POST请求带上默认口令的字典，响应里出现"登录成功"之类的关键字就算命中。这个逻辑被写进模板以后，以后任何一次遇到类似的系统，直接复用模板跑一遍就行，不需要重新分析攻击面、重新写脚本。
这种设计思路带来的最大好处是可积累、可共享。大家写的模板可以互相复用，一个漏洞的检测方法一旦被验证，就能被整个社区快速采纳。我自己维护的模板仓库里已经有几百个模板，不少是从公开渠道收集来的，平时遇到新的检测需求，先翻一翻有没有现成的模板，没有的话就基于已有模板改一改，大部分场景半小时内能搞定。
2.2 请求引擎：一条命令背后的多层调度逻辑
Nuclei跑起来以后，它背后做的事情比表面看到的要复杂得多。大致可以理解为三层调度：第一层是输入层的处理，不管是单URL、URL列表文件还是CIDR网段，统一转换成待检测的目标集合；第二层是模板层的匹配，把目标列表和模板列表做笛卡尔积组合，每个目标配每个模板，再交给并发池去执行；第三层是协议层的分发，HTTP请求走HTTP引擎，TCP连接走TCP引擎，不同协议各走各的逻辑。
这个设计直接决定了它在大规模测试场景下的优势。我之前在做一个漏洞排查项目时，需要对某公司几十个子域做全面体检，如果用传统方式人工一个个看，一天都未必能完成。用Nuclei之后，我把子域列表扔进去，载入了大概两百个和Web业务相关的模板，并发数调到100，不到二十分钟就跑完了。中间出了三个命中，其中有两个是信息泄露类的接口，事后人工验证也确实有问题。
并发调度这块有个参数值得专门说，-c控制的是并发模板数，-bulk-size控制的是每批处理的模板数量，-l指定目标列表文件。这三个参数配合好了，扫描速度和资源占用能保持在一个很理想的平衡点。跑内网大网段的时候我一般把并发控制在50以内，跑公网个别目标的时候拉到200也没多大压力，核心是别把目标站点打挂，也别把自己本机资源吃满。
2.3 协议支持：不止于HTTP的检测能力
很多人以为Nuclei只能测Web应用，这是对它最大的误解。Nuclei的协议支持面其实相当广，涵盖了HTTP、TCP、DNS、FTP、SSL/TLS甚至JWT等场景。
举一个实际用过的例子。网络安全事件里经常遇到弱口令或者空口令的Redis服务，传统做法是拿redis-cli去连一下试试。用Nuclei的话，写一个针对Redis的TCP检测模板，里面定义好连接后发送INFO命令，再用表达式匹配响应里是否包含redis_version这个字段，如果响应符合预期就说明端口是开着的且响应了Redis协议。这种检测方式的好处是完全脚本化了，不用每台机器都手动去敲命令，配合CIDR批量扫描，内网里有没有暴露的Redis服务一目了然。
DNS协议的检测我常用于域名接管场景。一个子域名指向了某个云服务提供商但实际资源已经被释放，DNS响应里就会出现特定的记录类型或者特定字符串，模板里的matcher如果匹配到了，就说明这个域名存在被劫持的风险。这类检测手工做起来相当繁琐，有了模板化方案以后，几百个子域名的接管风险排查十几分钟就能出结果。
3. 第一天：环境搭建与模板基础语法实操
3.1 快速安装：三个平台一视同仁
安装Nuclei的方式有好几种，最推荐的是直接下载官方编译好的二进制文件，解压即是可执行程序，不需要配Java环境也不需要装依赖，对没有包管理权限的服务器环境尤其友好。
# Linux/macOS 下用 curl 拉取安装脚本 curl -sSfL https://projectdiscovery.io/nuclei-install | sh # Windows 下直接用 go 工具链安装 go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest如果已经装了Go环境，go install是最省事的，一条命令装完直接进$GOPATH/bin里找可执行文件。装完验证一下版本号：
nuclei -version能看到版本信息输出就说明装好了。这个地方有个新手容易忽略的点：Nuclei的-update参数可以把模板库更新到最新版，模板库在这个领域迭代速度极快，新增的漏洞检测模板会定期推送，日常使用前先更新一次模板库是个好习惯。这点很重要，因为Nuclei本身只是个引擎，真正干活的是模板，模板不新，引擎再强也是白搭。
3.2 第一个模板：从编写到运行的完整路径
我习惯用最简单的HTTP检测来教新手入门。假设现在要检测一个Web站点是否泄露了/.git/config文件——这是一个很典型的信息泄露风险点，攻击者如果能访问到Git配置文件，就能看到仓库的结构和远程地址，深挖下去可能是源码泄露。
先创建一个git-config.yaml文件，内容如下：
id: git-config-exposure info: name: Git Config Exposure author: yourname severity: medium description: Detects exposure of git config file. requests: - method: GET path: - "{{BaseURL}}/.git/config" matchers: - type: word words: - "[core]" part: body逐行拆解这个模板。id是模板的唯一标识，命名建议见名知意，方便后续在众多模板中搜索管理。info块描述的是元信息，其中severity字段按建议填info、low、medium、high、critical之一，这决定了扫描结果按什么级别汇总。
requests块才是核心。method指明请求方法，path里的{{BaseURL}}是Nuclei内置的变量，运行时自动替换成你指定的目标地址。matchers是匹配器，type: word表示关键字匹配，words列表列出命中的关键字，part: body限定在响应体里搜索。逻辑就是：请求这个路径成功后，如果响应体里出现了[core]字样，就判定命中。
保存模板后运行：
nuclei -u https://example.com -t git-config.yaml-u指定目标URL，-t指定模板文件。如果目标站点确实存在Git配置文件泄露，Terminal里就会打出高亮的结果，显示命中模板名称、目标地址、风险等级等信息。
3.3 模板语法进阶：变量、请求链与动态值
只掌握最基础的GET请求是远远不够的。实际的检测场景里，很多时候需要获取页面里的某些动态值，然后把这些值作为下一步请求的参数——这就涉及Nuclei的变量提取机制。
最常见的场景是检测带Token的表单或接口。很多Web应用的接口需要一个会话Token，而这个Token是每次访问首页时动态生成的。在Nuclei模板里可以这样写：先发一个GET请求到首页，从响应体里用正则提取Token，把结果存到一个变量里，下一步请求再引用这个变量。具体语法如下：
requests: - method: GET path: - "{{BaseURL}}/" redirects: true extractors: - type: regex name: token part: body regex: - 'name="csrf-token" content="([a-f0-9]+)"' - method: POST path: - "{{BaseURL}}/api/check" body: "csrf={{token}}&username=admin&password=123456"extractors与matchers的区别需要理解透彻。matchers是判断"有没有"的过滤器，结果只能是命中或不命中；extractors是从响应里"捞数据"的抽取器，能提取出动态值并赋予变量名。上面例子里，第一个请求提取了token变量，第二个请求用{{token}}引用它，这就构成了一个完整的动态请求链。
实际编写时要注意正则表达式的严谨性。提取器的正则如果写得太宽泛，可能会匹配到无关内容导致后续请求失败；写得太窄，又可能漏掉合法的Token格式。我一般先用curl手动发一个请求看真实响应格式，再根据实际情况调整正则，这样一个模板调试下来通常十分钟内能跑通。
3.4 流程控制：多条件匹配与逻辑运算
模板之所以能应对复杂场景，很重要的一点是matchers支持逻辑组合。比如检测一个管理后台是否存在严重漏洞，不能只看单一路径是否返回200，还要同时满足多个条件才算命中。
来看看如何在模板里表达"同时满足"和"满足其一"这两种逻辑：
matchers-condition: and matchers: - type: status status: - 200 - type: word words: - "admin" - "dashboard" condition: or part: bodymatchers-condition字段放在matchers列表外层，它的值可以是and或or。and意味着所有子匹配器都命中才算整体命中，or则是任意一个命中即可。嵌套的condition字段控制单个匹配器内部多个关键词的逻辑。
有一种情况需要特别提醒：某些业务系统响应码不是标准的200，比如部分API接口返回201或202，如果模板里死板地匹配200就容易漏报。更稳妥的方式是放松状态码的限制，把它从硬性条件改成非强制条件，只用作辅助判断。我第一次写网关类系统的检测模板时就吃了这个亏，后来把状态码条件去掉了，只靠响应体关键词判断，误报率反而降了不少，这个调整在真实测试中很管用。
4. 第二天：编写高质量模板的方法论与技巧
4.1 模板设计思路：先想清楚三个问题再动手
写模板和写代码有点像，直接上来就敲键盘的结果通常是反复返工。我整理了一个三段式设计流程，能显著提高模板编写的效率和准确率。
第一步，明确要检测目标的行为特征。这个"特征"是判断漏洞是否存在的关键。比如检测一个服务是否开放了调试接口，你关心的特征是"接口返回了堆栈信息或调试页面关键字"；检测一个系统是否存在SQL注入，关心的特征是"输入单引号后页面报错信息出现数据库相关关键字"。特征必须具体、可验证，不能是"可能存在问题"这种模糊判断。
第二步，确定最简单的检测路径。一个漏洞或风险点可能有很多种检测方式，选成本最低、干扰最小的那种。以检测Spring框架的Actuator端点为例，最直接的路径就是请求/actuator/env这个地址，看有没有返回配置信息；如果这个路径不存在，再考虑其他变体。从最简路径开始写模板，后续根据实际需要再增加层级。
第三步，设计稳健的匹配规则。匹配器的设计要控制误报率和漏报率的平衡。关键词选得太通用，比如选"error"作为匹配词，任何页面只要带这个英文单词就会命中，结果就是满屏误报；选得太特化又可能漏报。经验之谈是选两到三个能同时命中的强特征词，配合matchers-condition: and，误报率能压到很低的水平。
4.2 多请求编排：模拟真实攻击路径
安全测试里有很多漏洞的利用过程是多步骤的。拿一个典型的越权漏洞来说，攻击者的操作路径是：先登录获取身份凭证，再带着凭证去访问某个数据接口，如果在响应里能看到不属于当前用户的数据，就证明越权存在。Nuclei模板支持把这条路径完整编排出来。
requests: - method: POST path: - "{{BaseURL}}/api/login" body: "username=test&password=test" extractors: - type: regex name: session part: body regex: - 'token":"([^"]+)"' - method: GET path: - "{{BaseURL}}/api/user/order/10001" headers: Authorization: "Bearer {{session}}" matchers: - type: word words: - "orderId" part: body第一个请求从登录接口的响应JSON里提取token，存入session变量；第二个请求在请求头里带上这个token去访问订单接口，如果响应里包含"orderId"字段，说明接口可能未校验数据归属权。这个模板跑出来的结果，能给后续人工测试提供很明确的指向。
这类多请求模板执行时消耗的时间相对长一些，因为每个目标都要串行完成两步请求。但它的价值在于能发现那些单请求完全没办法覆盖的漏洞类型。对于做安全评估的同行来说，这类模板的编写能力基本属于必须掌握的技能。
4.3 并发、限速与资源控制：别把目标打挂
Nuclei默认的扫描速度是比较激进的，它在设计时就考虑了扫描效率，所以如果你直接跑一个大规模目标，高并发下有可能对目标系统造成不小的压力。我见过有人用默认配置去扫一个生产环境的业务系统，结果把对方的前端服务器搞得不响应了，后来不得不调整参数重新来。
合理设置并发参数是每个认真使用Nuclei的人都要学的技能。实践中我建议关注以下参数的组合：
nuclei -l targets.txt -t templates/ -c 50 -bulk-size 25 -rate-limit 150-c 50是并发模板数，含义是同一时刻最多有50个模板在跑，这个值决定了总请求吞吐量的上限。-bulk-size 25控制每个模板内部同时处理的目标数，值越大单个模板对目标的覆盖速度越快，但会给目标带来更大的压力。-rate-limit 150是每秒最大请求数，这是最直接的限流手段。
三组参数配合使用时有个经验取舍：如果目标以公网业务系统为主，-c别超过100，-rate-limit别超过300；如果目标是内网资产或资源敏感型系统，-c控制在20到50之间，-rate-limit压到50到100。针对生产环境的扫描，建议先跑到小流量观察目标反应，再逐步加量，这个道理和压测差不多。
4.4 模板调试三板斧：零基础也能定位问题
模板写完了跑不出预期结果，这是每个写模板的人都会遇到的事。排查问题我总结了三板斧，按顺序依次执行，大部分问题都能定位。
第一斧是加-v参数跑一次看详细请求响应。nuclei -u http://target -t my-template.yaml -v会把每个请求的完整URL、请求头、响应状态码、响应体部分内容都打印出来，对照模板里写的内容，一眼就能看出请求构造是否符合预期。
第二斧是用-debug参数观察请求响应细节。-debug比-v更彻底，会把发起的所有请求和收到的所有响应以原始报文格式完整输出，连响应里的每个字节都不放过。正则提取器匹配不到内容时，用这个模式能直接看到响应原文，对照正则表达式逐字检查，问题基本就暴露了。
第三斧是简化法。当模板逻辑复杂找不出问题时，先把匹配器全删了，只保留请求部分跑通，确认请求本身没有问题；再把匹配器一个一个加回来，每加一个跑一次，定位到具体是哪一步导致结果异常。
这三板斧说起来不复杂，但绝大多数模板问题都在这个流程里被消化掉了。我在带新人上手Nuclei时，会强制要求他们遇到问题先走完这三步再来问我，效率提高非常明显。
5. 第三天：实战案例与完整扫描流程
5.1 实战一：批量检测多个子域的配置泄露
假设某公司让你对公司业务系统做一次安全自查，侧重点是配置信息泄露。手头有一份子公司所有业务子域的列表，总共100多个域名，要求快速筛查一遍。
准备目标列表文件subdomains.txt，每行一个域名。再准备一个覆盖常见配置泄露路径的模板集合，比如git/config泄露、env文件泄露、DS_Store文件泄露、备份文件残留等场景。
执行扫描：
nuclei -l subdomains.txt -t config-exposure/ -c 100 -o results.txtconfig-exposure目录下放着我整理的相关模板。-o参数指定结果输出文件，所有命中记录会以文本格式写入。对于120个域名的扫描任务，并发100的情况下跑完大概需要十几分钟，视目标响应速度而定。
扫出来的结果需要逐一人工确认。Nuclei的命中判定基于规则匹配，理论上有误报可能，所以管理员验证这一步不能省。我会在浏览器里打开命中的URL，确认文件确实存在且包含敏感信息，再评估风险等级。如果是git/config泄露这种，还需要进一步检查是否连.git目录下的对象文件也能访问，如果整个仓库都能下载，风险等级就要升到高危了。
5.2 实战二：基于抓包数据反推自定义模板
有些检测需求Nuclei官方模板库没有覆盖，需要自己动手写。最典型的场景是：你在测试某个私有化部署的业务系统时发现了一个新的风险行为，想把它做成模板以备后用。
流程大概是这样的。先用抓包工具或者浏览器开发者工具，把触发风险行为时的HTTP请求完整记录下来，包括请求方法、路径、请求头、请求体。然后把关键信息转译成Nuclei模板语法，构造请求的部分照抄抓包内容，匹配逻辑根据响应特征编写。
我在一个内部系统测试中发现了某个文件上传接口存在路径穿越行为，文件名的参数可以带上../../序列来任意指定上传目录。手工复现成功以后，我写了一个模板包含两步请求：第一步探测目标系统是否具备该接口的签名特征，第二步尝试上传一个测试文件到临时目录再访问它，两步都成功才算命中。这个模板后来在多个同类系统中都有效，这就是模板复用带来的长期价值。
5.3 策略定制：按场景选择模板集与严重级别
不同场景下需要关注的模板范围差异很大。外网渗透测试更关注高危漏洞和边界设备风险，内网安全评估更关注服务弱口令和信息泄露，业务上线前的安全检查最关注越权、逻辑漏洞和敏感数据暴露。
Nuclei的模板库里对模板做了详细的分类和标签，用-tags参数可以精准筛选。检查Spring全家桶就加-tags spring，检查API安全就加-tags api，检查云服务配置错误就加-tags cloud。这种按标签筛选的方式比在一个大模板集里跑全量要高效得多——全量跑不仅耗时，而且会产生大量与目标无关的干扰结果。
严重级别过滤我用得更频繁。日常巡检业务系统时，我只关心medium以上级别的问题，因为info和low级别的发现大多是信息展示类的提示，对安全决策几乎没有参考价值；但在做全面的上线前风险评估时，我会把级别放宽到info，详细记录每一个暴露面信息，这些低级发现往往能辅助后续的攻击路径规划。
筛选方式是在命令里加-severity medium,critical，或者反过来排除-exclude-severity info,low，两种写法效果一致，看个人习惯。
5.4 结果解读：从输出信息到修复建议
扫描完成之后最重要的工作是解读结果。Nuclei的输出每一行包含了命中模板的名称、目标地址、匹配的类型和具体匹配值。以一条典型的命中为例：
[medium] git-config-exposure: https://example.com/.git/config这条结果告诉你：目标域名在/.git/config这个路径上暴露了Git配置文件，风险等级为medium。但真正专业的做法不是拿到这条结果就完事了，而是要进一步评估这个暴露可能产生什么后果。
Git配置文件泄露的直接风险是攻击者可以获取仓库的远程地址和分支信息，如果远程地址里包含内部仓库域名，攻击者就获得了内网拓扑线索；有些配置文件里会记录历史提交者的邮箱和姓名，这些信息能用于后续钓鱼攻击；更严重的情况是如果.git目录下其他对象文件也能访问，整个源码仓库都可能被拉下来。
对应的修复建议一般是两条：一是配置Web服务器规则，禁止访问所有以.git开头的路径；二是如果业务不需要通过这些域名对外提供静态资源，直接关闭相关目录的访问权限。现在很多网关产品和Web中间件都有现成的防护规则可以直接启用。
6. 常见问题与排查技巧实录
6.1 模板不命中：先检查这三个地方
模板不命中是使用频率最高的一类问题。以前面提到的Git Config检测模板为例，跑完没有结果显示，按经验优先级排查以下三个原因。
第一检查请求路径是否正确。很多目标站点的前端有反代规则，根路径/被重写到某个子目录，实际请求到后端的URL已经变了。判断方法是用-debug参数看Nuclei实际发出的请求地址，同时对比浏览器里访问真实页面的地址，两个不一致就说明反代规则影响了请求路径。
第二检查响应内容是否包含匹配关键词。目标系统可能做了防护或者定制，返回的页面格式与预期不符。比如正常暴露的.git/config文件内容包含[core]，但如果目标系统配置了自定义的错误页，任何不存在的路径都会返回同一个错误页，这时无论怎么匹配都命中不了。用-debug直接看响应体就能发现这个问题。
第三检查匹配器配置是否正确。part: body限定了只在响应体里搜索，但如果目标的关键信息出现在响应头里，就需要改成part: header或者part: all。这个细节我在写账号类系统的检测模板时踩过坑，某些接口的标识信息放在自定义响应头里，默认只匹配body的话永远不命中。
6.2 误报率居高不下：收紧匹配条件的策略
用Nuclei做批量扫描时，误报是不可避免的，关键是把它控制在可接受范围内。如果某类模板的误报率特别高，需要考虑是不是匹配条件设计得太宽松。
最常见的原因是关键词太通用。比如想检测是否存在备份文件泄露，用了backup作为匹配词，结果任何页面只要出现"backup"这个词就被判定命中，而大部分正常业务页面里都可能出现这个单词。解决思路是改用更具体的关键词组合，比如备份文件的典型特征往往是文件名里的日期格式加特定后缀，这时匹配正则比匹配单词更可靠。
另一个原因是缺少前置条件判断。很多风险行为只在特定系统或特定版本中才存在，如果不对前置条件做筛选，模板会在无关系统上产生大量无效命中。我一般会在模板开头加一个前置请求，先验证目标系统是否具备该风险行为所需的特征，验证通过后才继续执行后续检测逻辑。用stop-at-first-match参数配合前置匹配器，可以做到首步不通过就自动跳过后续步骤。
还要养成定期复核模板命中结果的意识。模板是社区贡献的，质量参差不齐，有些模板在特定环境下会产生系统性误报。每次扫描的重要命中都应该保存原始响应样本，定期抽查样本的判定准确性，发现某个模板长期高误报就从常驻模板集里移除，这会显著提升日常扫描结果的信噪比。
6.3 大规模扫描下的性能与稳定性优化
扫描几十个目标体量还算可控，一旦到了上千甚至上万个目标，就必须考虑性能问题了。我在一次大型资产盘点项目里用Nuclei扫描了将近一万个域名，整个过程折腾了几天，踩过几个性能相关的坑，这里把经验整理出来。
首先明确一点：Nuclei的并发参数不是越大越好。并发过高时会触发目标系统的限流或封禁，大量请求直接得不到响应，反而拉低整体效率。合理的做法是从低到高逐步试探，找到一个既能维持较高吞吐量又不会触发目标防护的并发值。
其次要学会使用-stats参数观察运行状态。这个参数会每隔几秒输出一次当前进度，包括完成的请求数、命中数、运行时间、并发状态等。观察一段时间后如果发现命中数长时间不增长，很可能是匹配模板都集中在了少量目标上，其余目标因为超时被反复重试，这时候应该提高超时阈值并减少并发，给慢速目标留出足够响应时间。
最后，善用-resume参数。扫描过程中断是家常便饭，网络波动、内存不足、人为中断都可能导致任务停止。-resume配合上次的任务ID可以从断点继续，不需要从头开始跑，这在动辄数小时的批量化扫描里能省大量时间。配合-output参数实时写入结果文件，中断也不丢数据。
6.4 必须避开的五个反面操作
总结一下那些最容易犯的操作错误，这些错误我在带新人和做技术评审时反复见到。
第一个反面操作是不更新模板库直接开扫。Nuclei引擎本身更新频率不算高，但模板库几乎每天都有新增和修复。拿着一个月前的模板库去做新漏洞相关的排查，效果可想而知。正确做法是扫描前先执行nuclei -update-templates，确保用的是最新规则。
第二个反面操作是忽略目标授权。这个点必须强调：Nuclei是安全测试工具，用途是检测自己拥有或获得授权测试的系统。在未授权的情况下对任意目标发起扫描，既有法律风险也有道德问题。每次扫描前我都会确认目标范围有明确授权，这个习惯在行业内属于基本职业素养。
第三个反面操作是全量模板跑全量目标。默认配置下Nuclei会载入所有模板并对所有目标跑一遍，这种无差别扫描会生成海量低质量结果，还会浪费大量扫描时间。正确做法是按目标特性筛选模板集，Web业务用Web类模板，主机资产用网络类模板。
第四个反面操作是忽略输出结果的保存。Nuclei默认只把结果打印在终端，如果不加-o参数，跑完就真的什么都没留下。不仅本次结果丢失，后续想做数据统计、复查误报都无从谈起。养成每次扫描都指定输出文件的习惯，命中的原始响应也要尽量保存。
第五个反面操作是盲目修改模板后不验证。不少人在复制模板时顺手改了一两个关键词，改完也不跑测试就直接投入生产用，结果要么整批漏报要么整批误报还浑然不觉。任何模板修改后都要先用已知目标验证，确认改动方向正确再规模化使用，这个步骤必不可少。
7. 写在最后：三天之后怎么继续进阶
三天学下来，你已经掌握了Nuclei的模板语法、请求编排、调试方法和实战策略，这个基础已经能支撑你在大多数日常场景中独立完成安全检测任务了。
接下来进阶的方向有三条路线可以选，每个人兴趣不同路径也不同。一条是往协议深度走，深入研究非HTTP协议的检测场景，比如网络设备的服务指纹识别、加密流量的特征分析，这需要额外补充协议底层知识；一条是往模板工程化管理走，学习如何搭建团队内部的模板仓库、做模板版本管理和质量评审，把个人能力转化为团队资产；还有一条是往漏洞原理研究走，从"会用模板检测"进阶到"理解漏洞为什么存在"，这条路对后续做漏洞分析、代码审计都有帮助。
我个人实际使用中的体会是，Nuclei最大的价值不在于它本身有多聪明，而在于它把安全测试的经验沉淀机制做到了极致。每一次检测逻辑的固化，都是对重复劳动的一次解放。模板写得越多、积累越久，你在这个领域的操作效率会越来越高，这种复利效应是手工测试完全没办法比的。
最后分享一个我坚持了很久的小习惯：每次做完一个项目的扫描，不管有没有新发现，都会顺手把这次用到的目标特征、处理思路和几个调好的模板存到自己的知识库里。半年之后回头翻，这些存档不仅是技术笔记，更是自己在这个领域成长轨迹的见证。工具会不断迭代，模板会不断更新，但沉淀下来的方法论和判断力，才是真正属于自己的能力。
