更新紀錄

最後更新：2026-09-10

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

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

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），自動更新不會跨過這次改版，也不會誤裝：請到下載頁重新取得安裝包裝一次。之後的版本恢復自動更新。