CrowdSec 的组件主要通过 HTTP API 通信，因此不必全部装在同一台主机上。设计多服务器部署时，首先要分清：谁读取日志，谁把告警变成决策，谁真正执行阻断。把这些职责拆开，可以混合使用 Linux、Windows 和容器，但不会自动获得跨节点的事件聚合能力。

先画清楚三个角色

日志处理器（log processor）读取各自的日志，使用解析器解析，再根据场景（scenario）判断行为是否达到检测条件。它把产生的告警发送给本地 API。这里“本地”是组件名称，并不要求它与日志处理器运行在同一台机器上。

Local API，简称 LAPI接收告警，并根据 profiles 把告警转换成决策。它还负责与 CrowdSec 的 CAPI 通信，例如拉取阻断列表，以及把相关告警推送到控制台所使用的服务。

阻断或处置组件（remediation component，常称 bouncer）向 LAPI 查询应该执行的决策，再在具体系统中落实，例如通过防火墙或 Nginx 对恶意来源执行拦截。

官方给出的混合部署示例包括：一台 Linux 主机运行 LAPI；一台 Windows 主机同时运行日志处理器与 Windows Firewall 组件；Linux 上的 Docker 容器运行另一套日志处理器，宿主机部署 Linux Firewall 组件；Web 服务器则使用 Nginx 阻断组件。这些节点通过共同的 LAPI 交换告警与决策。

这份配置采用什么认证方式

为便于说明，官方指南主要采用日志处理器的用户名与密码认证：客户端注册，中央 LAPI 审核机器身份，之后使用生成的凭据连接。

另一条路线是 TLS 认证。原文链接目前指向官方 Next 版本文档，实际部署应切换到对应安装版本。这种方式不要求沿用同一套逐台验证流程，但需要自行建立并管理 PKI。选用哪条路线，应结合已有证书基础设施决定；本文没有配置证书，也没有把用户名密码认证误写成传输加密。

操作边界：以下步骤以已经安装 CrowdSec、具备对应机器的管理权限为前提。Linux 软件包常用路径是 /etc/crowdsec/；Windows、容器和不同部署方式的路径及重启方式需要按实际安装调整。本稿只做静态审查，没有运行命令或修改服务器。

第一步：配置中央 LAPI

先按 官方入门指南安装 CrowdSec。然后在运行 LAPI 的主机上编辑 /etc/crowdsec/config.yaml，使其他机器能够访问 API。原文展示的监听配置是：

api:
  server:
    listen_uri: 0.0.0.0:8080

配置审查：0.0.0.0 表示所有 IPv4 网络接口，会扩大 API 的可达范围。优先根据网络拓扑选择需要的私有监听地址，并用防火墙限制来源；不要把这个片段当成“可以直接暴露到公网”的建议。此片段也没有配置 TLS，不能仅把客户端 URL 改成 https:// 就获得可用的加密服务。跨不可信网络时，应先完成并验证合适的传输保护。

如果这台机器只承担 LAPI 职责，可以按指南在同一文件里移除 crowdsec_service 配置段，从而停用日志处理器。不要把停用日志处理器与停用整个 CrowdSec 服务混为一谈。

可选：自动注册日志处理器

每次增加日志处理器都手工审批可能较繁琐。LAPI 支持用共享令牌配合来源网段来自动注册机器。下面的内容应合并进已经存在的 api.server 配置段：

api:
  server:
    auto_registration:
      enabled: true
      token: "long_token_that_is_at_least_32_characters_long"
      allowed_ranges:
        - 10.0.0.0/24

token 和 allowed_ranges 都是必填项。示例令牌只是占位文本，正式使用时应换成足够长的随机秘密，不能使用文中所有人都看得到的字符串。示例中的 10.0.0.0/24 也仅说明 CIDR 写法，应缩小为实际获准的来源范围。

为何需要严格限制：被接纳的日志处理器能够向 LAPI 提交告警，而告警又可能变成阻断决策。一个不可信处理器提交任意告警，可能把管理员自己的地址封掉。因此令牌安全与来源限制会直接影响整套系统的完整性和可用性。

若要同时采用所有接口监听和自动注册，配置文件中仍然只应有一个 api、一个 server 映射，把 listen_uri 和 auto_registration 放在同一层级。本稿保留官方两个说明片段，特意补充了合并要求，避免复制粘贴后出现重复 YAML 键而使配置被覆盖。

完成修改后，按部署方式重启 CrowdSec，使设置生效。修改之前应保留原配置与管理连接的恢复办法，因为错误的监听、凭据或决策规则可能让节点失联。

解析器和 profiles 应该放在哪里

LAPI 收到的是告警，它不承担这些日志的解析和场景匹配。因此，解析器和场景应安装在实际处理日志的节点上，不必为了这一职责在纯 LAPI 节点重复安装。

如果需要改变决策规则，例如阻断持续时间，应修改 LAPI 主机上的 /etc/crowdsec/profiles.yaml。在日志处理器上修改同名文件，不会替中央 LAPI 改变生成决策的规则。

第二步：把日志处理器注册到 LAPI

每台处理日志的机器也先完成 CrowdSec 安装。默认安装可能自带本机 LAPI；如果本次部署要统一使用远端 LAPI，可按指南从该节点的 /etc/crowdsec/config.yaml 中移除整个 api.server 段，停用不再需要的本机 API 服务。

然后在日志处理器所在机器上注册身份：

sudo cscli lapi register --machine MyMachineName --url <lapi_url>

MyMachineName 是该节点在 LAPI 中的机器名，<lapi_url> 是实际 LAPI 地址。尖括号只是文档占位符，执行前必须替换，不能原样复制进 shell；URL 的协议必须与已配置的传输方式匹配。命令会自动生成凭据，并把它们写入 /etc/crowdsec/local_api_credentials.yaml。

静态审查：注册会改变本机凭据文件以及 LAPI 机器注册状态，属于真实配置操作。对已有节点重新注册前，应确认名称和凭据归属，避免意外覆盖现有连接设置。凭据文件包含秘密，应只让确有需要的服务身份和管理员读取，不应提交到源码库或公开工单。

如果 LAPI 已启用自动注册，可在命令中传入令牌：

sudo cscli lapi register --machine MyMachineName --url <lapi_url> --token long_token_that_is_at_least_32_characters_long

这里仍是官方命令结构，令牌要换成真实部署中约定的值。命令行参数可能出现在 shell 历史、进程参数或运维采集记录中，应按环境采取秘密保护措施；不能把示例字符串当成有效认证资料。本稿没有提供或使用任何真实凭据。

手工注册时，在中央主机审批

如果没有启用自动注册，就到运行 LAPI 的主机上验证新机器：

sudo cscli machines validate MyMachineName

审批前应确认这个名字对应预期的节点，不能只因为请求出现在列表里就信任它。完成自动注册或手工验证后，重启日志处理器，让它使用新凭据。

在 LAPI 主机上列出机器：

sudo cscli machines list

检查 Status 列，以及机器名、来源 IP、最近更新时间和心跳等信息。官方示例是一台名为 MyMachineName 的机器，版本为 v1.6.4-debian-pragmatic-amd64-523164f6-linux，操作系统为 Ubuntu 24.04，认证类型为 password。示例中的 2024 年时间戳和版本只是当时的输出，不表示部署时应安装这个旧版本，也不表示本次进行了连通性测试。

再回到日志处理器机器，检查凭据能否完成认证：

sudo cscli lapi status

官方输出会说明从 /etc/crowdsec/local_api_credentials.yaml 载入凭据，显示尝试连接的用户名与 LAPI 地址，并在成功时报告能够与 Local API 交互。这里只说明预期检查点，不伪造当前机器的成功输出。每增加一台日志处理器，都应重复注册与验证流程。

集中决策不等于集中检测

这一点是多服务器部署最容易忽略的限制：日志处理器之间不共享它们已经观察到的事件。中央 LAPI 汇集的是告警，并不会让各处理器自动拥有其他节点尚未达到告警阈值的日志状态。

例如，负载均衡器把同一来源的请求随机分到多台 Web 服务器，每个日志处理器只能看到自己服务器的那部分日志。一段恶意行为原本可能很快达到检测阈值，拆散以后，每个处理器都需要更久才积累够事件。

官方在这种场景下建议使用集中日志方案，让一个日志处理器读取汇集后的日志。这是对检测观察范围的调整，应结合日志量和可用性需求规划；不能用“所有节点连了同一个 LAPI”作为跨节点阈值已经合并的证明。

第三步：连接阻断组件

阻断组件与日志处理器使用不同的认证资料。日志处理器向 LAPI 提交告警，阻断组件则持 API key 读取决策。安装阻断组件时，如果它与 LAPI 在同一台主机，安装流程通常会尝试自动创建 key；多服务器部署中往往没有这个条件，需要手工创建。

在 LAPI 所在主机执行：

sudo cscli bouncers add MyBouncer

命令创建名为 MyBouncer 的身份并显示 API key。应当立即把新生成的 key 安全保存，因为之后不能用相同的查询方式重新取回它。本文有意不复制官方示例中的那串看起来像真实密钥的输出，避免误用公开演示值；这项编辑改动不影响命令含义。

接下来，在阻断组件的配置文件中填入刚生成的 API key 与 LAPI URL。常见配置目录是 /etc/crowdsec/bouncers/，但具体文件名、key 字段与 URL 字段随组件而异，应查阅所安装组件的文档，不能假设 Nginx、Linux Firewall 与 Windows Firewall 共享同一份配置格式。

官方指南说明，从 CrowdSec v1.6.4 开始，运行在不同机器上的多个阻断组件可以使用同一个 API key。这个版本门槛不表示必须共享：为不同组件分开管理 key，可以让身份归属和失效处理更清楚。采用共享 key 时，要理解任何一处泄露或轮换都会影响所有使用者。

核对整条链路，而不是只看某个服务在运行

完整的数据流是：日志处理器读取正确日志并产生告警，LAPI 接收告警并按 profiles 形成决策，阻断组件认证成功后读取并应用这些决策。cscli lapi status 成功能证明这一客户端的 API 认证可用，却不能独立证明解析器、场景和最终网络拦截都已正确配置。

本文已经对配置层级、命令执行位置、身份资料、版本说明与网络暴露面做静态审查。没有修改监听地址、注册机器、创建 API key、重启服务或应用任何阻断决策。实际部署仍应在受控环境验证日志和处置链路，并确保管理员有恢复访问的办法。