最近可能由於許多大公司都在訓練 LLM ，網路上的 AI 爬蟲流量大增。許多軟體業的論壇都傳出災情，維護論壇的工程師紛紛表示，『怎麼網站又崩潰了？ AI 爬蟲讓網站不堪負荷…』
不知道是巧合或是真的就是 AI 爬蟲，總之，我任職的 Gaiwan 公司所維護的一個網站Clojurians Log ，它也崩潰了。
Clojurian Log
簡單介紹一下 Clojurians Log 這個網站：在 Clojure 社群，許多的討論都是發生在 Slack 上，而 Slack 有兩個小小的缺點：
Slack 很貴。如果沒有付費，只有 90 天的歷史記錄。
Slack 的頻道裡的討論內容，無法被蒐尋引擎找到。
Gaiwan 公司認為，昔日的社群討論提供了極高的價值，應該要設法讓這些資訊長存，所以開發了一套軟體，它可以將特定 Slack 頻道的內容撈出，變成了一個可以長久保存、並且被蒐尋引擎搜索的內容網站服務。
reverse proxy 限速
由於該網站本來就已經使用 CloudFlare 在最前端先阻擋一層了，這意謂著，如果真的是 http get flood 的攻擊，通常已經被阻擋下了 80% 以上。另一方面，其實該網站的效能一直有改進的空間，它就只是從資料庫撈取資料並且加以呈現，並沒有為資料庫做出種種的最佳化。該網站正常的流量是：『 developer 在查資料時，反覆地查尋某個問題的前人研究歷史，才會走進該網站。』換言之，正常的情況也不會有太密集的流量，提昇效能好像也沒有必要，就放一邊了。
基於以上的資訊，我主觀判斷：「很有可能只是 10 個 IP ，它用了一般人也許 100 倍的速度去送出 http get request ，所以網站就崩潰了。那也許做個限速就可以過關了。」
該網站有用 Nginx 來做 Reverse Proxy，而 Nginx 某種程度就已經可以做為 DDoS 的防火牆，因為它提供了：
限制連線數 (
limit_conn)限制 http request 的速度 (
limit_req)限制傳輸頻寬 (
limit_rate)
我套用了 Nginx 的 rate limiting 功能加以限速之後，再重開網站，網站就活過來了。
後續的資料分析
第一時間處理時，先想著讓網站復活再說。事後仔細想想，其實我應該要設法釐清真正的崩潰原因，到底是 DDoS 攻擊，還是 AI 爬蟲，又或是其它原因。
Nginx 預設的存取記錄，儲存在 /var/log/nginx/access.log 這個檔案裡。網站重啟後之後一陣子，我有用肉眼監看了一下這個存取記錄，並且用一些輔助指令來分析。
輔助指令
;; 檢查哪些 IP 發送大量請求
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head資料分析的目標是要尋找什麼呢？異常流量總是有一些特徵足以辨識出來：
總結
這次 Clojurians Log 的網站崩潰事件，雖然當下讓人措手不及，但事後回顧，其實也是一次讓整體架構更堅固的契機。透過 reverse proxy 提供的限速機制，網站在不改動後端邏輯的情況下，成功擋下異常流量。後續搭配簡單的資料分析指令，也讓我們有機會能在日後快速定位潛在問題來源，區分出到底是來自攻擊、爬蟲，或只是偶發性的尖峰使用。
這類內容型網站的維運處於一個模糊地帶：一方面因為流量偏低，改進效能的投資也通常不足；但是，在預算有限的前提之下，只使用 reverse proxy 、不改動後端邏輯的作法，還是可以解決很大一部分的問題。只是說，這也考驗了身為 IT 專業人士的知識廣度了。