安裝這個韌體（版本：h6.0.0.3500 Build 20260520 發佈日期：2026-05-29）後，我的 NAS 在登入時會花 20 秒以上嘗試連線，看起來是連到 MyQnapCloud（但我根本沒啟用或使用這個功能）。登入後，開啟 Qnap App Center 也要再等 20 秒以上。如果你跟我一樣，在路由器上封鎖了這種隨機訪問網際網路的請求，登入時就會多等 20 秒或更久，因為 NAS 會跑這一段遙測流程。我覺得 Qnap 可能快不問你要不要和他們分享資料就直接傳了。看起來也沒辦法解除安裝或停用 MyQnapCloud，雖然我已經把它的相關服務全關掉、也沒做任何埠轉發。看來我只能試著調整 Qnap 的防火牆規則了。
嗨，歡迎來到論壇。 
打開應用程式中心時，系統會自動從 QNAP 儲存庫伺服器更新 QPKG 清單。對於像 myqnap.org 這樣的第三方儲存庫也會這樣做，這是很正常的。
如果你封鎖了 QNAP 伺服器的存取，應用程式中心的啟動時間就會拉長，而且本地的儲存庫清單也會過時。
感謝你的意見。不過，我的重點是，如果像我一樣，使用者針對 NAS 設定了防火牆規則以監控和阻止某些連線，那麼在 6.0 韌體下登入時會觸發更長時間的遙測（telemetry）程序。這種情況在 5.x 韌體下並不存在。使用之前的韌體時，我並沒有遇過登入延遲 20 或 30 秒的情況，而且我也不明白為什麼只要我不進入 App Center 或 MyQnapCloud，我的 NAS 每次登入都還是需要查詢 Qnap 伺服器。
如果你不想等待，那就不要封鎖這些連線。
如果你想阻止韌體正常工作，那你就不能抱怨由此產生的副作用。
那是因為軟體本來就會進化。每一個版本都不是上一個版本的複製，也不會完全一樣，也很正常。
也許 QNAP 的人可以來說明一下登入過程中到底發生了什麼？我已經知道 App Center 的狀況，但登入時的原因我只能猜了。
根據 Qnap 日誌，NAS 多次從不同的埠連接至 Amazon AWS 伺服器，顯然是在登入時嘗試同步某些資訊。我在路由器上並沒有設定特別的規則來封鎖這些連線。我認為是連線重複的特性導致路由器拒絕這些請求。
tcp 0 1 172.x.x.x:59822 3.171.85.4:1337 SYN_SENT
tcp 0 1 172.x.x.x:55936 3.171.85.32:1337 SYN_SENT
tcp 0 1 172.x.x.x:55906 3.171.85.32:1337 SYN_SENT
tcp 0 1 172.x.x.x:59826 3.171.85.4:1337 SYN_SENT
tcp 0 1 172.x.x.x:52634 3.171.85.110:1337 SYN_SENT
tcp 0 1 172.x.x.x:55922 3.171.85.32:1337 SYN_SENT
首先，你不需要隱藏你的 172.x.x.x 區段的 LAN 位址，因為這是屬於私人網路位址範圍，全球有數百萬人都在自己的內部網路中使用這種位址。這不是一個公開可訪問的位址空間。
其次，可能有各種各樣的原因，這些原因都與「與 QNAP 共用」資料無關。系統啟動時很有可能在做韌體更新檢查或其他作業。我不太確定 QNAP 在 Hero 6 裡做了哪些事情，但很有可能他們在安全更新等方面採取了更積極的作法。NAS 開機時，可能就會主動檢查韌體是不是最新的，並看你是否需要更新。
我個人認為，過度限制裝置不是一個最好的資安做法，如果你真的想這麼做，那你就需要接受相關的後果。
我不明白為什麼有人對我在這裡分享的警世故事變得如此防備，尤其是在有人寫出我根本沒說過的話時。我在安裝 6.0 韌體之前或之後，並沒有特別封鎖 Qnap 伺服器。我只是觀察到登入和存取 App Center 的過程變得非常緩慢，而 Qnap 試圖聯絡它的 AWS 伺服器，這在韌體更新前並沒有發生。
另外，雖然單純的私有 IP 位址對潛在駭客來說用處不大，但在這個 AI 時代，私有 IP 若與其他資訊（例如暴露的服務、外洩的憑證或漏洞）結合，確實會增加區域網路的風險。所以，我當然有權選擇不提供對診斷我的問題沒幫助的資訊。總之，這個主題我就到此為止，準備轉換話題了……
呃，不是的。暴露私有 IP 一點風險都沒有。暴露你的公有 IP 才有風險。
而且沒有人在防衛。只是覺得你的防火牆會阻擋外部查詢這件事很奇怪。
而且，是的，我們可能有點被你「小心……」這個標題弄得不爽 —— 你這麼寫就代表有什麼壞事發生了。其實並沒有。
嗨 @Bitbytes，
感謝你回報這個問題並詳細分享觀察狀況。
根據你的描述，這個延遲似乎在將 NAS 升級到 QuTS hero h6.0.0 之後出現，尤其是當 NAS 處於路由器/防火牆限制或監控特定對外連線的網路環境下。我們理解，這種情況對於將 NAS 運作於嚴格離線或有限連線環境的使用者來說，可能會造成困擾。
為了協助我們進一步調查，能否請你提供更多關於 NAS 防火牆規則的細節？
例如：
- NAS 是否預設阻擋所有對外連線
- 有無針對 QNAP 服務、AWS IP、DNS、HTTPS 或自訂連接埠的允許/阻擋規則
- 防火牆是阻擋、拒絕，還是靜默丟棄這些連線
- NAS 登入或啟動 App Center 時段的防火牆日誌
- 若將 NAS 暫時放到限制較少的網路環境中，是否仍出現相同延遲
你可以在分享前將任何敏感的公網 IP 位址或內部網路資訊遮蔽。
這些資訊將有助於我們瞭解延遲是否與特定的連線檢查、服務請求或防火牆行為有關，並協助我們向工程團隊提供更正確的回饋。
再次感謝你讓我們注意到這個問題。
我已經更改了你的用戶等級，現在你可以發送私人訊息了
他提出了兩點，而你回應了他的第二點，也就是如果封鎖 QNAP 雲端，App Center 會加載很久。但更令人擔憂的問題是登入。我不認為僅僅是登入 UI 會有 20 秒的延遲。還有沒有人在使用 QuTS 6，如果封鎖網路，也會這樣嗎？我現在還在用 QuTS 5，斷網的情況下還是可以立即登入。
我同意，但「完全沒連上 WAN」和「部分有 WAN 存取」還是有很大的差別。
我覺得這引出了更大的「還有什麼」的問題。如果你因某種原因和它想要連接的東西斷開，那還會不會有其他地方卡住？登入要等 20 秒，appcenter 也要 20 秒——假設你要修東西、需要到處操作一下。是不是每點一次 UI 或每敲一個指令都要再等 20 秒？說真的，這讓人很沒信心。
我們不了解他的情況。目前，他是我唯一看到抱怨 Hero 6 登入延遲很久的人。如果這是普遍性的問題，我相信會有更多人抱怨。
沒錯。所以我才問6版上有沒有人也遇過這情況。畢竟離線操作可能很少見，算是個邊緣狀況吧。也許有其他在用 QuTS 6 的人可以試著把 WAN 線拔掉一分鐘，看能不能重現或者排除這個問題。