企业官网建设流程全解析

1. 这不是一份“安装文档”，而是一份Wazuh部署现场的故障日志复盘

Wazuh不是点几下Next就能跑起来的图形化软件，它是一套基于Elastic Stack构建的、面向生产环境的开源安全监控与合规平台。我第一次在Ubuntu 22.04上部署Wazuh Manager时，以为照着官网文档走完curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash wazuh-install.sh -a就万事大吉——结果卡在第3步：Elasticsearch服务反复崩溃，日志里只有一行java.lang.OutOfMemoryError: Java heap space。后来发现，这根本不是配置错误，而是Wazuh安装脚本默认把Elasticsearch堆内存设为2GB，而我的测试虚拟机只有3GB总内存，系统连Swap都没开。这种“安装失败”背后，是资源规划、依赖版本、系统内核参数、SELinux/AppArmor策略、甚至Python模块编译环境等多重因素的叠加失效。

你搜“Wazuh 安装踩坑指南”，大概率正被某个具体报错卡住：可能是wazuh-manager服务启动失败，也可能是wazuh-indexer无法注册节点，或是wazuh-dashboard页面空白显示“Kibana is not ready”。这些表象背后，本质是Wazuh不是一个独立运行的单体程序，而是一个由Wazuh Manager（分析引擎）、Wazuh Indexer（替代Elasticsearch的专用索引器）、Wazuh Dashboard（可视化前端）和Wazuh Agent（终端探针）四个核心组件构成的分布式系统。它们之间通过HTTP/gRPC通信，共享TLS证书体系，共用一套集群发现机制。任何一个环节的证书不匹配、端口被占用、Java版本不兼容、或系统ulimit限制过低，都会导致整个链路中断——而安装脚本往往只告诉你“Failed”，却不告诉你失败在哪一层。

这份指南不讲“第一步下载脚本，第二步执行安装”，而是还原我在三类典型环境（物理服务器、VMware虚拟机、Docker容器）中部署Wazuh 4.7.x的真实过程：记录每一次systemctl status wazuh-manager返回的Exit code，截图journalctl -u wazuh-manager -n 50 --no-pager里的关键报错行，保存/var/ossec/logs/ossec.log中Agent注册失败的完整上下文。我会告诉你，为什么apt install openjdk-17-jre-headless比apt install default-jre更稳妥；为什么/etc/security/limits.conf里对wazuh用户的nofile设置必须大于65536；为什么在VMware里启用vmxnet3网卡驱动能避免Agent心跳包丢包；以及最关键的——如何用wazuh-control工具绕过安装脚本，分步验证每个组件的健康状态。如果你刚接触Wazuh，建议先跳到第4节“常见问题速查表”，找到你的报错关键词，再回溯对应章节的根因分析。这不是教程，是故障排除手册。

2. 安装方案选型：为什么放弃All-in-One脚本，转向手动分步部署

2.1 All-in-One脚本的便利性与隐藏陷阱

Wazuh官方提供的wazuh-install.sh脚本确实省事：一行命令自动完成Indexer、Dashboard、Manager的下载、解压、配置、服务注册和启动。它适合快速搭建POC环境，但在我经手的17个生产部署案例中，有12个首次安装失败都源于该脚本的“过度自动化”。问题不在于脚本本身有Bug，而在于它做了三件危险的事：

第一，无差别覆盖系统配置。脚本会强制修改/etc/sysctl.conf，添加vm.max_map_count=262144和fs.file-max=65536，然后执行sysctl -p。这在干净的Ubuntu系统上没问题，但如果目标服务器已运行MySQL或Nginx，fs.file-max被调高可能导致其他服务文件描述符耗尽。更致命的是，它会直接覆盖/etc/default/wazuh-indexer中的JAVA_HOME路径，而这个路径可能与系统已有的Java环境冲突。

第二，静默降级依赖版本。当检测到系统已安装OpenJDK 11时，脚本不会报错退出，而是自动卸载并重装OpenJDK 17。但在某些定制化内核（如AWS Graviton ARM64实例）上，OpenJDK 17的ARM版存在JIT编译器缺陷，会导致Indexer进程CPU占用率100%且无响应。此时脚本已完成安装，你只能手动回滚。

第三，证书生成逻辑过于理想化。脚本默认使用openssl req -x509 -nodes -days 3650生成自签名证书，密钥长度固定为2048位。而Wazuh 4.7要求Indexer与Dashboard间通信必须使用SHA-256签名的证书，2048位RSA密钥在部分FIPS合规环境中不被接受。脚本不校验证书签名算法，只检查文件是否存在，导致Dashboard启动后反复报错Invalid certificate signature algorithm。

提示：All-in-One脚本仅推荐用于全新安装的Ubuntu 22.04/24.04或CentOS 8 Stream虚拟机，且内存≥4GB、磁盘≥50GB。若服务器已运行其他Java服务（如Tomcat、Logstash），或需对接现有Elasticsearch集群，请务必跳过此脚本。

2.2 手动分步部署的底层逻辑与收益

我最终采用的方案是：完全弃用wazuh-install.sh，改用Wazuh官方APT仓库+手动配置+分步验证。核心逻辑是将Wazuh拆解为三个独立可验证的单元：

• Indexer单元：专注解决数据存储与检索。它替代了Elasticsearch，但并非完全兼容——Indexer使用RocksDB作为底层存储引擎，不支持Elasticsearch的DSL查询语法。因此，必须单独验证其集群状态（curl -k -u admin:admin https://localhost:9200/_cat/health?v）、证书有效性（openssl s_client -connect localhost:9200 -servername indexer -CAfile /etc/wazuh-indexer/certs/root-ca.pem）和索引创建能力（curl -k -X PUT "https://localhost:9200/test-index?pretty" -H "Content-Type: application/json" -d'{"settings":{"number_of_shards":1}}' -u admin:admin）。

• Manager单元：作为分析中枢，它不直接处理数据，而是将Agent上报的日志解析后转发给Indexer。关键验证点是/var/ossec/etc/ossec.conf中<indexer>段落的URL、证书路径和认证凭据是否与Indexer实际配置一致；同时检查/var/ossec/logs/ossec.log是否有INFO: Connected to indexer字样。

• Dashboard单元：本质是Kibana的定制分支，所有可视化依赖Indexer的API响应。必须确认其/usr/share/wazuh-dashboard/config/wazuh.yml中wazuh.hosts[0].url指向正确的Indexer地址，且wazuh.ssl.verification_mode设置为strict（而非none）以启用证书校验。

这种分步法的收益是故障定位效率提升3倍以上。例如，当Dashboard页面显示“Unable to fetch Wazuh API information”时，传统方式需重启全部服务并翻查数十个日志；而分步法下，我只需执行：

# 验证Indexer是否存活 curl -k -I https://localhost:9200 2>/dev/null | head -1 # 验证Manager能否连接Indexer sudo /var/ossec/bin/wazuh-control status | grep indexer # 验证Dashboard配置是否正确 grep -A 5 "hosts:" /usr/share/wazuh-dashboard/config/wazuh.yml

三步即可锁定问题在Indexer证书未被Dashboard信任，而非盲目重装。

2.3 环境适配决策树：从物理机到云环境的选型依据

不同部署环境对Wazuh组件有差异化要求，以下是基于我实际部署经验的决策树：

特别注意：不要在WSL2中部署Wazuh Manager。WSL2的网络栈与Windows宿主共享，导致Indexer监听的0.0.0.0:9200端口被Windows防火墙拦截，而wazuh-control start命令无法提示此错误。我曾为此耗费11小时排查，最终解决方案是改用原生Ubuntu VM。

3. 核心细节解析：从系统准备到证书生成的27个关键操作点

3.1 系统层预检：被90%教程忽略的5项硬性要求

Wazuh对操作系统的要求远超一般应用。以下检查必须在执行任何安装命令前完成，否则后续所有操作都是徒劳：

1. 内核版本与模块支持
Wazuh Agent的syscheck（文件完整性监控）和rootcheck（恶意软件扫描）依赖Linux内核的fanotify和inotify接口。执行：

uname -r # 必须≥5.4.0（Ubuntu 20.04默认） zcat /proc/config.gz | grep -i "fanotify\|inotify" # 输出应含=y

若fanotify为m（模块），需加载：sudo modprobe fanotify，并写入/etc/modules永久生效。

2. 文件描述符限制
Wazuh Manager需同时处理数千Agent连接，ulimit -n必须≥65536。编辑/etc/security/limits.conf：

wazuh soft nofile 65536 wazuh hard nofile 65536 * soft nofile 65536 * hard nofile 65536

然后重启shell或执行sudo su - wazuh -c 'ulimit -n'验证。注意：此设置对systemd服务无效，还需修改/etc/systemd/system/wazuh-manager.service，在[Service]段添加：

LimitNOFILE=65536

3. 时间同步精度
Wazuh组件间通信依赖精确时间戳，时钟偏差＞5秒会导致证书校验失败。强制使用chrony而非ntpd：

sudo apt install chrony -y sudo systemctl enable chrony && sudo systemctl start chrony chronyc tracking # 输出应显示System clock offset < 10ms

4. SELinux/AppArmor策略
Ubuntu默认启用AppArmor，其/etc/apparmor.d/usr.sbin.wazuh-manager策略文件存在路径白名单漏洞。临时禁用验证：

sudo aa-disable /usr/sbin/wazuh-manager sudo systemctl restart wazuh-manager

若服务正常，则需更新AppArmor策略，而非永久禁用。

5. Python环境隔离
Wazuh Manager自带Python 3.9解释器（位于/var/ossec/framework/python/bin/python3），但某些插件（如AWS S3日志导入）需额外模块。切勿用系统pip安装，而应：

sudo /var/ossec/framework/python/bin/python3 -m pip install boto3

否则/var/ossec/framework/python/下的site-packages会被污染，导致Manager启动时报ImportError: No module named 'wazuh'。

注意：以上5项检查缺一不可。我曾遇到一个案例，客户服务器ulimit -n显示65536，但/etc/security/limits.conf未配置wazuh用户，导致Manager启动后仅能维持200个Agent连接，第201个连接即被拒绝，错误日志却只显示socket: too many open files，无任何进程名提示。

3.2 依赖安装实操：OpenJDK、Git、Systemd的精准版本控制

Wazuh 4.7.x明确要求OpenJDK 17（非Oracle JDK），且必须是headless版本（无GUI组件，减少攻击面）。以下是经过验证的安装流程：

OpenJDK 17安装
Ubuntu 22.04默认源提供openjdk-17-jre-headless，但版本为17.0.1，而Wazuh 4.7.3需17.0.2。手动下载Debian包：

wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.2%2B8/OpenJDK17U-jre_x64_linux_hotspot_17.0.2_8.deb sudo dpkg -i OpenJDK17U-jre_x64_linux_hotspot_17.0.2_8.deb sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17.0.2+8-jre/bin/java 1 sudo update-alternatives --set java /opt/java/jdk-17.0.2+8-jre/bin/java

验证：java -version输出应为17.0.2，且which java指向/opt/java/jdk-17.0.2+8-jre/bin/java。

Git配置要点
Wazuh Manager需Git拉取规则集更新。关键配置是禁用SSL验证（因内网Git服务器无有效证书）：

git config --global http.sslVerify false git config --global user.name "wazuh" git config --global user.email "wazuh@localhost"

但此配置存在安全风险，生产环境应改为：

git config --global http."https://git.internal.company.com/".sslCAInfo /etc/ssl/certs/internal-ca.crt

Systemd服务优化
Wazuh官方service文件未设置内存限制，导致Indexer在内存不足时OOM。编辑/etc/systemd/system/wazuh-indexer.service：

[Service] MemoryLimit=3G RestartSec=30 Restart=on-failure Environment="JAVA_HOME=/opt/java/jdk-17.0.2+8-jre"

然后执行sudo systemctl daemon-reload。

3.3 证书体系构建：从Root CA到Node证书的7步手工签发

Wazuh的TLS证书体系是故障高发区。All-in-One脚本生成的证书常因subjectAltName缺失导致Dashboard无法连接Indexer。以下是符合RFC 5280标准的手工签发流程：

步骤1：生成Root CA私钥与证书

openssl genrsa -out root-ca.key 4096 openssl req -x509 -new -nodes -key root-ca.key -sha256 -days 3650 -out root-ca.pem \ -subj "/C=US/ST=California/L=San Francisco/O=Wazuh/CN=Wazuh Root CA"

步骤2：创建Indexer证书请求配置
新建indexer.cnf：

[req] default_bits = 4096 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [dn] C = US ST = California L = San Francisco O = Wazuh CN = indexer [req_ext] subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = indexer IP.1 = 127.0.0.1 IP.2 = 192.168.1.100 # 替换为服务器实际IP

步骤3：生成Indexer私钥与CSR

openssl genrsa -out indexer.key 4096 openssl req -new -key indexer.key -out indexer.csr -config indexer.cnf

步骤4：用Root CA签发Indexer证书

openssl x509 -req -in indexer.csr -CA root-ca.pem -CAkey root-ca.key -CAcreateserial \ -out indexer.pem -days 3650 -sha256 -extfile indexer.cnf -extensions req_ext

步骤5：生成Dashboard证书（复用同一CA）
dashboard.cnf中CN = dashboard，alt_names包含DNS.1 = dashboard和服务器IP。

步骤6：生成Manager证书
Manager证书的alt_names必须包含所有Agent将连接的IP/DNS，例如：

IP.1 = 192.168.1.100 DNS.1 = manager.local DNS.2 = wazuh-manager.company.com

步骤7：证书权限与路径标准化
所有证书文件必须属主wazuh，权限600：

sudo chown -R wazuh:wazuh /etc/wazuh-indexer/certs/ sudo chmod 600 /etc/wazuh-indexer/certs/*.pem /etc/wazuh-indexer/certs/*.key

且路径必须严格匹配配置文件：

• Indexer：/etc/wazuh-indexer/certs/
• Dashboard：/usr/share/wazuh-dashboard/certs/
• Manager：/var/ossec/etc/wazuh-cert/

实操心得：证书签发后，务必用openssl verify -CAfile root-ca.pem indexer.pem验证链完整性。若返回OK，再执行curl -k -v https://localhost:9200检查TLS握手是否成功。很多“连接被拒绝”错误实为证书校验失败，而非端口未监听。

4. 实操过程全记录：从零开始部署Wazuh 4.7.3的逐行命令与结果分析

4.1 环境初始化：Ubuntu 22.04虚拟机的12项预配置

我使用的测试环境是VMware Workstation 17.0，虚拟机配置：4 vCPU、4GB RAM、50GB SSD。以下是开机后的首屏操作：

1. 系统更新与基础工具安装

sudo apt update && sudo apt upgrade -y sudo apt install curl wget gnupg2 apt-transport-https software-properties-common -y

2. 添加Wazuh APT仓库

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh-stable.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/wazuh-stable.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update

3. 安装OpenJDK 17.0.2（如前所述）
略，见3.2节。

4. 创建专用用户与目录

sudo useradd -r -s /sbin/nologin wazuh sudo mkdir -p /etc/wazuh-indexer/certs /usr/share/wazuh-dashboard/certs /var/ossec/etc/wazuh-cert sudo chown -R wazuh:wazuh /etc/wazuh-indexer /usr/share/wazuh-dashboard /var/ossec

5. 配置系统参数

echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf echo "fs.file-max=65536" | sudo tee -a /etc/sysctl.conf sudo sysctl -p

6. 预检ulimit

echo "wazuh soft nofile 65536" | sudo tee -a /etc/security/limits.conf echo "wazuh hard nofile 65536" | sudo tee -a /etc/security/limits.conf

7. 安装Indexer

sudo apt install wazuh-indexer -y sudo systemctl daemon-reload

8. 部署Indexer证书
将前述生成的root-ca.pem、indexer.pem、indexer.key复制到/etc/wazuh-indexer/certs/，并设置权限。

9. 配置Indexer
编辑/etc/wazuh-indexer/opensearch.yml：

plugins.security.allow_default_init_securityindex: true plugins.security.ssl.transport.pemcert_filepath: certs/indexer.pem plugins.security.ssl.transport.pemkey_filepath: certs/indexer.key plugins.security.ssl.transport.pemtrustedcas_filepath: certs/root-ca.pem plugins.security.ssl.http.pemcert_filepath: certs/indexer.pem plugins.security.ssl.http.pemkey_filepath: certs/indexer.key plugins.security.ssl.http.pemtrustedcas_filepath: certs/root-ca.pem

10. 启动Indexer并验证

sudo systemctl enable wazuh-indexer sudo systemctl start wazuh-indexer sleep 30 # 等待集群初始化 curl -k -u admin:admin https://localhost:9200/_cat/health?v # 应返回 green 状态

11. 安装Dashboard

sudo apt install wazuh-dashboard -y

12. 部署Dashboard证书
将root-ca.pem、dashboard.pem、dashboard.key复制到/usr/share/wazuh-dashboard/certs/，权限600。

此时，Indexer与Dashboard已就绪，但尚未关联。下一步是配置Dashboard连接Indexer。

4.2 Dashboard配置：3个文件的17处关键参数详解

Dashboard的配置分散在三个文件中，任何一处错误都会导致前端白屏：

文件1：/usr/share/wazuh-dashboard/config/wazuh.yml
这是Dashboard连接Indexer的主配置：

wazuh: - hosts: - url: https://192.168.1.100:9200 # 必须是Indexer监听的IP，不能用localhost username: admin password: admin nodes: 1 ssl: verification_mode: strict # 绝对不可设为none！ certificate_authorities: - /usr/share/wazuh-dashboard/certs/root-ca.pem

关键点：url必须使用服务器实际IP，因Dashboard容器内localhost指向自身而非Indexer；certificate_authorities路径必须绝对准确，且root-ca.pem内容需与Indexer使用的CA完全一致。

文件2：/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml
这是Kibana框架的通用配置：

server.host: "0.0.0.0" server.port: 5601 opensearch.ssl.verificationMode: strict opensearch.ssl.certificateAuthorities: ["/usr/share/wazuh-dashboard/certs/root-ca.pem"] opensearch.username: "admin" opensearch.password: "admin" opensearch.requestTimeout: 90000

关键点：server.host必须设为0.0.0.0，否则Dashboard仅监听本地回环；requestTimeout需≥90秒，因Indexer首次启动需加载大量规则集。

文件3：/usr/share/wazuh-dashboard/config/kibana.yml（旧版遗留）
Wazuh 4.7仍保留此文件，需注释掉所有elasticsearch.*配置，否则会与opensearch_dashboards.yml冲突：

# elasticsearch.hosts: ["https://localhost:9200"] # elasticsearch.username: "admin" # elasticsearch.password: "admin"

配置完成后，启动Dashboard：

sudo systemctl enable wazuh-dashboard sudo systemctl start wazuh-dashboard sudo journalctl -u wazuh-dashboard -n 50 --no-pager | grep -i "listening\|error"

正常输出应含Server running at http://localhost:5601。若出现Error: connect ECONNREFUSED 127.0.0.1:9200，说明wazuh.yml中url配置错误。

4.3 Manager安装与Agent注册：从服务启动到首条告警的全流程

Manager是Wazuh的神经中枢，其安装需与Indexer、Dashboard协同：

1. 安装Manager

sudo apt install wazuh-manager -y

2. 配置Manager连接Indexer
编辑/var/ossec/etc/ossec.conf，在<ossec_config>内添加：

<indexer> <url>https://192.168.1.100:9200</url> <user>admin</user> <password>admin</password> <ssl> <certificate_authorities>/var/ossec/etc/wazuh-cert/root-ca.pem</certificate_authorities> </ssl> </indexer>

注意：<url>必须与Dashboard配置中的url完全一致；certificate_authorities路径需存在且可读。

3. 部署Manager证书
将root-ca.pem、manager.pem、manager.key复制到/var/ossec/etc/wazuh-cert/，权限600。

4. 启动Manager

sudo systemctl enable wazuh-manager sudo systemctl start wazuh-manager sudo journalctl -u wazuh-manager -n 50 --no-pager | grep -E "(Connected to indexer|ERROR)"

成功日志应含INFO: Connected to indexer。

5. 注册首个Agent
在另一台Ubuntu机器上安装Agent：

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh-stable.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/wazuh-stable.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-agent -y sudo /var/ossec/bin/manage_agents # 选择"A"添加Agent，记下Key

回到Manager服务器，执行：

sudo /var/ossec/bin/manage_agents # 选择"E"提取Key，粘贴到Agent端 sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent

6. 验证Agent状态
在Manager上执行：

sudo /var/ossec/bin/agent_control -l # 应显示Agent状态为"Active" sudo tail -f /var/ossec/logs/ossec.log | grep -i "received message from agent"

约1分钟后，Dashboard前端应出现首条告警：“New agent registered”。

5. 常见问题与排查技巧实录：21个真实报错的根因与速修方案

5.1 Indexer类问题：从集群红灯到索引损坏的应急处理

问题1：curl -k -u admin:admin https://localhost:9200/_cat/health?v返回red
根因：Indexer节点无法形成集群，通常因discovery.seed_hosts未配置或防火墙阻断9300端口。
速修：

# 检查集群配置 sudo grep -A 5 "discovery.seed_hosts" /etc/wazuh-indexer/opensearch.yml # 应为：discovery.seed_hosts: ["192.168.1.100:9300"] # 开放端口 sudo ufw allow 9300 sudo systemctl restart wazuh-indexer

问题2：Indexer service failed with exit code 143
根因：OOM Killer终止进程，因MemoryLimit设置过低或Java堆内存不足。
速修：

# 查看OOM日志 dmesg -T | grep -i "killed process" # 调整Java堆内存 sudo sed -i 's/-Xms2g -Xmx2g/-Xms3g -Xmx3g/' /etc/wazuh-indexer/jvm.options sudo systemctl restart wazuh-indexer

问题3：Failed to create index [.wazuh-monitoring-10-2024.05.01]
根因：Indexer磁盘空间不足或/var/lib/wazuh-indexer分区满。
速修：

df -h /var/lib/wazuh-indexer # 清理旧索引（谨慎！） curl -k -X DELETE "https://localhost:9200/.wazuh-monitoring-10-2024.04.*" -u admin:admin

5.2 Dashboard类问题：前端白屏与API失效的诊断链

问题4：Dashboard页面显示Kibana server is not ready yet
根因：Dashboard无法连接Indexer，99%因证书校验失败。
速修：

# 检查证书链 sudo openssl verify -CAfile /usr/share/wazuh-dashboard/certs/root-ca.pem \ /usr/share/wazuh-dashboard/certs/dashboard.pem # 若失败，重新签发Dashboard证书，确保`subjectAltName`包含服务器IP

问题5：Error: Unable to fetch Wazuh API information
根因：Manager未向Indexer推送API元数据。
速修：

# 强制Manager同步 sudo /var/ossec/bin/wazuh-control restart # 检查Manager日志 sudo tail -50 /var/ossec/logs/ossec.log | grep -i "api" # 应含`INFO: API started on port 55000`

问题6：Dashboard登录后空白，Network标签显示401 Unauthorized
根因：/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml中opensearch.username/password与Indexer的admin凭据不匹配。
速修：

# 重置Indexer管理员密码 sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh -p admin # 将输出的hash替换到/etc/wazuh-indexer/opensearch-security/config/opensearch-security/config.yml sudo systemctl restart wazuh-indexer

5.3 Manager与Agent类问题：连接中断与日志丢失的深度排查

问题7：ossec.log持续刷ERROR: Connection refused, waiting for server
根因：Manager未监听Agent连接端口（1514/1515），或防火墙阻止。
速修：

# 检查Manager监听状态 sudo ss -tlnp | grep :1514 # 若无输出，检查/var/ossec/etc/ossec.conf中<remote>段落 # 应含：<port>1514</port> 和 <protocol>tcp</protocol> sudo ufw allow 1514

问题8：Agent注册成功，但无日志上报
根因：Agent配置中<server>IP错误，或Manager的<client><use_password>设为yes但未配置密码。
速修：

# 在Agent端检查配置 sudo cat /var/ossec/etc/ossec.conf | grep -A 5 "<server>" # 应为：<address>192.168.1.100</address> # 在Manager端检查密码配置 sudo grep -A 3 "<client>" /var/ossec/etc/ossec.conf # 若<use_password>yes，则需在Agent端执行： sudo /var/ossec/bin/manage_agents -a # 重新生成带密码的Key

问题9：wazuh-control status显示wazuh-manager为inactive (dead)，但ps aux | grep wazuh有进程
根因：systemd服务文件Type=forking与Manager实际启动模式不匹配。
速修：

# 编辑服务文件 sudo nano /etc/systemd/system/wazuh-manager.service # 将Type=forking改为Type=simple sudo systemctl daemon-reload sudo systemctl restart wazuh-manager

5.4 系统级问题：资源争用与内核参数失效的终极解法

问题10：systemctl start wazuh-indexer后立即退出，journalctl无日志
根因：/etc/security/limits.conf