Windows 11 New Outlook 郵件黑盒事件：一個月後才看到真正的 Mail Flow 作者：Steven Lai ｜ 日期：2026-05-14 📌 前言 這個案例，我追了快一個月。 整個過程幾乎沒有證據。 沒有退信 沒有 Sent Items 沒有 Outbox 沒有 SMTP log Windows Event Viewer 也沒有有效線索 直到今天，才因為一封偶發退信，讓整條郵件路由真正浮出水面。 Windows 11 New Outlook 的實際寄信路徑， 和我們以為的 SMTP 模型，根本不是同一件事。 🧩 事件背景 Windows 11 內建新版 Outlook（New Outlook） ISP 信箱（Seednet） 收件端：Gmail / Hotmail 📨 客戶沒收到信 但奇怪的是： Outlook 沒顯示寄送失敗 沒有退信... » read more
RFC 9797 與企業 DHCP Pool 危機 為何公司同仁突然拿不到 IP？NAS 與印表機間歇性失聯？ 近年來，企業 IT 現場開始頻繁出現一種「難以定位」的網路異常： 許多管理者第一時間會懷疑： 然而，真正的原因，可能與現代行動裝置導入的 MAC Randomization（隨機 MAC 位址）機制有關。 而此一趨勢，也與 RFC 9797 所代表的裝置隱私方向密切相關。 MAC Randomization 正在改變企業網路環境 現代作業系統為了降低裝置被追蹤的風險，開始大量採用： 目前常見於： 其核心目的在於： 避免使用者透過固定 MAC 位址，被長期識別與追蹤。 從隱私保護角度而言，這是正向發展。 但對企業 DHCP 管理而言，卻帶來新的挑戰。 同一台設備，可能重複取得多組 IP 在企業 Wi-Fi 環境中，行動裝置會頻繁出現： 若裝置使用 Randomized MAC， DHCP Server 可能會視其為： 「新的設備」。 因此： 同一台手機、筆電或平板， 短時間內可能重複取得 2~3 個 IP。 /24 網段其實很快就會耗盡... » read more
這篇文章有三個主角：一個固執的排錯工程師、一個聽起來很有把握的 AI、以及一份他們都沒去讀的官方文件。 結局是：工程師手動挖對了一半，AI 說中了一半又說錯了一半，官方文件早就把答案寫好了——只是沒人第一步就去查。 一、故事的起點：Qwen 在哪裡？ 環境是 Windows 11，Ollama 本地跑著 qwen3.5:9b-q8_0，OpenCode v1.14.40 剛裝好。按理說一切應該順暢——但 OpenCode 每次啟動，都自作主張地選回了一個叫做 minimax-m2.7:cloud 的雲端模型。 ⚠️ 問題明確：你設定好的本地模型，隔一次重啟就消失了。minimax 幽靈般地回來，像是設定根本沒被寫進去。 排錯的直覺是：設定檔的問題。但 哪個 設定檔？ XDG 規範遷移的陷阱 OpenCode 在某個版本之後，悄悄從 Windows 慣例路徑遷移到了符合 XDG 規範的新路徑。舊版使用者習慣去改的地方，新版根本不理。 # 舊版慣例（不再生效） %APPDATA%\opencode\opencode.json # 新版 XDG 規範路徑（這才是有效的） %USERPROFILE%\.config\opencode\opencode.json 在這個路徑下，把 model 欄位手動修正為 ollama/qwen3.5:9b-q8_0，重啟，終於有效。Qwen 3.5 開始正常接管工作，而且 tool calling 能力也確認正常——它主動調用 read 工具讀取了本地的 CONSTITUTION.md，完全符合 agentic 工作流的期待。 ✔️ 第一階段結論：路徑找對了，模型確認上線，憲法執行能力驗證通過。... » read more
技術觀察 · AI Infrastructure 24GB 顯存，為什麼跑不動 16GB 的本地 AI 模型？ Mr. τ／風雲網通系統 · 本地 LLM 部署實測觀察 很多玩家的第一反應：「我有兩張 3060，加起來 24GB，跑個 16GB 的模型理論上完全沒問題啊？」 實測結果卻是：載入沒事，一開始對話就隨機崩潰。這不是顯卡壞了。是 VRAM 的本質被誤解了。 💡 核心觀念：VRAM 是預算，不是倉庫 很多人把 VRAM 想成靜態的硬碟空間。但跑 LLM 推論時，它更像是一個「會呼吸的緩衝區」。16GB 的模型進了顯存之後，只是第一筆支出，後面還有更多看不見的隱形成本持續消耗。 一個更直觀的比喻：VRAM 是電梯的「額定載重」，而 16GB 的模型只是乘客的體重。電梯運行時的機械摩擦、剎車瞬間的衝擊力（推論峰值）——這些才是讓系統超載的真正原因。 📦 消失的顯存去哪了？三層隱形成本 1 靜態模型權重（固定 16GB） 這是你看得見的部分——模型進了 VRAM 就不動了。誤區正是從這裡開始，很多人以為「剩下 8GB 就是安全空間」，但實際上那 8GB 要承擔後面所有的動態壓力。 2 KV Cache 的「呼吸效應」（4～8GB，且隨時間膨脹） 這是最關鍵的時間變數。LLM 是有記憶的，每一輪對話都要把前面的內容儲存進... » read more
工程實戰 · Mr. τ · 2026 年 5 月 30 分鐘換來的 12 倍加速 本地 LLM 效能異常的根因拆解與 Debug SOP ▌ 這篇文章在講什麼 我花了整個上午，讓 AI 助理幫我 debug 一個本地 LLM 效能異常。六輪下來沒解決，最後靠一個三字參數位置錯誤找到根因。這是那次事件的完整記錄——以及我從中整理出來的 Debug SOP。 現象：200 字的文件，為什麼要跑 30 分鐘？ 測試場景很單純：6 筆文件，每筆約 200–300 字，交給本地模型做結構化評分。正常情況下，這種規模的任務應該在幾分鐘內完成。 實際結果是：每筆 140–150 秒，6 筆合計接近 30 分鐘。 硬體監控數字正常，GPU 在線，模型已載入顯存。從表面看，系統沒有任何問題。 六輪 Debug，每輪都沒打到點 我請 AI 助理協助排查。接下來發生了一段很典型的「AI 時代 Debug 迴圈」： 1 加入串流顯示... » read more
資安實務 ｜ NAS 維運筆記 ｜ 2026 深夜收到「陌生 IP 登入警報」，你知道該怎麼處理嗎？ 從一封 NAS 警告信，學會判讀、鑑別、封鎖的完整 SOP 某天下班後，手機收到一封主旨為「嚴重｜來自陌生 IP 的登入嘗試」的警報信。來源地：東歐某國家。登入帳號：公司管理員信箱。——你的第一反應是什麼？ 一、這封警報信在說什麼？ Synology Active Insight 會在偵測到非常規地理位置登入時自動發信通知。信中包含三個關鍵資訊： ✔ 哪個帳號被嘗試登入 ✔ 連線類型（HTTP/HTTPS） ✔ 來源所在位置（國家/地區） 收到這封信不代表帳號已被入侵，但也不能置之不理。關鍵在於：你是否能識別這次登入是否為授權行為。 二、先做鑑別診斷：正常還是攻擊？ 在採取任何行動前，先冷靜確認以下三個問題： 1 這段時間有人出差或出國使用 VPN 連回公司設備嗎？ 2 有委外廠商或協作夥伴被授權遠端存取嗎？ 3 登入是否成功？（失敗嘗試 vs. 實際進入是完全不同的嚴重程度） 若三個問題都答「否」，就需要啟動應急處置流程。 三、哪些國家是高風險來源？ 根據實際日誌分析，以下地區出現高頻率的自動化掃描與暴力破解嘗試： 風險等級 國家代碼 常見攻擊手法 高風險 CN、RU、UZ、KZ 自動化腳本掃描、帳號暴力破解 中風險 DE、NL、UA、PL 租用 VPS 作為跳板進行中繼攻擊 中風險... » read more
作者：Mr. τ 分類：現場排障案例 標籤：Wi-Fi／藍牙／2.4GHz／無線網路 在 IT 現場，有一類問題特別難抓——症狀看起來像網路故障，換個時間又自動恢復，偏偏找不到明確的硬體損壞跡象。本文記錄一個真實案例：Wi-Fi 播放卡頓，根本原因卻藏在一支藍牙耳機裡。 一、問題現象 使用情境：室內距離無線基地台較遠的位置，以手機連線 Wi-Fi 觀看 YouTube，同時透過藍牙耳機收聽音訊。 觀察到的異常：影片播放頻繁緩衝、斷斷續續卡頓，網路連線表面上仍顯示正常。 二、快速排查驗證 1 切換至 4G 行動網路播放 → 影片立即恢復正常，確認問題在 Wi-Fi 端，非內容來源或設備本身故障。 2 保持 Wi-Fi 連線，關閉藍牙耳機 → Wi-Fi 傳輸立即順暢，確認藍牙裝置是干擾來源。 兩步驗證完成，方向明確：藍牙與 Wi-Fi 之間存在無線干擾。 三、根本原因分析 3.1 頻帶重疊是核心問題 Wi-Fi 的 2.4GHz 頻帶與藍牙使用相同的無線頻譜範圍（2.400–2.4835 GHz）。當兩者同時運作，且距離接近時，訊號會相互競爭通道，造成封包碰撞與重傳，導致實際吞吐量下降。 Wi-Fi 2.4GHz 傳輸距離較遠，穿牆能力強，但頻段擁擠，干擾源多（微波爐、藍牙、鄰居 AP 等） Wi-Fi 5GHz 頻道數多、速度快、干擾少，但傳輸距離相對較短，穿牆能力較弱 藍牙（Bluetooth） 工作在 2.4GHz，採跳頻展頻（FHSS）技術，雖有抗干擾設計，但在弱 Wi-Fi 環境下仍會形成競爭 實際情境... » read more
三十六計 之 第二十五計：偷梁換柱 一間公司的網路壞掉，通常不是壞，是「被改了」。 這次的案子從一通求助電話開始。客戶反映 NAS 狀態不穩定，異地備份任務也持續出現錯誤。遠端連進去診斷，我就知道這不只是設備問題。 ━━━━━━━━━━━━━━ 📡 異常一：設備看得到，但抓不到 第一個奇怪的地方出現了。 用原廠提供的管理工具，可以正常找到 NAS 的詳細資訊。但換成一般的網路掃描工具，或者直接查 ARP 表，卻完全看不到這台設備的 IP 存在。 這種「廠商工具看得到，標準協定看不到」的狀況，通常意味著網路層出了問題，而不是設備本身故障。這是第一個線索。 ━━━━━━━━━━━━━━ 🔀 異常二：Gateway 被換掉了 接著進行更詳細的網路掃描，發現一件讓我高度警覺的事。 這個客戶原本的網路架構設計是這樣的：主站與分站各自部署一台企業級 VPN 路由器，兩台設備透過 Internet 建立加密通道，讓分站的 NAS 可以定時將資料備份到主站的 NAS。這是一個相對標準、可靠的異地備份架構。 但掃描結果顯示，分站那一端的企業級 VPN 路由器，已經被換成了一台消費級 Wi-Fi 路由器。 現場詢問了相關人員，才得知是分站同仁自行找當地店家協助處理網路問題，店家在不清楚原有架構的情況下，直接把路由器換掉了。新的設備沒有 VPN 功能，也沒有留下任何管理帳號與密碼。 結果很直接：兩個站點之間的 VPN 通道完全消失，分站 NAS 的所有備份任務全數失敗。但內部的日常檔案存取，還勉強維持正常運作——這也正是最危險的地方。沒有人知道備份已經中斷多久了。 ━━━━━━━━━━━━━━ ⚡ 異常三：分站 NAS 還有另一個獨立問題 排查過程中發現，分站的 NAS 本身也有狀況。 設備會不定時從網路上消失，需要現場人員到機房手動重開才能恢復。這種「時好時壞」的症狀，加上現場環境沒有配置 UPS，研判與電力品質不穩有直接關係。突波與電壓不穩定，不會每次都讓設備壞掉，但會讓系統累積異常、縮短硬碟壽命，並在你最不注意的時候讓備份中途中斷。... » read more
十六分鐘 vs 九十分鐘 一張交換器燈號，背後是二十年的背景知識 作者：Steven Lai ｜ 風雲網通系統 ｜ IT 外包顧問 有一種停機，不是伺服器掛掉，不是網路線被切斷，而是某個角落的設備悄悄壞了一半——它還能運作，但已經不可靠了。這種狀況，最難抓、也最容易讓人繞遠路。 從一個閃爍的圖示開始 某個工作日上午，辦公室裡有幾台電腦的 Windows 右下角，網路圖示開始交替出現「已連線」和「無網路」。不是全斷，斷了又好，好了又斷。 這種間歇性的狀況，往往比完全斷線更麻煩。完全斷線，方向很明確。間歇性，可能是一百種問題裡的任何一種。 接到通知的工程師沒有急著動電腦，而是先做了一件很多人會跳過的事——往遠處看了一眼。 用對方向，少走九成的路 以下是整個排查的實際順序，以及每一步背後的判斷邏輯。 ① 遠觀數據機燈號，搭配 MOD 頻道交叉驗證 約 1 分鐘 MOD 頻道播放正常，代表數據機到 ISP 這段沒問題。WAN 端一口氣排除，節省了打電話報修、等待 ISP 人員的時間。 ② 重開防火牆 約 2 分鐘 這台防火牆的變壓器曾經換過，不是不值得懷疑。重開沒有解決問題，排除，繼續往下。 ⚡ ③ 觀察交換器燈號 約 10 秒 ← 決勝點 一眼看過去，燈號全滅，然後重新亮起，循環發生。這個行為模式，有經驗的工程師認得出來：不是設定問題，是硬體在間歇性故障。作業系統、網路線、網路卡這些假說，一刀切掉一半。 ④ 換上代用交換器 約 5 分鐘 過程中有個小插曲——第一台代用機剛好是 port-based VLAN 版本，換錯了，立刻再換一台一般無網管型。這類細節，不熟的人可能還要花時間查原因。 ⑤ 處理驅動程式殘留狀態 約 5 分鐘等待 換了交換器之後，電腦還是一度無法上網——封包有出無入，自設 IP 也無效。這不是新問題，而是舊連線的協商狀態沒清乾淨，等連線環境穩定後會自行恢復。認識這個現象，避免了「懷疑網路卡」甚至「懷疑主機板」的誤判。... » read more