封 AI 爬蟲卻把 Googlebot 一起擋掉？Cloudflare 新版 AI 流量控制的三個分類與一個期限
上個月寫過一篇文章，講 Cloudflare 網路上的 HTML 請求有 57.5% 來自機器人、真人只剩 42.5%（那篇在這）。當時的結論偏哲學：網站的讀者已經一半不是人，你要為誰設計。哲學歸哲學，實務上站長手上的工具只有一個很鈍的開關——Cloudflare 儀表板那顆「Block AI Bots」。它針對的主要是拿內容去訓練模型的爬蟲，但只有開和關兩個狀態，你沒得挑要擋哪一種。 7 月 1 日 Cloudflare 把這顆開關拆了。新版的 AI 流量控制把「AI bot」切成三種用途分開管，連免費方案都能用。更重要的是他們同時宣布：9 月 15 日起預設值要變，而且變法會讓「封鎖 AI 訓練」連 Googlebot 一起擋掉。如果你的站在 Cloudflare 後面、又開過 Block AI Bots，這篇讀完建議去檢查一下設定。 一鍵封鎖為什麼不夠用先講舊開關的問題在哪。 去年那顆「Block AI Bots」的假想敵很明確：拿你的內容去訓練模型、然後一滴流量都不回給你的訓練爬蟲。封它天經地義。但一年下來，「AI bot」這個詞涵蓋的東西越來越雜。有人問 ChatGPT...
Sitemap 卡「無法擷取」三個月？修了四輪 XML 都沒用，最後把它搬到 Cloudflare Worker 才過關
今天打開 Search Console，看到這一行： 1/sitemap.xml 2026年6月8日 2026年6月11日 成功 612 狀態「成功」，系統探索到的網頁 612。我盯著它看了幾秒，因為文章也累積到一些數量了，想著要讓Google搜尋能搜尋到，結果到現在，這一欄一直是紅色的「無法擷取」。整整三個月，Google 連我的 sitemap 都不願意讀，全站文章只有首頁被索引。 最後解決問題的那一步，跟 sitemap 的內容一點關係都沒有。這篇把整個排查過程寫下來，包含三次「修對了東西但沒解決問題」的彎路——如果你的 GitHub Pages 部落格也卡在這個狀態，也許可以少走幾步。 問題長什麼樣我的部落格是 Hexo 生成、部署在 GitHub Pages（kyosora.github.io）。三月中建站時把 sitemap.xml 提交到 Search Console，狀態顯示「無法擷取」（Couldn't fetch）。 當時想說剛建站，Google 需要時間。結果這個狀態凍結了快三個月，期間「已送出」日期一直停在 3 月 17 日，系統...
以為是 App Pool 的鍋，結果 IUSR 被 Windows 偷走了
上週為了讓同事拉一份檔案，我在測試機上把 IIS 專案資料夾開了個進階共用。東西傳完後我把共用關掉，繼續回頭改別的東西。 十分鐘後測試站同事回訊息：整個網站 HTTP 401，連 /favicon.ico 都打不開。 我第一個念頭是「我剛剛根本沒動 web.config 啊？」然後花了半小時繞遠路——這篇就是想分享這個坑，因為症狀跟原因之間的距離遠到不合理。 症狀 瀏覽器吃到 401 Unauthorized 連 CSS、圖片這類靜態檔都 401 IIS 沒有動過站點設定 專案程式碼沒動過 App Pool 跑得好好的，沒當機、沒停 重啟 IIS 沒用 翻開 IIS 記錄（C:\inetpub\logs\LogFiles\W3SVC...），關鍵那行： 12sc-status: 401sc-substatus: 3 401.3 的官方說明是 「Access is denied due to an ACL set on the requested resource」——翻譯：這不是 IIS 驗證設定的問題，是 NTFS 層級擋下來的。 我第一個走錯的方向本能反應是去翻 App ...
打開 APEX 就藍屏重啟？用 PowerShell 事件日誌 10 分鐘找出元兇
按下 APEX 啟動鍵。讀取畫面跑完。然後——藍屏，重啟。 再試一次。還是藍屏。 這個問題困擾我好一陣子了。頻率不固定，有時候連開三場沒事，有時候進遊戲讀完畫面就炸。因為不是每次都觸發，排查起來格外惱人——你沒辦法穩定重現，就很難判斷到底是哪裡出問題。 我走過的彎路我一開始懷疑是熱當。APEX 吃資源本來就兇，我的 GPU 溫度跑到八九十度是常態，藍屏的時間點又剛好在遊戲載入高峰，看起來太像過熱了。 所以我先更新了顯示卡驅動。沒用。 接著我把 APEX 的相關路徑全部加進火絨的安全區，怕是防毒軟體跟 EasyAntiCheat 打架。也沒用。 問題就這樣斷斷續續，每隔幾天炸一次，炸完重開又能玩，讓人很難下定決心認真查。直到某天連續藍屏兩次，我受不了了，想到一件事——AI 現在不是很會讀 log 嗎？不如直接把事件日誌丟給它看。 這個決定救了我大概一整個晚上的時間。 BSOD 0x0000001a 是什麼MEMORY_MANAGEMENT。聽起來嚇人，實際上這個停止碼涵蓋範圍很廣，代表 Windows 核心在管理記憶體時遇到嚴重的不一致狀態。 溫度、驅動、防毒——我之前懷疑的方...
你的 AI 帳單即將縮水 30 倍：一天之內 NVIDIA 和 OpenAI 同時給出的訊號
3 月 16 日晚上，兩件事同時發生。 Jensen Huang 在 GTC 主題演講上揭曉 Groq 3 LPU，宣稱每瓦 tokens 效能提升 35 倍。幾個小時後，Sam Altman 在 X 上發文：GPT-5.2 到 5.4，三個月內效率提升 32 倍，每個任務成本降到 37 美分。 兩家公司，一硬一軟，同一天給出幾乎相同的數字。這不是巧合。 硬體端：Groq 3 LPU 到底是什麼NVIDIA 在 2025 年底花 200 億美元買下 Groq 的核心團隊和技術。GTC 上第一次展示成果：Groq 3 LPU（Language Processing Unit），專門為推理設計的晶片。 跟 GPU 最大的差異在架構。GPU 用 HBM（高頻寬記憶體）做訓練和推理都行，但推理階段的記憶體存取模式跟訓練完全不同。LPU 用 SRAM 直接塞在晶片上，消除了記憶體瓶頸。結果就是：推理延遲極低，每瓦輸出的 tokens 數量暴增。 NVIDIA 的做法很聰明。LPX 機架裝 256 顆 LPU，設計成放在 Vera Rubin GPU 機架旁邊一起用。訓練用 GPU，推理用 ...
當銅線跑不動 AI：NVIDIA 花 40 億美元押注光子學，你的 GPU 叢集正在碰上物理極限
我在追蹤 NVIDIA GTC 2026 的預告資訊時，撞上一個讓我停下來想了很久的數字：2 公尺。 在 1.6 Tb/s 的傳輸速度下，銅線的訊號完整性和散熱問題，讓它連 2 公尺都撐不住。這不是理論推導，是工程實測。NVIDIA 在 3 月 2 日宣布砸 40 億美元投資 Lumentum 和 Coherent 兩家光子學公司，接著在 GTC 發表 Spectrum-X 和 Quantum-X 矽光子網路交換器。 銅線時代正在結束。如果你在管 AI 叢集，或者你的工作跟 GPU 運算基礎設施沾上邊，這件事值得花十分鐘搞懂。 問題出在哪：銅線碰上了物理牆GPU 跑得再快，資料傳不過去就是白搭。 現代 AI 訓練和推理的瓶頸早就不只在運算力。一個 NVL72 機架裡塞了 72 張 Rubin GPU，它們之間的資料交換量是天文數字。第六代 NVLink 的頻寬達到 260 TB/s，但這些資料要在 GPU 之間、機架之間、甚至跨資料中心移動。 銅線在低速時代不是問題。但當每個埠口要跑 1.6 Tb/s，物理定律就開始反咬： 訊號衰減：高頻電訊號在銅線裡跑得越遠，衰減越嚴重。2 ...
curl 能下載、Node.js 卻 fetch failed——在 WSL2 + Docker 裡修好 OpenClaw Telegram Bot 圖片上傳的全過程
我用 OpenClaw 在 WSL2 + Docker 環境架了一個 Telegram Bot，接上 OpenAI Codex 的 vision model，打算讓它能看圖回答問題。結果使用者傳圖片過來，Bot 只回了一句「我看到的是 <media:image>，沒有實際圖片內容」。 這個 Bug 花了我整個晚上，最後發現根因是：OpenClaw 內部的 SSRF 防護機制建立了自己的 HTTP dispatcher，覆蓋掉了 WSL2 專用的 IPv4 網路設定，導致圖片下載靜默失敗。 curl 完全正常，Node.js fetch 卻怎麼都不行。 這篇文章記錄完整的追蹤過程。如果你也用 OpenClaw 架 Telegram Bot、或在 WSL2 + Docker 裡跑 Node.js 服務遇到 TypeError: fetch failed，這篇或許能幫上忙。 什麼是 OpenClawOpenClaw 是一個開源的 AI agent gateway，可以把 LLM（Claude、GPT、Ollama 等）接上 Telegram、Discord、Slack ...
當 IIS 遇到代理伺服器：如何在複雜網路環境下實現真實 IP 白名單控制
前情提要：測試機被臨時收走台電那邊因為要做白帽滲透測試，得暫時把測試機關掉。但開發團隊三不五時還是需要一個能驗功能的環境，於是我們把程式臨時搬到另一台機器上跑。原本盤算著，IIS 設個 IP 白名單就能擋住外人，半小時搞定。結果這個白名單，前後折騰了我大半天。 問題：白名單一開，全員 403我在 IIS 管理器的「IP 位址及網域限制」裡，把信任的 IP 一個個加進白名單，存檔，重新整理頁面。畫面回我一個乾脆的 403。 換個設定再試，規律很清楚： 設成「允許未指定的用戶端」→ 一切正常 設成「拒絕未指定的用戶端，只放行白名單」→ 所有人都 403 白名單裡明明有我自己的 IP，怎麼也被擋？翻 IIS Log 才看懂： 1c-ip: 192.168.0.28 每一筆請求的來源 IP 都是 192.168.0.28。這是那台 Proxy Relay 伺服器。外部請求全部先打到它，再由它轉發進 IIS。IIS 眼裡只有代理伺服器這一個來源，真正的客戶端 IP 它根本看不到——白名單再怎麼設都是擋自己人。 追查：真實 IP 藏在哪個標頭代理轉發時，習慣上會把原始客戶端 IP 塞進...
告別背包中自動喚醒的筆電：用 PowerShell 一鍵關閉藍牙裝置喚醒功能
昨天我又被這個問題坑了一次。筆電關蓋放進背包，騎車到咖啡廳，打開包準備開工——機器燙手、電量歸零、已經自動關機。整個下午的計畫泡湯。 這不是第一次。我的 Steam Deck 也中過同樣的招：放包裡沒事，拿出來卻發燙、掉電掉得莫名其妙。元凶我早就懷疑過，這次決定把它揪出來釘死：藍牙滑鼠在背包裡被擠壓、滾動，被系統當成「使用者想喚醒電腦」的訊號，於是它就在密閉的包包裡偷偷醒過來，自己跑了一整個下午。 罪魁禍首：藍牙裝置的喚醒權限Windows 預設讓不少連接的裝置具有「喚醒電腦」的權限，滑鼠和鍵盤尤其常見。這在桌機上有用——按一下滑鼠就把睡眠的機器叫起來。但對天天把筆電丟進背包移動的人來說，它是個災難。 藍牙滑鼠在包裡稍微移動或被按到，系統就判定該醒了。結果電腦在沒有散熱空間的背包裡開機運轉，電力白白燒掉，長時間悶著還可能因為過熱傷到硬體。 要解決它，得先搞清楚一件事：到底哪些裝置現在「有權限」叫醒你的電腦。 第一步：先看清楚誰能喚醒電腦別急著寫一大段腳本掃全部裝置。Windows 內建的 powercfg 有一個指令，直接列出當下被授權喚醒系統的裝置清單，而且這份清單通常很短： ...
IIS 401.3 權限錯誤完全解析：為什麼新增 IUSR 是救命關鍵
當你的網站顯示 401.3 錯誤IIS 網站部署後出現： HTTP 錯誤 401.3 - Unauthorized因為網頁伺服器上此資源的存取控制清單 (ACL) 設定或加密設定的緣故，您沒有檢視此目錄或網頁的權限。 HTTP 401.3 是什麼HTTP 401.3 是 IIS 特有的狀態碼，表示「由於 ACL 限制，請求被拒絕」。與一般的 401（認證失敗）不同，401.3 明確指出這是檔案系統權限問題，不是網站認證設定的問題。 IIS 想提供你請求的資源，但它持有的身分沒有足夠的 NTFS 權限來讀取那些檔案。 IUSR 是什麼IUSR（Internet User）是 IIS 的預設匿名存取帳戶。每當訪客在未登入的狀態下存取網站，IIS 就以 IUSR 的身分去讀取網站資源。如果網站資料夾的 NTFS ACL 沒有賦予 IUSR 讀取權限，就會觸發 401.3。 授予 IUSR 適當的權限1. 找到你的網站根目錄首先，找到你的網站檔案所在的實體路徑。通常是在： C:\inetpub\wwwroot\你的網站名稱 或是你自訂的其他位置 2. 設定資料夾權限 在檔案總管中...
