兩個層面所發出的訊號

當挖礦業務看似出現異常時，兩種不同類型的資訊經常被混為一談：礦機控制板上不斷上升的硬體錯誤計數，以及礦池後台不斷攀升的拒絕份額（rejected share）數量。這兩者雖然相關，卻是由挖礦流程中不同層面所產生的，所衡量的並非同一件事。

硬體錯誤屬於礦機端的遙測資訊——是由 ASIC、其控制板或韌體所回報的狀況。拒絕份額則是礦池端的驗證結果——是礦池針對某一份提交工作所作出的判斷。若將其中一方視為另一方的證據，可能導致操作者在實際問題其實是網路路徑壅塞時更換算力板，或是在礦池後台數據看似正常時，忽略了真正存在的晶片故障問題。

本文將把這兩種訊號分開說明，解釋各自真正能可靠反映的狀況，並在僅有其中一項出現異常時，提供一套實用的排查順序。

ASIC 硬體錯誤實際回報的內容

在大多數 ASIC 礦機上，狀態介面會顯示硬體錯誤計數（通常標示為 HW 或 HW errors），同時還會顯示其他欄位，例如 ASIC 狀態、每片算力板偵測到的晶片數量，以及回報的算力。Bitmain 自家針對其狀態頁面的說明文件，將這些欄位分別定義如下：HW 反映礦機回報的硬體或運算錯誤；ASIC 狀態為「0」代表晶片正常，非零或「X」值則可能代表該晶片未能正常運作；另有一個獨立欄位會回報該算力板上偵測到的正常運作晶片數量（Bitmain Support）。

僅憑 HW 錯誤計數上升，並不能確鑿證明硬體發生故障。Bitmain 指出，部分硬體錯誤可能在設備以滿載算力正常運作期間發生，並可在內部自行修正，不會中斷挖礦運作。若計數緩慢增加，但本機算力維持穩定、晶片數量完整、溫度正常，這通常屬於較弱的訊號；相較之下，若同時出現多項指標組合——本機算力下降、算力板回報的晶片數量少於預期、反覆出現溫度保護事件、風扇或電源故障，或設備日誌顯示無法偵測到板上晶片——這樣的組合才更值得透過礦機自身的診斷日誌（而非礦池數據）來進一步隔離排查，確認是否屬於設備層級的狀況。

由於 HW 錯誤計數器、其重置行為以及其確切含義皆由各廠商的韌體自行定義，因此不應將其視為統一的標準化指標，跨不同 ASIC 型號進行比較。

拒絕份額實際回報的內容

在聯合挖礦（pooled mining）中，礦機並不會將完整區塊提交給礦池，而是提交「份額」（shares）——即符合礦池份額目標的工作量證明結果。礦池的份額目標在數值上設定得高於比特幣網路的區塊目標，因此更容易達成，其對應的難度亦低於實際找到一個區塊所需的難度；份額讓礦池得以衡量每台礦機在兩個區塊之間所貢獻的工作量（Bitcoin Developer Guide）。

拒絕份額是一個統稱，泛指任何未被礦池接受的已提交份額。其具體原因通常屬於以下幾個子類別之一，而非「拒絕份額」本身的同義詞：

• 過期份額（Stale share）——該工作在較早的挖礦任務中曾屬有效，但送達時該任務已不再是當前任務。
• 無效份額（Invalid share）——未能通過礦池驗證檢查的提交內容。
• 重複份額（Duplicate share）——同一份額被重複提交超過一次。

比特大陸（Bitmain）將礦池的拒絕率定義為礦池所拒絕的數據量與礦工所傳送總數據量之比，並指出網絡不穩定是拒絕率升高的主要成因之一（Bitmain Support）。這對診斷問題有重要意義：一連串的過期份額（stale shares）大多反映的是礦機與礦池節點之間的時序或連接狀況，而非晶片層面的故障。相比之下，無效份額（invalid shares）有時可能源於不穩定的挖礦設置、韌體問題或不一致的供電——這些情況同時也會影響硬件表現——因此，無效份額上升是一個較合理（但仍非決定性）的訊號，提示需要檢查設備本身。

若礦池對同一時段的接受與拒絕次數均有提供數據，則可按以下方式計算原始拒絕百分比：

Rejected share count ÷ (Accepted share count + Rejected share count) × 100

此數值僅在「接受」與「拒絕」次數涵蓋相同時間窗口且採用相同份額難度（share-difficulty）設置時才具有意義；若該時段內份額難度曾發生變化，則原始次數將不再代表可比較的工作量。此外，該結果也不應被解讀為 BTC 收益損失的直接百分比，因為實際收益取決於實際被接受的工作量、礦池的收益計算方式，以及找到區塊的時間點，而非單純的份額比率。

為何這兩種訊號容易被混淆

硬件錯誤與份額被拒絕這兩者之間的混淆，通常源於兩種習慣性做法：一是假設任何屏幕上出現的紅色提示都代表同一類問題；二是比較在不同時間窗口或由不同系統測量所得的數字。礦機本地顯示屏報告的是設備自身觀察到的情況——自身的晶片狀態、自身的錯誤計數、自身計算出的算力。而礦池後台報告的則是礦池從其接收到的份額中觀察到的情況——這不僅取決於礦機的輸出，還取決於網絡路徑、上報間隔，以及礦池自身的驗證邏輯。

當實際的硬件問題導致礦機產生不穩定或無效的工作量，進而被礦池拒絕時，這兩種訊號可能會同步變化。但它們也可能各自獨立變化：一台狀態完全正常的 ASIC 礦機，可能因礦池節點擁堵或距離較遠而顯示較高的過期份額率；而一台已出現早期硬件不穩定跡象的礦機，若礦池尚未收到足夠多受影響的提交份額以呈現出明顯模式，其拒絕率仍可能看似正常。

實用的診斷方法

與其孤立地對任一數字作出反應，不如先解讀具體訊號，再對照一組簡短的問題進行核對，然後再判斷問題所在。

若硬件錯誤計數持續上升，應檢查本地算力、晶片數量及溫度是否保持穩定。若這些指標均保持穩定，則該計數本身作為故障證據的說服力較弱。若本地算力下降、出現晶片缺失，或同時記錄到溫控或風扇故障，則設備本身便值得進一步檢查，首先應查閱礦機自身的日誌。

若被拒絕的份額持續上升，應檢查主要集中在哪個子類別。若模式主要集中在過期份額，則應首先關注連接路徑——所選的礦池節點、路由或重連行為——而非算力板（hashboards）。若模式主要集中在無效份額，則更合理的做法是檢視近期的韌體或調參變更、供電穩定性及散熱情況，同時查閱設備自身的錯誤日誌。

無論哪種情況，都應確認該模式是僅影響單一礦工（worker），還是同時影響透過同一路徑連接的多個礦工。若問題僅局限於單一設備，則問題指向該設備本身；若問題同時影響多台原本彼此獨立的礦機，則指向共同的環節，例如網絡連接或礦池節點。

為何本地與礦池算力數據會不一致

另一個常見的混淆來源，是礦機本身顯示屏上的算力與礦池後台顯示的算力之間的不匹配。這兩個數字並非可互換的指標：本地算力是設備自行回報的估算值，採用製造商自訂的刷新與平均運算方法；而礦池的算力則是根據其在指定時間窗口內實際收到的share所推算出的估算值。

以ViaBTC的後台為例，其即時算力是以前10分鐘為區間計算的滾動平均值，而日算力則是以前24小時為區間計算的滾動平均值（ViaBTC）。在重啟或短暫斷線之後，礦機的本地算力可能在數分鐘內恢復正常，但礦池的24小時數據卻可能因為先前的停機時間仍在該滾動窗口之內，而維持偏低更長時間。這屬於測量窗口效應，並不能單獨作為硬件錯誤或礦池端問題的證據；在將任何一方的數據視為故障確認之前，應先比較相同時間段內的數字。

結論

硬件錯誤計數與拒絕份額（rejected share）計數所回答的是不同的問題：前者描述的是ASIC本身所回報的狀況，後者描述的是礦池對提交工作所作出的判定。閱讀具體的拒絕原因、檢查硬件信號是否伴隨其他設備層面的症狀，並在比較數字前對齊測量窗口，通常會比把每一個紅色指示都當作同一類故障來處理，得出更準確的診斷結果。

常見問題

HW錯誤計數持續上升，是否總是意味著算力板出現故障？

不一定。部分硬件錯誤可能在正常運作期間發生，並在不中斷挖礦的情況下被自動修正。若持續上升同時伴隨本地算力下降、芯片缺失，或溫度與風扇故障，則比單憑計數本身更能有力地證明設備確實存在問題。

過期（stale）、無效（invalid）與重複（duplicate）share是否屬於三種同等程度的問題？

它們都只是較廣泛的「拒絕份額」結果之下的子類別，而非彼此平行的獨立指標。每一種都指向不同的可能成因：過期份額多與時間延遲或連線問題有關，無效份額多指向硬件或配置方面可能不穩定，而重複份額則多與軟件或連線行為導致的重複提交有關。

我可以用拒絕率來估算挖礦收益損失嗎？

原始拒絕率是以同一時期內相匹配的接受與拒絕份額數量計算得出的，它所描述的是礦池未接受的提交工作所佔的比例。這並非一個標準化的收益損失指標，因為實際收益取決於礦池的結算方式、share難度與出塊時機等因素，而不僅僅是這個原始比例。

為何我礦機屏幕顯示的算力與礦池後台不同？

兩者採用不同的測量方法與時間窗口。礦機的本地顯示是設備自行回報的估算值，而礦池後台反映的則是在指定滾動週期內實際收到的share數量。這種差異更可能是報告窗口效應所致，而非硬件或礦池故障的證據，尤其是在剛剛重啟之後更是如此。

參考資料

• Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
• Bitmain Support, "Miner Status Page Explained" — https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• Bitmain Support, "The Rejection Rate of Mining Pools" — https://support.bitmain.com/hc/en-us/articles/5220664696473-The-rejection-rate-of-mining-pools
• ViaBTC, "Mining Pool with Real-Time Hashrate Monitoring: Understanding Measurement Windows and Latency Effects" — https://www.viabtc.com/en/blog/Mining-mining-pool-with-real-time-hashrate-monitoring-understanding-measurement-windows-and-latency-effects-941