更新紀錄

最後更新：2026-09-15

這裡只記錄您看得到或會遇到的改變：畫面、行為、升級方式。內部整理與工具調整不列在這裡。最新的版本在最上面。

自 2026-09-06 起，各個部分分開發行、各有自己的版號。節標題會標明是哪一個（例如「Hub」）；沒有標明的是您主機上的 SvrGuard 主程式。

1.0.42 · Hub 1.0.25 · Admin 1.0.26 — 2026-09-15

新增「日誌來源」頁（Pro） —— 一直以來，主控台沒有任何地方回答得了「這台主機的偵測，現在到底讀得到哪些日誌」。現在這一頁列出：目前正在讀的每一個檔（路徑、最後解析時間）、找得到卻沒有在讀的數量、最後一次真的讀到新內容是什麼時候，以及目前生效的採集設定。
⚠️ 「完整性」那一欄要看清楚：它寫「無法確認是否有遺漏」時，意思是我們沒有能力去看（例如在 Synology 上主程式不是特權身分），⛔ 不是「已經確認沒有遺漏」。⚠️ 網站沒有流量時，「最後讀到新內容」本來就不會前進，那不是故障。
掃描目錄現在會多看一層子目錄，而且是靠內容認出紀錄檔 —— 每個網站各自一個子目錄（nginx/site-a/、apache2/site-b/ 這類配置）先前整批被漏掉，因為掃描只看指定目錄本身。現在會多下去一層，並且讀內容來判斷那是不是網站存取紀錄——檔名叫什麼都可以。
⚠️ 為了不讓這件事變成每一輪的負擔：壓縮檔不會被開啟、目錄捷徑不跟隨（避免繞回自己）、只下去一層，而且每一輪最多辨識固定數量的新檔，其餘留到下一輪（紀錄裡會寫還有幾個沒看）。
介面語言不再中英夾雜 —— 兩處：代理提醒後面那句建議您怎麼改網頁伺服器設定的話，在英文介面仍然是中文；以及自動更新沒有執行時的原因說明，在中文介面會出現英文。兩處都已改正。
更新進行中的遮罩，結束時轉圈會停下來 —— 更新完成、失敗或等太久時，畫面上那個轉圈仍然在轉，看起來像還在進行中。現在三種結局都會停下來並換成對應的顏色。
Hub／Admin：威脅位址庫的待審回報，時間改用您主機的本地時間顯示 —— 先前那一欄顯示的是世界標準時間而且沒有標明，於是一筆剛送出的回報看起來像是八小時前的。

1.0.41 — 2026-09-15

當網站前面有代理時，主控台會告訴您「這台的紀錄裡看不到真正的訪客」 —— 如果您的網站前面有反向代理、負載平衡器，或網站跑在容器裡，網站紀錄檔每一筆的來源位址都會是那個代理自己，不是訪客。⛔ 後果不是誤封，是偵測根本不可能成立：所有證據都被歸到一個永遠不會被封鎖的內部位址上，而畫面上一切看起來正常。現在主控台會直接講出來，並附上依據（多少筆裡有多少筆、最常見的是哪一個位址），指引您調整網頁伺服器的紀錄格式，讓它記下真正的來源。
我們刻意不去讀 X-Forwarded-For 這類標頭 —— 那個標頭是連線的另一端自己填的，攻擊者可以在裡面寫任何位址。若我們照單全收，等於讓攻擊者指定「請封鎖這個位址」，而被封的會是無辜的第三方。⭐ 少擋一些，遠好過替攻擊者擋掉他想擋的人。⚠️ 另外，這項偵測只認得出內部網段的代理；位於公開網際網路上的代理我們不會去猜，因為那與「一個攻擊者送出大量請求」在紀錄上分不開。⛔ 所以沒有看到這個提醒，不代表來源位址一定是可用的。
Synology DSM：更新頁不再自相矛盾 —— 先前同一頁可能同時出現「已是最新版本」與「有新版可更新」，而按下去什麼都不會發生。原因是那兩處問的是兩個不同的更新來源，其中一個只比對版號。現在版號相同就不算有更新，按鈕也不會出現。
⚠️ 連帶要知道的一件事：在 Synology 主機上，版號沒有變的重新打包無法透過更新取得，必須換一個版號才送得到您手上。

1.0.40 — 2026-09-15

Synology DSM 7：blockcheck 問輔助程式這件事，現在才真的生效 —— 1.0.37 的更新紀錄說它會改問實際執行封鎖的那一方，而在您的主機上它並沒有：blockcheck 是獨立執行的一支指令，從不自己去執行封鎖，所以它手上永遠沒有那條路可走，結果仍然是那句「讀不到防火牆」，外加一句沒有用的「請改用管理者身分執行」。
現在它會列出規則在不在、位址集合在不在、裡面裝了幾個位址，以及依設定應該有幾個。⚠️ 這類主機上仍然只能比對數量，不能逐一比對位址，畫面會講出這一點；數量不同也不一定是故障——同步有自己的排程。抱歉，那段描述有三個版本的時間與實際情況不符。
主程式會告訴您，這台主機有哪些網站紀錄檔沒有被讀到 —— 先前只能讀設定裡指定的那個目錄，而網頁伺服器實際寫到哪裡，它從來沒有問過：紀錄檔放在更深的子目錄、放在 /var/log 以外、或每個網站各自一個檔名，都會被漏掉，而畫面上一切正常。現在每一輪採集會問一次正在執行的網頁伺服器實際開著哪些檔，只採計這台主機自己檔案系統上的檔，並且逐一讀過內容確認那真的是網站存取紀錄（只看檔名會把被網站送出的圖檔也算進去）。有漏掉的就在紀錄裡列出檔名。
⚠️ 這需要管理者權限才問得到。在 Synology 套件這類以非特權身分執行的主機上，目前問不到，這時它會明白記為「無法判斷」——⛔ 那不等於「沒有漏掉」。採集與封鎖不受影響，這一項只負責告訴您有沒有漏。

1.0.39 · Hub 1.0.24 — 2026-09-14

Hub：核准沒有成功時，裝置碼不再被作廢 —— 先前裝置碼是在核准真正完成之前就被記成已使用，所以只要核准這一步失敗，您就會拿到一組作廢的代碼與一句「請重新產生」，而那台主機可能其實已經綁上了。現在代碼要等綁定成功才算用掉；核准被拒絕仍然會用掉它（您得先處理被拒的原因），其餘情況一律把代碼放回去，下一次輪詢照樣可用。
Hub：核准成功但畫面等不到時，那台主機可以自己把金鑰取回來 —— 金鑰是在核准的回應裡產生的，不會存下來；那個回應遺失時（主機端等待十秒就放棄，而核准還在進行中），主機已經綁定卻沒有金鑰，而它自己做什麼都拿不到。現在代碼會記住它綁的是哪一台主機，只有那一台能在代碼原本的十分鐘有效期內回來取金鑰。
⚠️ 這改變了一個界線：先前是「一次核准換一把金鑰」，現在是「一次核准、同一台主機換一把金鑰」。換一台主機拿同一組代碼，得到的仍然是「代碼已失效」。
升級失敗後的橫幅不再說「已還原舊版程式」 —— 上一版已經改掉日誌裡那個說法，而橫幅沒有跟著改，於是那句不正確的描述留在您真正會讀到的那個地方。落後一版以上的主機退到的是它從來沒有跑過的版本，橫幅現在只說目前執行的是哪一版，不再稱它為還原。退到哪一版沒有改變。

1.0.38 · Hub 1.0.23 — 2026-09-14

安裝指令不再蓋掉既有的安裝 —— 在已經裝好 SvrGuard 的主機上重跑安裝指令，先前會先換掉程式檔，再因為服務已經註冊過而中斷，留下一台「程式檔是新的、跑著的服務是舊的」主機，而畫面上什麼都沒說。現在它會在動任何東西之前就停下來，並告訴您升級該用的指令：curl -fsSL https://svrguard.ofuyuan.com/upgrade.sh | sudo sh。安裝就是安裝，升級由升級指令負責——它會先停掉服務，而且新版起不來時會把舊的放回去。
升級失敗時，「回到上一版」不再被用來描述不是那件事的情況 —— 升級失敗時主機會退回我們發行的前一個版本，而那只有在您的主機正好落後一版時，才等於「您的上一版」。落後更多的主機會退到一個它從來沒有跑過的版本，而先前每一句訊息都把它稱為回滾。⚠️ 退到哪一版沒有改變，改的是怎麼描述它：我們只為兩個版本公布校驗值與簽章，所以無法驗證任意的舊版本。
系統更新頁對共享威脅情報的說明改對了 —— 那一行仍寫著「每次開啟本頁時檢查一次」，而自 1.0.37 起它每天會自動檢查一次，開啟本頁時仍會再問一次。功能沒有改變，改的是畫面上那句話。
Hub：核准一台主機之後，清單會顯示「等待連線」 —— 核准裝置碼與那台主機真的連上來是相隔幾秒的兩件事，而中間那幾秒清單上什麼都沒有，看起來像核准沒有生效。現在那段期間會出現一列「等待連線」；那台主機遲遲沒有連上時，畫面也會告訴您該做什麼（到該主機重新執行 svrguard pair -device）。

1.0.37 — 2026-09-14

沒有設定通知管道的主機，現在一樣會自動更新 —— 先前只要沒有設定任何通知管道（Email 等），自動更新就會停用，理由是「更新失敗時沒有人會知道」。代價卻是這些主機再也收不到任何修正，包括修正封鎖本身的那些。自動更新與通知從本版起是分開的兩件事：更新照常進行，而通知只在您設定了管道時才寄。更新沒有成功時，原因仍然會顯示在系統更新頁上。
共享威脅情報現在會自動更新 —— 它先前只有在您手動按下按鈕時才會更新，也就是說沒有人按的話，它從安裝那天起就不再變動。現在每日一輪會依序更新威脅位址庫 → 共享威脅情報 → 主程式；前兩項便宜且可逆，所以排在前面，而且任何一項失敗都不會影響後面的更新。
Synology DSM 7：blockcheck 不再誤報「讀不到防火牆」 —— 在 DSM 7 上，封鎖是由具權限的輔助程式直接寫進核心的，而 blockcheck 讀取時用的是那台機器上並不存在的指令，於是它回報讀不到，還建議您改用管理者身分執行——而那沒有用，因為那個指令根本不在。現在它會改問實際執行封鎖的那一方，並列出規則在不在、位址集合在不在、裡面裝了幾個位址，以及依設定應該有幾個。
⚠️ 在這類主機上只能比對數量，不能逐一比對位址，畫面會明白講出這一點；數量不同也不一定是故障——同步有自己的排程，兩輪之間本來就可能差幾筆。

1.0.36 — 2026-09-13

Synology DSM 7：以管理者身分手動升級過一次之後，之後的升級不再會被擋住 —— 升級程序有三個暫存檔，前兩個在 `1.0.35` 已經改成跟著執行身分走，第三個沒有。以管理者身分手動跑過一次升級之後，那個檔會屬於管理者，之後服務再要升級時寫不進去，於是每一次升級都會在真正開始之前就被拒絕。三個檔現在都跟著身分走。
⚠️ 這次的拒絕本身是正確的：它防的是「升級程序把執行自己的程序一起關掉」，服務也沒有因此停止；問題在於它說不出被拒絕的原因。現在它會講出是哪個檔案、為什麼寫不進去。
⛔ 已經卡住的主機需要手動處理一次：執行安裝的腳本是升級前那個版本產生的，所以這個修正不會自己套用到「升級進入本版」的那一次。請以管理者身分刪除 /tmp/svrguard-detach.out 後再升級一次。

1.0.35 — 2026-09-13

更新沒有成功時，主控台現在會說出原因 —— 按下「更新程式」之後，實際執行更新的是另一個獨立程序，而它做出「這次不更新」的判斷時，畫面的回應早就送出去了。先前的結果是更新中的遮罩自己降下來，畫面回到正常，而沒有任何地方說過剛才試過更新。現在那個原因會留下來，並顯示在系統更新頁上——不論原因是沒有訂閱、沒有設定更新來源、升級前檢查沒過，或是升級程序沒有啟動起來。
⚠️ 這不涵蓋一種情況：那個程序若被系統整個結束掉（例如記憶體不足），它來不及留下任何話，遮罩仍會等到逾時才消失。
Synology DSM 7：手動執行過一次升級指令之後，自動更新不再會被無聲地卡死 —— 升級程序的暫存檔用的是固定檔名，而以管理者身分手動跑過一次之後，那些檔案會屬於管理者；之後服務再要升級時既刪不掉也寫不進去，於是在寫下第一行紀錄之前就結束了，畫面上看起來就是按了按鈕什麼都沒發生。現在檔名會跟著執行身分走，並且會確認升級程序真的開始寫紀錄了才回報交棒完成。
更新按鈕不再承諾它做不到的事 —— 若磁碟上的程式檔已被換成另一個版本而服務尚未重新啟動，按下更新只會被下一個程序拒絕，而且是無聲的。現在主控台會在升起遮罩之前先比對，不一致就直接說出兩邊的版本並請您先重新啟動服務。
Synology 套件不受此限制——在那裡「磁碟上與執行中不同」本來就是升級失敗回復之後的正常狀態。

1.0.34 — 2026-09-13

Synology DSM 7 的自動更新現在完成得了 —— 在 DSM 7 上安裝新版套件時，系統會把套件相關的整組程序一併停止，而執行升級的程序本身也在那一組裡，於是安裝停在半路：新版沒有裝上，健康檢查也沒有跑。現在升級程序會先離開那一組，再進行安裝。
DSM 6 不受這件事影響，行為沒有改變。
⚠️ 若您的 Synology 上 SvrGuard 目前顯示為已停止，從套件中心按啟動即可恢復；本版修正的正是造成它的原因。
升級有了總時間上限 —— 升級若異常地久，會自行結束並在升級紀錄裡說明原因，不會無限期佔住套件。

（1.0.32 與 1.0.33 是內部測試建置，未對外發行。）

1.0.31 — 2026-09-13

網站日誌讀不到的兩種主機，現在讀得到了 —— SvrGuard 預設找的是 Debian／Ubuntu 的慣例（/var/log/apache2、檔名 access.log）。RHEL、CentOS、Fedora 與 Synology DSM 用的是另一套：目錄是 /var/log/httpd，檔名是 access_log —— 一個底線，而且 log 前面沒有點。安裝精靈原本找得到正確的目錄，卻仍用 Debian 的檔名去比對，於是一個檔案都對不上。現在檔名會跟著目錄一起判斷。
Synology 上另有一種情況：2026-07-28 之前安裝、之後只做升級的主機，設定檔裡沒有這幾項，升級也不會補 —— 現在安裝套件時會補上缺的那幾行（您自己設定過的值一律不動，包括刻意留白的）。
⚠️ 這會讓封鎖筆數增加，那是預期的 —— 上述主機的網站攻擊偵測先前完全沒有輸入（SSH 偵測與防火牆封鎖一直正常）。修好之後它們開始讀得到網站存取紀錄，所以會第一次看到針對網站的攻擊事件與封鎖。那不是新的攻擊，是原本就在發生、而我們看不到的那些。

1.0.30 — 2026-09-13

Synology DSM 7：自動更新這次真的會執行了 —— 上一版讓套件裡那支有系統管理權限的小程式代為安裝，但只接了一半：主控台那一列已經知道這台主機又能更新了，而判斷「要不要自動更新」的那一段還在沿用舊答案，於是橫幅仍然寫著「這台主機無法自行安裝套件」，自動更新也仍然停著。兩處現在問的是同一個問題。若您的主機曾經升級失敗過一次，那筆紀錄也不再永久擋住自動更新 —— 它記的是舊做法的失敗。
⚠️ 自動更新仍然需要您設定至少一個通知管道（設定頁），這一條沒有改變：更新失敗時若沒有任何人會被通知，本程式一律拒絕在無人看管下更新。
主機無法自行安裝套件時，畫面不再只是把按鈕收走 —— 上一版起，遇到「這台主機無法自行安裝套件」的情況會停用「更新程式」按鈕並說明原因。但那一列同時顯示著「有新版可更新」，動作欄卻空著 —— 等於告訴您有更新，又沒給任何抵達它的方式。現在那一格會出現「取得安裝包」，直接帶您到下載頁，取得之後以手動安裝更新。可以自行更新的主機完全不受影響，看到的仍是原本的「更新程式」按鈕；已經是最新版時也不會出現這個連結。

1.0.29 — 2026-09-13

Synology DSM 7：自動更新恢復了 —— 上一版只做到「不讓您按一顆注定失敗的按鈕」，那是止血，不是修好：DSM 7 的主機仍然只能由您到套件中心手動安裝每一次更新。這一版讓套件裡原本就有的、由 DSM 正式授權以系統管理權限執行的小程式（它一直負責寫防火牆規則）代為執行套件安裝，於是 DSM 7 的主機可以像其他平台一樣自己完成更新。
⚠️ 需要您手動安裝這一版一次。 代為執行的那個小程式是套件的一部分，而它無法由自動更新替換，所以這一版必須經由套件中心裝上去；裝好之後，往後的更新就會自動完成。DSM 6 與一般 Linux 主機不受影響。
安裝的每一步都會先驗證，確認是我們簽出來的那一份 —— 由於安裝改由具有系統管理權限的程式執行，它不採信提出要求的一方：會自行重算套件的雜湊、自行驗證數位簽章，並把驗過的那一份複製到只有系統管理者能寫入的位置之後才交給套件中心。驗不過就不安裝，並在畫面上說明原因。
升級失敗需要退回上一版時，版本紀錄不會再對不上 —— 退回上一版需要短暫調低套件記載的版號。先前那個動作與還原分屬不同步驟，中途若被中斷，主機上會留下一個與實際執行程式無關的版號，而後果是這台主機從此認為自己已是最新、安靜地不再更新。現在調低與還原在同一個步驟內完成。

1.0.28 — 2026-09-12

SSH 密碼嘗試：補上兩個時間窗之間的一條縫 —— SvrGuard 用兩個時間窗看 SSH 登入失敗：一天內 20 次，以及5 分鐘內 10 次的短窗。短窗先前是用固定的 5 分鐘格子去數的，只要攻擊把嘗試攤開超過半個窗，每一格都只數到一部分 —— 例如 11 次分散在 6 分鐘，短窗最多數到 8 而放行，而總次數又不到一天 20 次的門檻，於是兩個窗中間留下一條縫。現在短窗改成真正的滑動計算：任何連續 5 分鐘內滿 10 次就算。門檻與您的設定都沒有改變；但這一類「放慢速度避開偵測」的來源從這一版起會被擋下來，所以您可能會看到封鎖筆數比以往增加 —— 那是預期中的。
Synology DSM 7：不再讓您按一顆注定失敗的「更新程式」 —— 在 DSM 7 上，套件以非特權身分執行，而安裝套件需要系統管理權限。先前按下「更新程式」會花三分鐘反覆嘗試重啟服務、安裝失敗、還原也失敗，最後留下一則「這台主機需要人處理」的警告 —— 而您的主機其實從頭到尾都好好的，偵測與封鎖也一直正常。現在主程式會先問系統一個它已經知道答案的問題（「我自己在執行嗎？」），得到矛盾的答案就直接停用那顆按鈕與自動更新，並說明請從 Package Center 手動安裝。DSM 6 與一般 Linux 主機不受影響，那裡的自動更新照常運作。

1.0.27 — 2026-09-12

內容與 1.0.26 相同，只有版號不同 —— 1.0.26 與 1.0.25 沒有上架（它們是在實機上逐一驗證用的），所以您在下載頁與自動更新看到的版號會從 1.0.24 直接跳到 1.0.27。下面 1.0.24 之後的每一項變更都包含在這一版裡。

1.0.26 — 2026-09-12

Synology DSM 7：SSH 登入紀錄終於讀得到了 —— 在 DSM 7 上，主程式以非特權身分執行，而系統的 SSH 認證紀錄屬於 root，結果是 SSH 攻擊偵測長期沒有任何輸入（網站存取紀錄的偵測與封鎖一直正常）。這一版在套件裡宣告加入系統的 log 群組，那正是該紀錄檔開放讀取的群組。安裝後主控台上「日誌檔讀不開」的警告應該會大幅減少。
不再為「本來就不該讀的檔案」發警告 —— 上一版開始會告訴您哪些日誌檔看得到卻讀不開。那是對的，但它連 logrotate.status 這類根本不是日誌、以及本程式永遠不會解析的系統檔案也一起報，於是變成一條永遠亮著的紅字。現在只有本程式真的會解析的種類（網站存取與錯誤紀錄、認證紀錄）讀不到時才會提醒。
「威脅位址庫」那一列不再把「沒訂閱」說成「讀不到更新來源」 —— 沒有訂閱時，本程式根本不會去問供應端有沒有新版，而畫面卻顯示紅色的「讀不到更新來源」，看起來像伺服器故障。現在會分別說明：需訂閱、尚未設定更新來源、或真的問了而對方沒有回應（並附上原因）。
Synology：手動安裝一次之後，「自動更新已暫停」的提示會消失 —— 那段提示是依據上一次自動升級的紀錄產生的，而在 DSM 7 上手動安裝並不會更新那份紀錄，於是提示會一直留著。現在安裝套件時會把舊紀錄收起來。
防火牆訊息更正 —— 主程式改用 ipset 時，紀錄原本寫「核心不支援 nf_tables」，但實際原因往往是權限不足、無法詢問核心（DSM 7 即如此）。現在寫的是「無法使用 nf_tables」並附上真正的原因。

1.0.25 — 2026-09-12

Synology DSM 7：1.0.24 的套件裝不起來，這一版修好了 —— 1.0.24 的 DSM 7 套件在安裝時會被 DSM 擋下（錯誤 319，套件中心顯示「因 SvrGuard 以根權限執行，而導致無法安裝」）。原因是我們在套件裡宣告了一項檔案權限，想讓主程式讀得到系統的 SSH 認證紀錄 —— 而 DSM 不接受未經 Synology 認證的套件提出這種宣告。宣告已經拿掉，DSM 7 的安裝與升級恢復正常。DSM 6 與一般 Linux 主機（deb／rpm／tar.gz）完全不受影響，1.0.24 在那些平台上安裝正常。
連帶：DSM 7 上仍然讀不到 SSH 認證紀錄 —— 那正是上面那項宣告原本要解決的問題，目前沒有其他辦法可以取得該權限。主程式現在會在主控台明白告訴您它讀不到哪些紀錄檔，不再安靜略過。攻擊偵測的其他來源（網站存取與錯誤紀錄）與封鎖功能都不受影響。

1.0.24 · Hub 1.0.21 — 2026-09-12

通知信不再使用表情符號 —— 主旨與內文開頭的圖示已全部移除。部分收件伺服器把它們當成垃圾信的特徵，而一封被判成垃圾信的攻擊通知，等於沒有通知。信件內文的編碼方式也一併改成可直接閱讀的形式，讓同樣的內容不再看起來像被刻意混淆過。通知開頭那一行現在是 Host: 你的主機名稱。
通知信可以附上退訂方式 —— 設定檔的 [email] 新增 unsubscribe，填入的網址或信箱會放進信件的 List-Unsubscribe 標頭，有助於投遞。預設留空，留空就不會產生這個標頭——指向一個沒有人處理的位址，比沒有更糟。另外刻意不支援「一鍵退訂」：這些是資安告警，誤按一次就關掉整台主機的攻擊通知，代價太高。
資料庫不在的時候，主程式不再拒絕啟動 —— Synology 上這會讓升級後的主機整個停住 —— 上一版把「資料庫檔案不存在」當成「資料庫損毀」。⚠️ Synology 升級時就會走到這個狀態：安裝程序發現還原回來的資料庫壞了，會先把它搬到一旁（這是對的，證據要留著），並告訴您「服務會在啟動時盡量重建」—— 而上一版的服務在那一刻只會拒絕啟動，即使旁邊那份備份是好的。一般 Linux 主機則是在自行指定資料庫位置、或資料庫被刪掉之後重新啟動時遇到。現在：有備份就還原，您的主機身分跟著回來；沒有備份就當成第一次啟動，建立一個新的。
Synology 升級失敗後的最後一道救援，現在真的有東西可以用 —— 升級失敗而且 DSM 自己的還原也失敗時，主程式本來會直接把上一版的執行檔放回去。⚠️ 而那條路自 1.0.13 起一次都沒有成功過：它比對版本時讀錯了一欄，把版本字串後面的建置編號當成了版本，於是每次都判定「這顆執行檔不是我要的」。實際發生時，主機會停在沒有任何服務在跑的狀態。現在比對是對的，那顆執行檔會被放回去。
Synology DSM 7：套件升級現在真的做得到 —— 而先前一次都沒有成功過 —— 我們的套件少了兩支 DSM 7 在升級時必須看到的控制腳本，於是 DSM 一律拒絕升級（錯誤 261）。⚠️ 不分管道：從套件中心按更新、從主控台按「更新程式」、或讓它自動更新，結果都一樣，而畫面只會說版本沒有改變。實際上，DSM 7 的主機從第一個 Synology 版本起就只能裝、不能升，唯一的辦法是先移除再重新安裝。現在那兩支腳本在包裡了。DSM 6 不受影響，它一直都升得上去。
Synology DSM 7：SSH 登入失敗現在偵測得到 —— 先前這些主機讀不到那份日誌 —— DSM 7 上主程式以非特權身分執行，而系統的認證日誌只有 root 讀得到。⚠️ 於是那些主機的 SSH 攻擊偵測完全沒有輸入：程式每 5 分鐘照常跑、主控台一切正常，而它看到的永遠是空的。現在改由套件在安裝時向 DSM 宣告需要讀取權限，那是 DSM 支援的做法；先前是在安裝程序裡自己去要，而那在 DSM 7 上做不到。DSM 6 以 root 執行，一直都讀得到。網站與防火牆相關的偵測不受這一條影響。
用舊版救回來之後，主控台會說出來 —— 上面那條救援有一個代價：它換回舊的執行檔，但套件資訊不一定改得動（DSM 7 上改不動）。那會讓主機以為自己已經是最新版而不再更新，而且什麼都不會說。現在這種狀態會常駐顯示在主控台上，並告訴您該做的事是到套件中心重新安裝一次。沒有發生過的主機不會看到任何東西。

1.0.23 · Hub 1.0.20 — 2026-09-10

Synology 套件升級不會再弄壞主機上的資料庫 — 升級時的備份是把檔案複製進去而不是換掉，而正常關機會把資料庫的暫存檔清掉 — 於是上一次升級留下的暫存檔會被還原到新的資料庫旁邊，兩者配成一對之後資料庫就損壞了，而升級的每一步都回報成功。備份現在改成由資料庫自己導出單一一個檔，先建到旁邊、全部成功才換過去。
資料庫真的損壞時，主機現在會自己救回來 — 先前遇到損壞只會每次啟動都失敗，而訊息只在系統日誌裡。現在會從備份還原並重新啟動，並在主控台上說出發生過什麼。若連主機身分都救不回來，它會拒絕啟動而不是拿一個空的資料庫繼續跑 — 那樣會默默占掉您另一份訂閱。
那些用位址集合封鎖的主機，不會再說一個 IPv6 位址已經被擋住 — 這一層先前會去建集合、掛規則、失敗了只留一行日誌，而封鎖清單上仍然顯示它被擋住。現在這種主機會把 IPv6 目標列進「為什麼沒有生效」裡並說明原因。使用 nftables 的主機不受影響，IPv6 照常封鎖。舊的 IPv6 集合也會被撤掉，不再留在核心裡丟封包。
Hub：同名主機的提醒現在真的會出現 — 上一版說加入機隊時名稱重複會提醒，而那句提醒實際上從來沒有出現過：查詢寫錯了欄位名稱，而查詢失敗被當成「沒有重複」。現在會出現。
在 DSM 上查詢某個位址有沒有被擋，結果現在是對的 — 查詢去問的位址集合名稱是寫死的，而這類主機實際使用的是另一個名稱 — 於是它去問了一個不存在的集合，然後回報「這個位址沒有生效」。
「這一版裝上的時間」不再顯示成上一次自我更新的時間 — 兩個時間先前共用同一個欄位，於是它們永遠一致，也永遠看不出來不一致。
剛加入機隊的主機被 Hub 拒絕時，現在會自己恢復 — 主機換過金鑰之後，Hub 可能還拿著舊的那一把，於是每一個請求都被拒絕。先前要等下一次同步才會好，現在被拒絕的當下就會請它重新認一次。

1.0.22 · Hub 1.0.19 — 2026-09-10

Synology DSM 7：封鎖現在真的寫得進防火牆了 — 並更正上一版的說法 — 1.0.20 說「安裝時會取得寫入防火牆所需的權限」，而在 DSM 7 上那條路根本走不通：套件的安裝程序本身就沒有權限去要那件事，於是那些機器仍然是偵測得到、一條規則都寫不進去。現在改由套件裡一支只做防火牆這一件事的小程式代為寫入，主程式每 5 分鐘交給它同步一次。兩台實體 NAS（兩種處理器、兩種核心）實測：核心裡的位址數與封鎖清單完全相符。
在 DSM 上查詢某個位址有沒有被擋，不再把「讀不到」說成「沒有被擋」 — 讀取封鎖清單需要權限，而讀不到的時候它回報的是「這個位址並未生效」並附上一句其實不會改變任何東西的修復指令。實測當下那個位址正在被丟棄。現在讀不到就說讀不到，並指出該問誰。
不會再持有一大批沒有任何規則去查的封鎖位址 — 先前只問核心「能不能建立位址集合」，沒問防火牆「能不能引用它」；兩者可以一個成立、一個不成立，而所有訊息都會說成功。現在會實際插一次規則再收掉，引用不了就換一種方式封鎖。
沒有設定通知管道時，不再在每一頁上掛一條紅色橫幅 — 那句話改成在更新頁上就地說出原因。設定好 Email 之後立刻生效，不必等隔天的檢查或重新啟動。
儀表板「防火牆後端」那一行，正常時不再拖著一段括號 — 括號裡的原因只有在擋不了任何東西的時候才需要，那時它仍然會完整說出來。
主控台的版本列現在帶著建置編號 — 版號相同而內容不同的時候，那串編號是唯一解釋「為什麼還有新版可以更新」的東西；沒有它，那一列讀起來像自相矛盾。
更新進行中的畫面不再變成沒有樣式的一片白 — 那張畫面的樣式先前由正在重新啟動的那個程式提供，而它存在的目的正是蓋住重新啟動。樣式現在直接寫在頁面裡。
Hub：加入機隊時，若名稱與您自己既有的主機重複，確認頁會提醒 — 先前這個提示永遠不會出現。它只是提醒不是阻擋（兩台主機同名是合法的），而且只在您已登入時、只拿您自己的主機比對 — 否則任何拿到連結的人都能用它試探某個名稱在不在。

1.0.20 — 2026-09-09

Synology NAS 先前沒辦法自己更新，而按鈕看起來是好的 — 套件安裝時從來沒有寫入更新來源，於是「更新程式」按下去只會回一句「尚未設定更新來源」，每日的自動檢查也同樣停在那裡。現在新安裝會帶上更新來源；既有的 NAS 會在下一次安裝套件時自動補上。您若曾經自己把它清空，那是您的設定，不會被覆蓋。
在一般 Linux 主機上，同樣的情況先前會回報成功 — 更新來源沒有設定時，畫面會顯示「已觸發更新」並蓋上更新中的畫面，而實際上執行檔完全沒有換過，失敗的訊息只留在系統日誌裡。安裝包現在一律帶上更新來源。
沒有更新來源時，不再畫出一個按下去必定失敗的按鈕 — 那一列改成直接說出「尚未設定更新來源，這一列無法更新」。更新來源只是一時連不上的時候，按鈕會留著 — 那是暫時的狀況，您需要一個可以再試一次的地方。
Synology DSM 7 上，封鎖現在真的寫得進防火牆 — DSM 7 以受限的帳號執行套件，而套件安裝時沒有向系統取得寫入防火牆所需的權限，於是那些機器攻擊照樣偵測得到、規則卻一條都寫不進去。現在安裝時會取得它；取得不到的話會在安裝訊息裡直接說出來，而不是安靜地只剩偵測。
DSM 7 的安裝包，下載頁現在也給得到 — DSM 6 與 DSM 7 需要不同的套件，而先前下載頁上只有 DSM 6 的三個，DSM 7 的機器沒有手動安裝的路。現在兩個世代 × 三種架構都在上面。安裝前請在「控制台 → 資訊中心」同時確認 DSM 版本與 CPU — 兩者都要對，裝錯那一個 DSM 會直接拒絕。
換過封鎖方式的主機，解除封鎖現在會真的解除 — 主機從一種位址集合型別換到另一種之後，舊的 IPv6 集合會留在核心裡繼續丟封包，而清單上已經看不到它 — 於是「已解除封鎖」與「仍然被擋」可以同時成立。新的集合接手之後，舊的現在會被撤掉。

1.0.19 — 2026-09-09

封鎖現在會用核心的位址集合，而先前每一台主機都退到逐條規則 — 我們有三層封鎖方式，中間那一層（ip_set）在偵測它可不可用的時候，送出的詢問少了一個必要欄位，於是每一台主機都得到同一個錯誤，這一層從來沒有被真正選用過。修正之後，核心具備這項功能的主機會改用一條規則加一個位址集合，而不是每一個被封鎖的位址各一條規則。封鎖的結果不變，比對的成本變小。
Synology NAS 這類只支援單一位址的核心，現在也用得到位址集合 — 這些核心只編入了「單一位址」的集合型別，而我們先前一律要求「網段」型別，於是在這些機器上一定失敗。現在會依核心實際支援的型別選用。
在那種核心上，整個網段的封鎖不會生效 — 而現在畫面會直接說出來 — 單一位址的集合放不下一個網段。先前這種項目會被安靜地略過，主控台仍然顯示它已被封鎖；現在它會列在「為什麼沒有生效」裡，並且說明原因。一般的封鎖不受影響：偵測與威脅位址庫產生的都是單一位址，只有手動封鎖一整個網段時才會遇到。
防火牆後端那一行說明不再自相矛盾 — 先前那句話寫死成「核心不支援 nf_tables，已退回 ipset」，但實際退到的可能是別的層，括號裡的真實原因於是與前半句互相矛盾。現在只顯示實際的原因。

1.0.18 · Hub 1.0.18 — 2026-09-08

綁定完成之後，主機不會再被自己的 Hub 拒絕一次（Hub） — 主機的身分是寫在管理端的，而 Hub 是照自己手上的一份副本認人，那份副本先前要等下一次同步才會知道有這台新主機。實測相隔 18 秒，而主機的下一個請求就在那 18 秒裡面 — 於是綁定其實成功了，畫面卻說失敗。現在 Hub 會在回覆主機之前先把副本更新好。
綁定成功而登入沒完成時，不再說「無法完成綁定」 — 這兩件事先前共用同一句話，而它會讓人以為要重綁一次。現在會說「已加入機隊，但這次登入沒有完成」，並直接說明不需要重新綁定，只要再登入一次。主機主控台的登入頁也會留著這段說明，關掉對話框之後還看得到。
登入頁會說出你正在為哪一台主機登入 — 從主機按下「綁定個人帳號」之後，登入頁先前與平常的登入畫面完全一樣。現在上面會列出主機自報的名稱、主機自報的 hostname、Hub 看到的來源位址，並註明每一項的來源 — 前兩項是主機自己說的，不是我們的認定。

1.0.17 · Hub 1.0.17 — 2026-09-08

Synology NAS 上名稱相同的兩台主機，現在可以同時存在（Hub） — 這是上一則裡說「還沒有解決」的那一件。判斷兩台是不是同一台主機時，先前必須兩項硬體識別資訊都不同才算不同主機，而 Synology 機器其中一項永遠是空的，兩台就永遠不算不同 — 於是第二台會接手第一台的位置，而第一台從此每一次上傳都被回絕，兩邊都不會顯示任何錯誤。現在改用主機自己產生的安裝識別碼來判斷，兩台各自保有自己的名稱與紀錄。同一台主機換了網路卡仍然是同一台，不會被當成新主機。
連線被拒絕時，不再宣稱「主機已被停用」 — 連線被拒有好幾種原因，而畫面先前一律顯示「Hub 已停用此主機」。實際上最常見的原因是名稱已經被另一台主機使用，於是這句話會把人帶去找一個不存在的原因。現在會說明兩種可能，並直接指出該做的下一步（重新綁定這台主機）。
沒有人登入主控台的主機，也會取得自己的身分 — 主機的安裝識別碼先前只在有人開啟主控台或重新綁定時才會產生，所以一台裝好之後就沒有人再登入的主機永遠只以名稱被辨識，也就永遠會遇到上面第一項的問題。現在主機會自己完成這件事，不需要任何人登入。

1.0.16 · Hub 1.0.16 — 2026-09-08

只是打開網站首頁，不會再被當成探測而封鎖 — 偵測「有人在探管理站台」的兩條規則，先前只看對方碰過哪幾個站台，不看它要求了什麼。而一次首頁造訪本來就會留下兩筆紀錄（先連上 HTTP、再被導到 HTTPS），這兩筆就足以讓那兩條規則成立，於是只是點進網站的位址也會被封鎖七天。現在必須至少有一個「一般訪客不會去要的路徑」，才會判定為探測；首頁、圖示、樣式檔，以及這個網站確實會正常回應的網址，都不算。偵測與封鎖本身沒有變弱：真的在找 /wp-login.php、/.env 這類路徑的，一樣會被擋。
名稱相同的第二台主機，不再每次連線都被拒絕（Hub） — Hub 會替名稱重複的第二台配一組屬於它自己的識別碼，但那組識別碼先前沒有回到主機手上，於是主機仍然用舊的身分連線，每一次上傳都被回絕，而兩端都沒有說明原因。現在會帶回主機端。Synology NAS 上的名稱重複還沒有解決，那是另一個原因，仍在處理中。

1.0.15 — 2026-09-08

經常重新啟動的主機，自動更新現在真的會執行 — 更新的每日檢查是從程式啟動那一刻開始算 24 小時的，所以一台每天重新啟動不只一次的主機（NAS 尤其常見）永遠等不到那一刻，自動更新看起來是開著的，卻從來沒有跑過，而畫面上不會有任何說明。現在會把上次檢查的時間記下來，啟動時若已經超過一天就補做一次。如果您的主機停在某個舊版本而自動更新是開著的，這就是原因。

1.0.14 · Hub 1.0.15 — 2026-09-07

名稱相同的主機共存，這一版才真的生效 — 上一版說明的那件事，主機端已經到位，但 Hub 那一側沒有把主機的識別碼帶進判斷，所以綁定還是會被拒絕。已修正：現在名稱重複的第二台會自動取得一個屬於自己的識別碼並正常加入。要用到它，主機上的 SvrGuard 必須是這一版或更新。
綁定沒有成功時，會直接說出原因，而且就在你按下按鈕的那個畫面上 — 先前會換到另一個畫面，只寫「請回到主控台再試一次」。那句話沒有告訴您發生什麼事，照著重試也不會有不同的結果。
兩台主機帶著同一組安裝識別碼時，會說明原因 — 複製虛擬機或還原備份會把識別碼一起複製過去。先前這種情況只會得到一個沒有說明的錯誤；現在會告訴您該解除綁定哪一台，或重新安裝。

1.0.13 · Hub 1.0.14 — 2026-09-07

名稱相同的主機現在可以同時加入機隊 — 先前主機是用它自己回報的名稱辨識的，於是兩台名稱一樣的主機（例如兩台都叫 NAS）會被當成同一台：後加入的那一台綁定不會成功，而先加入的那一台也可能被它取代。現在每台主機在安裝時會產生一組只屬於自己的識別碼，名稱重複不再影響綁定，機隊清單上兩台都會分別列出。名稱仍然可以重複，它只是給您看的標籤。

2026-09-07 — 下載與安裝方式調整

一行安裝現在會自己挑對的安裝包 —— 有 apt 的主機裝 deb、有 dnf／yum／zypper 的裝 rpm，兩者都沒有才用 tar.gz。走套件管理器的那兩種會順便把相依套件處理掉，執行檔放在 /usr/bin/svrguard。
安裝過程不再逐題詢問 —— log 路徑自動偵測，服務裝好就啟動，裝完只剩「綁定到您的帳號」一個動作。想自己逐題設定的話，改用 tar.gz 手動安裝：解開後執行 sudo sh install.sh，那是現在唯一還會逐題詢問的路徑。
先前用一行安裝裝過的主機不會被換成套件 —— 那種安裝在 /opt/svrguard，而套件接不上它原本的設定與封鎖紀錄。腳本偵測到就會維持原本的方式，並把原因印出來。
在 Synology NAS 上，安裝腳本會拒絕執行，並告訴您該裝哪一個 .spk。DSM 把已安裝的版本記在套件資訊裡，繞過套件中心放進去的執行檔會與它對不上，而中間不會有任何一步失敗。
下載頁更正了四處說明 —— 驗證封鎖是否生效的指令、Synology 支援的 DSM 版本、防火牆後端的描述，以及「主控台沒有另外的管理密碼」（登入一律用您的 Hub 帳號）。

1.0.12 — 2026-09-07

按下「更新程式」之後，畫面不會再變成伺服器的錯誤頁 —— 更新會把服務重新啟動，而在那短短幾秒裡，先前有機會讓瀏覽器落到一張「Service Unavailable」上，看起來像出了事，其實更新正在正常進行。現在那張「更新中」的畫面由按下按鈕的那一次回應直接畫出來，不再需要等服務回來才畫得出，所以整段過程都看得到進度與結果。
「有新版可更新」與「按下去真的會更新」現在是同一個條件 —— 先前在少數情況下，主控台會顯示可以更新，而更新程式判斷之後什麼都不做，畫面就一直停在等待。兩邊的判斷已經合併成同一套規則。
更新完成後重新整理頁面，不會再跳出「要重新送出表單嗎」。

Hub 1.0.12 — 2026-09-07

Hub 主控台的更新畫面與主機端一致 —— 同上，按下更新之後看到的是 SvrGuard 自己的「更新中」，而不是伺服器的錯誤頁。
更新裝完之後會多做一次核對 —— 先前只確認服務有起來，而服務起得來並不代表換上去的是新的那一顆。現在會核對裝好的確實是要裝的那一版，不符就當成失敗並說出來。

1.0.11 — 2026-09-06

這一版沒有任何功能變更 — 它存在的目的是讓我們把「更新」這件事本身，在真實的機器上完整跑一次並確認結果。您不需要為了它做任何事；照平常的方式更新即可，更新後的行為與 1.0.10 完全相同。之所以還是寫在這裡，是因為您的主控台會提示有新版可更新，而「有新版卻查不到它改了什麼」不應該發生。

Hub 1.0.10 — 2026-09-06

帳號的信件會用您在主控台選的語言 — 重設密碼的信先前是照當下那個瀏覽器的語言寫的，而要求重設密碼時您並沒有登入，所以您在主控台選過的語言根本沒有被用到：同一個帳號，從不同語言的瀏覽器要求，會收到不同語言的信。現在改成以帳號選過的語言為準；從來沒有選過的帳號，仍然沿用您當下閱讀網站的語言。
帳號信件的主旨不再附上一串機器代號 — 密碼重設、Email 驗證這類信件的主旨後面會接一段主機識別，那是為了「這封信在講您哪一台機器」而設計的，但帳號的信件跟任何一台機器都無關，接上去只是一串看不懂的字。攻擊通知與監控告警仍然會標明是哪一台主機，那是您需要的。

1.0.10 — 2026-09-06

更新時蓋住畫面的那一層，這次真的會結束 — 上一版把更新的結果分成三種說法，但那層畫面用來詢問主機的憑證會隨著服務重新啟動一起消失，於是它問到的其實是登入頁，而不是答案；畫面照樣一路撐到十分鐘上限，看起來與修好之前一模一樣。現在改用不需要登入的方式詢問，重啟之後仍然問得到，三種結果才真的會出現。從 1.0.9 升上來的那一次仍然是舊畫面——那一次的畫面是升級前那個版本畫的，要等這一版裝好之後的下一次更新，才看得到差別。

Hub 1.0.9 — 2026-09-06

續訂提醒信不再寫出金額 — 實際扣款的金額以您在 Paddle 收到的收據為準；信件本身只告訴您哪幾份訂閱即將續訂、以及在到期前要怎麼關閉它。
更新頁會分別說出兩個時間 — 先前只有一句「版次由管理端在報到時指定」，看不出這一版是什麼時候裝上的，也看不出管理端上次指定版次是什麼時候。這兩件事不一樣：「六月起就是最新的」與「六月之後就沒有人再問過」在畫面上原本長得一樣。現在兩個時間分開顯示；如果這一版不是自我更新裝上的，也會直接說沒有安裝時間可以顯示。
自動更新那一句不再叫您去按一個不存在的按鈕 — 自動更新關閉時，頁面一律寫「需要有人按上面的按鈕」，包括上面根本沒有按鈕的時候（已經是最新版，或管理端還沒有指定版次）。現在這兩種情況各自說明自己的狀況。

2026-09-06 — 價格調整

Pro 訂閱價格調整為每台每年 US$59（原 US$30） — 自 2026-09-06 起適用於新購買的訂閱。已經購買的訂閱不受影響：到期日不變，服務照常運作到那一天。免費的部分沒有任何改變——偵測、封鎖、誤判時的解除封鎖與白名單、攻擊通知，一樣不需要訂閱。

1.0.9 — 2026-09-06

更新程式時，畫面會等主機回來，並說出結果 — 先前按下更新之後，畫面會蓋上一層「更新中」，然後就停在那裡；等到十分鐘上限到了，它只會說「請重新整理並確認目前版本」，等於把「到底成功了沒有」丟回給您自己查。現在那層畫面會持續詢問主機是否重新上線（服務重啟期間連不上是預期的，不會被當成失敗），並且分成三種結果：更新完成會顯示從哪一版換到哪一版並請您重新登入；更新未完成（服務回來了但版本沒變）會明說版本沒有改變；等待逾時則說明我們沒有等到結果、請您確認目前版本——這三種不再共用同一句話。
威脅位址庫那一列不再只是一片空白 — 這一列沒有按鈕（每日排程會自動檢查並套用），所以它說的話就是您唯一的線索。先前「來源上有比較新的一份、還沒輪到套用」與「根本連不上更新來源」在畫面上長得一模一樣，而後者代表這台主機已經停止接收威脅位址庫。現在會分別說明：已最新／來源有新版將於每日排程套用／無法比較版本／讀不到更新來源。
本機資料庫的成長有了上限 — 規則命中紀錄與 IP 檔案先前沒有保留期限，會一直累積。現在兩者都保留 90 天。目前正在封鎖中的位址不受影響，封鎖清單上的國家、分類與歷程照常顯示。

1.0.8 — 2026-09-05

每天的資料庫整理不會再被重新啟動打斷 — SvrGuard 每天會清掉過期的存取紀錄，只保留設定的天數。但那個排程是從程式啟動起算滿 24 小時才執行，所以只要主機重開機、套件更新或服務重啟得比一天還頻繁，這個整理就一次也不會跑——資料庫會持續變大而畫面上沒有任何跡象。實測一台機器因此累積了 12 天的紀錄（設定是 3 天），檔案 235 MB。現在啟動時會檢查上次整理的時間，錯過了就補跑。
資料庫不再記錄用不到的逐網址統計 — 先前每天會為「當天被存取過的每一個網址」各留一筆統計並永久保存，而網路上的掃描每次都在試不存在的網址，所以那張表是跟著攻擊次數成長的，一台機器累積了 22 萬筆。這些資料沒有出現在任何畫面上，現在不再記錄，既有的也會在升級時清掉。偵測、封鎖與統計圖表都不受影響。
資料庫的暫存檔會定期收回 — SQLite 的寫入暫存檔（WAL）先前沒有任何時機被收回，在忙碌的主機上會一直長大。現在每天整理時會合併回主檔並清空。

1.0.7 — 2026-09-05

Synology 套件更新時，畫面會顯示更新正在進行 — 在 Synology NAS 上按下更新之後，那層「更新中」的畫面只閃一下就消失，接著回到一頁仍然寫著舊版本的畫面，看起來像沒有反應。更新本身一直是成功的，只是畫面沒有說出來。現在與其他平台一致：更新期間會蓋住主控台並顯示目前階段，完成後自動恢復。

1.0.6 — 2026-09-05

威脅位址庫更新後，新增的封鎖會立刻生效 — 先前套用一份新的威脅位址庫之後，畫面會回報寫入了幾筆封鎖，但那些位址要等下一輪同步才會真的進到防火牆。中間這段時間，資料庫裡看起來擋住了，實際上還沒有。現在套用完會立即同步防火牆。
登出頁上的「重新登入」不會再帶您到一頁錯誤訊息 — 從主控台登出之後，畫面上那個連結按下去會得到一頁純文字的錯誤。現在改為只提供真的走得通的兩條路：回到您剛才的位置，或前往 Hub 主控台。

1.0.5 — 2026-09-05

「規則包」與「規則庫」統一改名為「威脅判斷庫」 — 同一個東西先前在主控台、官網與通知信件裡有三種叫法。功能沒有改變，只是名稱。搭配上一版的「威脅位址庫」，現在兩個庫的名字說得出各自在做什麼：一個判斷行為，一個記錄位址。
更新進行中不會再誤按到別的功能 — 按下更新之後，整個主控台（含左側選單）會被蓋住，只留下目前的階段與進度，完成後自動恢復。先前更新途中頁面仍可點擊，切走再回來就看不出它到底跑完了沒有。
共享威脅情報只有真的有新資料時才顯示更新按鈕 — 與其他三列一致。先前它永遠可以按，而按下去多半只是再確認一次沒有新的。
帳號類信件會依照您的介面語言寄送 — 驗證信、重設密碼、到期與續訂提醒等 11 封信件，先前一律是中文，現在跟隨您在主控台選的語言。
兩則顯示錯誤已修正 — 英文介面上，系統更新頁的三則狀態文字會夾雜中文；規則更新的通知信裡版本號會印成一串亂碼（例如 v%!d(string=1.0.2)）。兩者都只影響顯示，更新本身一直是正常的。

1.0.4 — 2026-09-04

「惡意 IP 資料庫」改名為「威脅位址庫」 — 主控台、官網與通知信件的用詞一致改過。功能沒有改變，只是名稱：它擋的不只是 IP，改成這個名字比較貼近它實際在做的事。
系統更新頁看得到「最後更新」了 — 規則庫、威脅位址庫、共享威脅情報與程式本身，四列各自顯示上次成功取得或套用的時間。先前只看得到版本，看不出它是今天更新的還是停了兩週。
需要手動升級一次 — 規則庫與威脅位址庫的版本格式在這一版改成與程式相同的三段數字。舊版本的 agent 讀不懂新格式，而且不會顯示任何錯誤，它只是安靜地停止更新。請到下載頁取得安裝包，逐台手動升級一次；之後恢復自動更新。攻擊偵測與自動封鎖在這段期間照常運作，停的只有規則庫與威脅位址庫的更新。
網站上找得到聯絡方式了 — 每一頁的頁尾都加了聯絡信箱。

1.0.3 — 2026-09-04

Synology 主機恢復自動更新 — 1.0.0 起，NAS 上的自動更新會把每一個新版本都判定為「無法比較」而拒絕安裝，畫面上看起來像是刻意的安全檢查。這一版修好了。受影響的 NAS 需要手動安裝這一版一次：舊版本自己帶著這個問題，沒辦法靠自動更新跨過去。請到下載頁取得套件，用套件中心手動安裝，之後恢復自動更新。

1.0.2 — 2026-09-04

Synology 套件的「更新程式」按鈕修好了 — 在 NAS 上按下它會顯示「已觸發更新」，但實際上不會更新，而且畫面看不出來。現在它會走 Synology 套件的正確安裝流程。自動更新一直是正常的，受影響的只有手動按下去那一次。
不再顯示過期的更新狀態 — 主控台上方那則「自動更新目前沒有在執行」的警告，先前可能在問題排除後繼續留著。現在服務重新啟動時會清掉它。

1.0.1 — 2026-09-04

綁定主機頁修正 — 補上前往核准頁面的連結、加上「訂閱到期日」欄；沒有可以接手的主機時，不再顯示轉移選項。
看得到版本了 — 主控台側欄與 version 指令都會顯示版本與建置編號，回報問題時講得出自己跑的是哪一份。
新增這一頁 — 更新紀錄從這一版開始有。

1.0.0 — 2026-09-04

第一個正式版本。

版號改制 — 版本從此是 1.0.0 這種三段數字，取代先前以建置日期組成的編號。agent、Hub 與管理端各自發行、各有各的版號。
威脅位址庫更新修復 — 修正一個會讓威脅位址庫停止更新的錯誤。更新狀況可在主控台的「系統更新」頁看到。
舊版主機需手動升級一次 — 若您的主機還在舊編號（例如 6376.0.20260903），自動更新不會跨過這次改版，也不會誤裝：請到下載頁重新取得安裝包裝一次。之後的版本恢復自動更新。