上一节你按 profiling 报告找出慢规则，用更具体的内容与修饰符重写，重跑对比优化前后的检查次数与耗时，并在同一份 PCAP 上确认告警仍然命中——单条规则层面的优化闭环走通了。但这样的验证只覆盖了手头这几条规则。企业里的规则不会只有你手头这几条：官方规则集需要持续更新，自研规则在增长，试验规则需要地方试错。全部混在一个文件里，一次官方更新就可能覆盖你的修改，一次试验规则上线就可能淹没生产告警；更糟的是，谁也说不清当前到底加载了哪些规则，出了问题无法定位是规则错、配置错，还是情报源变了。

这里先做两件事：设计规则集的分层目录，说清 suricata-update 与威胁情报源的集成方式。suricata-update 负责拉取、更新并管理规则，默认模式获取 ET Open 规则集；更新后的规则安装在 /var/lib/suricata/rules，最终由单一的 suricata.rules 文件组成。分层是骨架，集成是血液：层分得清，情报源接得稳，回归测试才有意义。先规划再动手，是因为下一节的部署会直接依赖这里的目录与源选择；现在改错路径，比上线后改错路径便宜得多。

suricata-update 的工作流可以拆成四步。第一步，拉取：从配置的规则源获取最新规则，默认模式获取 ET Open 规则集。第二步，合并：把各来源的规则输出为单一的 suricata.rules 文件。第三步，安装：运行 sudo suricata-update，把合并结果放到默认位置 /var/lib/suricata/rules。第四步，加载：执行 sudo systemctl restart suricata，引擎按 suricata.yaml 的配置读取规则文件。

规则文件只是文本，真正生效靠引擎按配置加载；任何手动改动都要与这个流程对齐，否则会被下一次更新冲掉。重启不是可选项：suricata-update 只负责把规则文本写到磁盘，加载动作由引擎完成，不重启，新规则不会生效。每次运行后，可以用 sudo tail /var/log/suricata/suricata.log 确认引擎状态，日志里的路径信息是排查加载问题的第一手线索。

分层落到目录上，可以这样设计。下面是可行方案之一，不是 Suricata 强制路径；最终以你的 suricata.yaml 配置为准。

/var/lib/suricata/rules/          # suricata-update 聚合区（默认位置）
└── suricata.rules                # 官方来源合并后的单一规则文件
/etc/suricata/rules/custom/       # 自定义规则区，按用途分子目录
├── web-attacks.rules
├── dns-tunneling.rules
└── local-experiments.rules       # 试验规则，评审后再进生产

三条设计要点。第一，官方区只交给 suricata-update 维护，你不手动编辑，否则下一次更新会把你的手工修改冲掉。第二，自定义区按威胁类别分子目录，文件名即用途，新规则先落在 local-experiments.rules。第三，任何文件进入加载列表，都要在 suricata.yaml 中声明；路径写错时，引擎日志会指出问题，按日志核对每个路径即可。每条自研规则沿用你已掌握的 classtype 与 reference，保证告警可归类、可溯源。版本管理上，自定义目录建议纳入 Git 一类的版本库，每次变更留下记录；文件命名用「类别-作用」的约定，比如 web-phpinfo.rules、dns-tunnel.rules，命名统一，告警溯源时一眼就能定位到规则文件。目录是骨架，规则是肌肉，sid 与元数据是关节，三者对齐，规则集才能长期演进。