Wazuh authd 連線數達上限導致無法註冊

Jason Cheng 發布 2026.11.09 瀏覽 1 次

本文目錄

問題徵狀
先分清楚卡在哪一段
問題排除過程
原因：authd 連線數達到上限
處理方式
預防與監控
問題排除步驟整理
結論
參考資料

新主機裝好 Wazuh agent，Dashboard 上卻怎麼找都找不到，舊主機又一切正常，該從哪裡查起？

這是最近處理的一個客戶案例。客戶的 Wazuh 叢集管理約 545 台 agent，一開始只有一台新主機查不到，重裝 agent 也一樣；過了幾週，變成每一台新主機都查不到。客戶一度以為是 manager 的金鑰檔與內部資料庫不同步，於是轉來詢問。

實際原因是 manager 上負責註冊的 wazuh-authd，同時處理中的註冊連線已經滿了（上限約 1,000 條），新主機的註冊請求一連上就被關掉。重新啟動 manager 就能恢復，但 4.14.8 以前的版本會再發生，要升級到 4.14.9 以上才算解決。

注意：這裡的 1,000 不是 agent 數量的上限，545 台 agent 也沒有用掉其中 545 條。authd 只在註冊時使用（新主機，或金鑰失效需要重新註冊的主機），註冊完成就斷線；已註冊的 agent 平常連的是另一個服務（1514 埠的 wazuh-remoted），不佔 authd 的連線。正常情況下 authd 同時只有幾條連線，這次把 1,000 條佔滿的，是連上 1515 之後既不完成註冊、也不關閉的連線。

問題徵狀

新主機查不到
新裝的 agent 不在 Dashboard 的 Agents 清單上，重裝也一樣。
舊主機正常
已註冊的 agent 持續回報、狀態 active，告警也照常進來。
某天開始全部失敗
8 月中以前用同樣流程可以註冊，之後才開始失敗，多台主機、不同網段結果都一樣。

agent 端的記錄每分鐘重試一次，每次都是同一個錯誤：

新主機的 agent-auth 註冊失敗：SSL error (1). Connection refused by the manager

訊息後半句提示「可能是連接埠設錯」，但連接埠沒有錯，這句話在這個案例裡會把方向帶偏。

先分清楚卡在哪一段

「新主機看不到」有三種完全不同的情況，問題排除的方向也不一樣：

情況	代表的問題	檢查方向
清掉篩選、確認帳號權限後，清單上仍沒有	註冊沒成功	1515 註冊服務（authd）
清單上有，但沒有資料	資料傳送或寫入	1514 與 indexer
有資料，但畫面上看不到	篩選或權限	Dashboard 篩選條件、使用者權限

Wazuh 的 agent 預設用兩個連接埠（本文都以預設的 TCP 1514、1515 說明）：1515 只在註冊時用，由 wazuh-authd 發給 agent 一組金鑰；註冊完成後，agent 只用 1514（wazuh-remoted）傳送資料。所以 1515 出問題時，持有有效金鑰的主機不受影響，只有新主機與需要重新註冊的主機註冊不了，跟這次的徵狀吻合。

問題排除過程

確認新主機不在清單上

Agents 頁上方預設有 status=active 篩選，已註冊但還沒連上的 agent 狀態是 never_connected，會被藏起來。請客戶先清掉篩選，再用新主機的 IP 搜尋，結果是 0 筆。

注意清單上的 IP 是 manager 看到的來源位址，經過 NAT 時會跟主機自己的 IP 不同，用 IP 查不到還不能斷定沒註冊，用主機名稱查或在 manager 上執行 manage_agents -l 比較可靠。這次是靠下一步的 manager 記錄確認。

manager 記錄完全沒有這幾台

authd 收到註冊請求時，會先記一行 Received request for a new agent (名稱) from: IP，成功是 Agent key generated，被拒絕則有 Duplicate name、Invalid password provided by IP 這類記錄。在 manager 的 ossec.log 搜尋三台新主機的 IP，什麼都沒有。搜尋前要確認三件事：查的是實際接收註冊的節點、記錄涵蓋失敗的時間、來源 IP 沒有經過 NAT 改變。

在 manager 的 ossec.log 搜尋新主機 IP，完全沒有記錄（依原始畫面重新繪製，主機名稱與 IP 為示意值）

這三件事都確認過仍然完全沒有記錄，代表註冊請求根本沒有被 authd 處理。「金鑰與資料庫不同步」「名稱重複」「註冊密碼錯誤」都會留下記錄，可以一起排除。

1515 連上就斷

客戶的基礎架構團隊從一台早就註冊好的主機測試，1514、1515 的 TCP 都連得上；封包記錄顯示 1515 在三向交握後約 0.5 毫秒，manager 還沒收到任何資料就送出 FIN，之後對 TLS 的 ClientHello 回 RST。用 openssl s_client 測，拿不到憑證、讀到 0 bytes：

從已註冊的主機測試：1514、1515 的 TCP 都通，但 1515 拿不到憑證（依原始輸出重新繪製）

這是很強的線索。連線在 TLS 握手之前就被關閉，server 連憑證都沒送出，原因就不在憑證、註冊密碼或主機名稱，而是接受連線的那一方直接把連線關掉。可能是中間的負載平衡或轉送設備、防火牆或 IPS，也可能是 authd 自己拒收。

在 manager 本機測自己的 1515

要分辨是網路還是服務，最快的方法是在 manager 本機連自己的 1515，中間不經過任何設備：

在 manager 本機連 127.0.0.1:1515，一樣拿不到憑證，問題在 manager 本機

本機一樣拿不到憑證，網路設備就可以排除，問題在 manager 本機。

注意：客戶第一次執行時，把指令後面的全形冒號一起複製進去，openssl 回 Servname not supported for ai_socktype。用 -host 與 -port 分開寫，比較不會發生這種情況。

authd 有在跑，記錄裡全是 Too many connections

先確認 1515 確實由 wazuh-authd 監聽、服務也在跑，排除埠被其他程式佔用或服務沒啟動：

1515 由 wazuh-authd 監聽，wazuh-authd 與 wazuh-remoted 都在執行

再看 authd 自己的記錄，答案就在這裡，每隔幾秒一筆：

authd 記錄滿是 Too many connections. Rejecting.，連線數已經到達上限

authd 其實一直在寫這個錯誤，只是平常很少有人看 manager 自己的 ossec.log。

原因：authd 連線數達到上限

authd 同時最多處理約 1,000 條註冊連線（與已註冊的 agent 數量無關）：4.14.8 以前閒置連線不會被關閉，4.14.9 起連上 30 秒還沒產生回應就關閉

Wazuh 原始碼 src/headers/defs.h 把 authd 同時處理的連線數上限定為 1,000：

#define AUTH_POOL       1000                        /* Max number of connections        */

authd 每接受一個連線，就在連線池裡找一個空位；找不到空位時，記一筆錯誤後直接關閉連線（src/os_auth/main-server.c）。連線池從第 1 格開始分配，所以實際最多容納 999 條，本文為了好讀寫成約 1,000 條：

if (client_index == -1) {
    merror("Too many connections. Rejecting.");
    ...
    close(client_sock);
    continue;
}

連線一被接受就關掉，還輪不到 TLS 握手，這就是外面看到的「TCP 連上、還沒收到資料就 FIN」與 no peer certificate。

這個上限只管註冊連線

看到「1,000 條上限」，很容易以為是 agent 太多。其實 agent 跟 manager 之間有兩種連線，AUTH_POOL 只限制註冊用的那一種：

	註冊連線	資料連線
服務與埠	`wazuh-authd`，1515	`wazuh-remoted`，1514
用途	新主機註冊或重新註冊、取得金鑰	已註冊的 agent 傳送事件與狀態
連線多久	註冊完成就關閉	agent 運作期間一直保持（預設 TCP）
受 AUTH_POOL 1,000 限制	是	否

所以 545 台 agent 平常都在 1514，跟 authd 的 1,000 條無關。正常情況下 authd 只有正在註冊的幾台主機，同時 1,000 條全滿，表示裡面幾乎都是不該留著的連線。

連線為什麼會被佔滿

對方正常關閉的連線，authd 會釋放這個連線，所以一般的連線測試、送出關閉封包的掃描不會累積。問題出在連上之後既不完成註冊、也不關閉的連線。4.14.8 以前的 authd 對這種連線沒有逾時，也沒有開 TCP keepalive，這個連線會一直佔著不放：

連上之後不送資料、或握手完只送一部分就停住的連線
對方已經消失，但關閉封包沒有送到 manager，例如註冊到一半斷線、主機斷電，或中間的防火牆、NAT 設備把閒置連線的狀態清掉
有人故意大量建立連線、把連線數佔滿的攻擊

這種連線只要持續產生、又沒有回收，遲早會累積到上限，這也解釋了「某天開始全部失敗」。累積的速度取決於來源，可能是幾週慢慢累積，也可能短時間大量湧入。這次事件沒有實際查出是哪個來源佔用 1515，確認的只有連線池已滿、重新啟動後恢復，上面是依原始碼推論的常見來源。

Wazuh 官方修正的 PR 標題把它定位成不需驗證就能讓所有主機無法註冊的問題：能連到 1515 的人，開 1,000 個連線不關，就能讓新主機與需要重新註冊的主機全部註冊失敗，直到對方放掉連線或 authd 重新啟動。

4.14.9 的修正

Wazuh 4.14.9 的 CHANGELOG 寫著，修正 wazuh-authd 讓閒置的註冊連線一直開著的問題，連上 30 秒還沒產生回應的連線會被關閉（PR #39539）。原始碼差異（4.14.8 → 4.14.9）：

--- wazuh v4.14.8 src/os_auth/auth.h
+++ wazuh v4.14.9 src/os_auth/auth.h
+#define AUTH_IDLE_CONN_TIMEOUT 30   /* Seconds a connection may stay idle before completing its enrolment request */
+#define AUTH_EPOLL_WAIT_MS     1000 /* epoll_wait tick used to sweep idle connections */

--- wazuh v4.14.8 src/os_auth/main-server.c
+++ wazuh v4.14.9 src/os_auth/main-server.c
+static void sweep_idle_clients(void) {
+    time_t now = w_get_monotonic_time();
+    for (int j = 1; j < AUTH_POOL; j++) {
+        if (g_client_pool[j] && g_client_pool[j]->write_len == 0 &&
+            now - g_client_pool[j]->connected_at >= AUTH_IDLE_CONN_TIMEOUT) {
+            mdebug2("Closing idle enrolment connection from %s (slot %d)", g_client_pool[j]->ip, j);
+            delete_client(j);
+        }
+    }
+}

每個連線多記錄連上的時間，事件迴圈改成每秒醒來一次，把連上超過 30 秒、還沒有回應要送出的連線關掉。我抽查原始碼，4.8.0、4.12.0、4.14.5、4.14.7、4.14.8 都沒有這段（AUTH_POOL 同樣是 1,000），4.14.9、4.14.10 有。連線上限沒有改，只是閒置連線不會再一直佔著。

處理方式

立即恢復：重新啟動 manager

sudo systemctl restart wazuh-manager

重新啟動會釋放 authd 佔住的所有連線，這次新主機在重新啟動後馬上就註冊成功。注意重新啟動的是整個 manager，分析與 API 等服務也會中斷片刻；已註冊的 agent 會短暫斷線，事件先暫存在 agent 端的佇列，之後自動重新連線。重新啟動前先用「預防與監控」一節的 ss 指令記下 1515 的連線數與來源，重新啟動後這些線索就沒了。4.14.8 以前的版本連線數會再慢慢被佔滿，重新啟動只是暫時解決。

無法重新啟動時：手動匯入金鑰

如果暫時不能重新啟動 manager，可以不經過 1515，在 manager（叢集要在 master 節點）上手動新增 agent 並取出金鑰，再到新主機匯入：

# manager（master）上：新增 agent，再匯出它的金鑰
sudo /var/ossec/bin/manage_agents -a any -n new-host-01
sudo /var/ossec/bin/manage_agents -l | grep new-host-01
sudo /var/ossec/bin/manage_agents -e <agent ID>

# 新主機上：執行後選 I 匯入金鑰，貼上金鑰並確認
sudo /var/ossec/bin/manage_agents
sudo systemctl restart wazuh-agent

匯入金鑰後，agent 只需要 1514 就能開始回報。重新啟動前先確認 agent 的 ossec.conf 裡 <client><server><address> 指向 manager；叢集環境會由 master 把金鑰同步到各 worker。金鑰等同這台 agent 的身分，請勿貼在聊天群組或工單裡，用互動選單貼上，也不會像 -i 參數那樣留在 shell 的指令歷程。

根本解決：升級到 4.14.9 以上

4.14.10 已在 2026/11/05 發佈，除了包含 4.14.9 的 authd 修正，也有多項安全性修正，我建議直接升到 4.14.10。以下是我自己的環境升級時注意的幾件事，屬於重點摘要，實際操作請照官方升級指南的完整步驟：

先備份
manager 的 /var/ossec/etc（含 ossec.conf、client.keys、自訂規則）、/var/ossec/api/configuration、自訂的整合程式，以及 indexer、dashboard、filebeat 的設定目錄。資料面的完整備份（manager 資料庫、indexer 快照）照官方備份指南做。
升級順序
先停 filebeat 與 dashboard，再依 indexer → manager master → 各 worker → dashboard 的順序升級。indexer 多節點時逐台升級，cluster_manager 角色的節點最後升。中央元件的版本要完全一致（含修補版號），升級過程中版本不同的 worker 會暫時連不上 master，全部升完就恢復。
indexer
升級前把分片配置設成只配置主分片（cluster.routing.allocation.enable: primaries）並執行 flush，升級後改回來，確認節點都回來、叢集狀態回到 green（多節點環境不要停在 yellow 就當作完成）。
設定檔
manager 的 ossec.conf 保留現有設定，升級後確認沒有被覆蓋。indexer 的 jvm.options、dashboard 的 opensearch_dashboards.yml，官方做法是升級前備份、升級後把自訂值套回新版檔案。
filebeat 範本要手動更新
不要只靠重新啟動 filebeat。官方流程是先下載新版 Wazuh filebeat 模組與對應版本的 wazuh-template.json，再執行 filebeat setup --pipelines 與 filebeat setup --index-management -E output.logstash.enabled=false。
agent 不必跟著升
agent 版本可以低於 manager，但不能高於 manager。

升級後除了確認 wazuh-control status 全部服務在跑、新告警持續進來，也在 manager 本機執行一次 echo | openssl s_client -host 127.0.0.1 -port 1515，看得到 subject= 憑證資訊，代表 authd 有在接受連線；最後還是要實際註冊一台測試主機，確認它出現在清單上、狀態是 active。

預防與監控

限制誰能連 1515
1515 只需要讓準備註冊的主機連，不必對所有網段開放。這是防止連線數被惡意佔滿最直接的做法，升級後也值得做。
健康檢查與掃描避開 1515
負載平衡、監控系統的 TCP 檢查，或弱點掃描、資產探測工具，可以排除 1515 或改檢查其他項目，減少不必要的連線。
看 manager 自己的記錄
連線數到達上限時 Too many connections. Rejecting. 就會出現，把這句納入告警，就能在使用者回報之前發現。
新主機部署流程最後確認一次
確認 agent 已出現在清單上、狀態是 active，才算部署完成。

想知道目前 1515 上掛了多少連線、哪個來源最多，可以在 manager 上執行：

# 目前 1515 上已建立的連線數
sudo ss -Htn state established '( sport = :1515 )' | wc -l

# 依來源 IP 統計，看是誰佔最多
sudo ss -Htn state established '( sport = :1515 )' | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head

數字接近 1,000，或同一個來源佔了大量連線，就要找出那台主機在做什麼，再從防火牆限制或調整它的設定。

問題排除步驟整理

下次遇到新主機在 Wazuh 上看不到，可以照這個順序查，每一步都能縮小範圍。

步驟一：agent 在不在清單上

Dashboard 先清掉 status=active 篩選、確認登入帳號看得到所有 agent，用主機名稱搜尋；或在 manager（master）上：

sudo /var/ossec/bin/manage_agents -l | grep -i new-host-01

在清單上只是沒資料，往 1514 與 indexer 查；不在清單上，繼續下一步。

步驟二：manager 有沒有收到註冊請求

sudo grep -iE "new-host-01|10.20.30.41" /var/ossec/logs/ossec.log
# 連同已封存的舊記錄（路徑依事件發生的年月調整）
sudo sh -c 'zgrep -h -iE "new-host-01|10.20.30.41" /var/ossec/logs/wazuh/2026/Aug/ossec-*.log.gz'

Agent key generated：manager 產生過金鑰，先看 agent 端記錄確認有收到並保存，再查 agent 為什麼連不上 1514
Duplicate name：manager 上有同名的記錄。先核對 agent ID、最後連線時間，確認是同一台主機重灌留下的舊記錄才刪除；不同主機就改用不同名稱
Invalid password provided by：註冊密碼錯誤
完全沒有記錄（已確認節點、時間與來源 IP）：請求沒有被 authd 處理，繼續下一步

步驟三：看 agent 端記錄

Linux 在 /var/ossec/logs/ossec.log，Windows 在 C:\Program Files (x86)\ossec-agent\ossec.log。

SSL error (1). Connection refused by the manager：TCP 連上了但 TLS 交握失敗，可能是 manager 端直接關閉連線（本次案例），也可能是 TLS 設定不相容，要搭配 manager 記錄判斷
(1208): Unable to connect to enrollment service：連不到 1515，查網路、防火牆、manager 位址
Duplicate agent name、Invalid password：manager 回傳的拒絕原因，見步驟二

步驟四：從問題主機測 1514、1515

for p in 1514 1515; do
  echo "== port $p =="
  timeout 5 bash -c "exec 3<>/dev/tcp/wazuh-mgr.example.com/$p && echo 'TCP connected'" 2>&1
done
echo | openssl s_client -host wazuh-mgr.example.com -port 1515 2>&1 | grep -E "CONNECTED|peer certificate|subject|errno"

Windows 可以用 Test-NetConnection wazuh-mgr.example.com -Port 1515 測 TCP。TCP 連不上，查網路、防火牆、manager 位址，以及 authd 有沒有在監聽；看得到 subject= 代表 1515 有回應，問題多半在註冊內容，回頭看步驟二的記錄；TCP 通但 no peer certificate，繼續下一步。

步驟五：在 manager 本機測 1515

echo | openssl s_client -host 127.0.0.1 -port 1515 2>&1 | grep -E "CONNECTED|peer certificate|subject|errno"

本機看得到憑證、遠端拿不到，往中間的網路設備與 manager 的主機防火牆查，並確認 manager 網域解析出來的位址是不是這台 manager；本機也拿不到憑證，先查 manager 本機。

步驟六：確認 authd 狀態與記錄

sudo ss -ltnp | grep -E ':1514|:1515'
sudo /var/ossec/bin/wazuh-control status | grep -E "authd|remoted"
sudo grep -E "authd|enroll" /var/ossec/logs/ossec.log | tail -40

出現 Too many connections. Rejecting. 就是本文的連線數達到上限；1515 由其他程式監聽是埠被佔用；authd 沒在跑就看啟動錯誤。