Hacker News
A developer reports that Meta's crawlers are hitting their self-hosted instance's robots.txt file several times per second without accessing any other content, suggesting a potential loop error in Meta's infrastructure.
AI 生成摘要
在過去的四天裡，Facebook 的爬蟲以每秒多次的頻率不斷存取我自行架設實例的 robots.txt 檔案，卻完全沒有存取其他任何內容，這讓我懷疑 Meta 內部的程式邏輯是否出了問題。
一名自架 Forgejo 實例的開發者發現，Meta 旗下的 Facebook 爬蟲（facebookexternalhit）在過去幾天內以每小時高達 7700 次的頻率，瘋狂請求其網站的 robots.txt 檔案。儘管該爬蟲來自 Meta 的官方 IP 位址，且並未進一步存取其他網頁內容，但這種異常且高頻率的重複行為引發了技術社群對於大型企業爬蟲機制設計與維運品質的熱烈討論。
針對這起異常的爬蟲行為，Hacker News 社群普遍認為這反映了 Meta 工程實踐上的粗糙。許多討論者指出，即使是三十年前的搜尋引擎爬蟲，也懂得根據內容更新頻率來調整抓取間隔，而 Meta 的系統顯然缺乏基本的快取機制或狀態追蹤。儘管作者提到伺服器已設定了長達六小時的快取控制標頭，但 Meta 似乎完全無視這些指令。社群成員分析，這可能是因為 Meta 的爬蟲系統是由無數獨立的執行緒或叢集實例組成，而這些實例之間缺乏協調機制，導致每個節點都獨立且重複地請求同一個檔案，最終形成了這種變相的阻斷服務攻擊。
部分留言者從企業組織文化的角度切入，認為這種「壞掉」的狀態在大型科技公司中其實是常態。在「錯誤預算」的框架下，只要這類異常行為造成的損失未達營收的一定比例，或者修復成本高於維持現狀的支出，工程團隊往往會選擇忽視。這種現象被視為一種懶惰的工程設計，因為追蹤上次請求時間並非技術難題，但在龐大的架構中，這類小問題往往被淹沒在更高優先級的任務之下。
此外，社群也討論了應對這類惡意爬蟲的策略。有人提議使用「壓縮炸彈」來反擊，但隨即遭到反對，認為這可能導致爬蟲判定網站失效進而轉向抓取其他受保護的內容。另一種觀點則建議利用重新導向將流量導回 Meta 自身的伺服器，或者乾脆封鎖整個子網段。更有經驗的維運者分享了類似的慘痛經驗，提到 AI 浪潮下的爬蟲對 Wiki、論壇和 Git 倉庫造成了毀滅性的負擔，這些爬蟲往往不選擇下載現成的資料轉儲檔，而是透過數百萬次的網頁請求來耗盡目標伺服器的資源。這顯示出當前網路生態中，大型企業的自動化工具與個體網站主之間的權力不對等，以及開發者在面對不負責任的爬蟲時所面臨的無奈。
在討論中，有使用者提到可以透過 Cloudflare 等 CDN 服務來過濾非必要的爬蟲流量，並建議網站管理員應主動限制 Web 伺服器（如 Apache 或 Nginx）的併發處理上限，以防止這類高頻請求拖垮整個系統硬體資源。