DLR 恢復週：未知佔比必須在恢復流量前歸零

在簡訊發送暫停後，盲目且過快地恢復發送量是極易耗盡餘額的陷阱。未知的 DLR 狀態代表上游路由並未真正送達，這會導致大量的發送失敗。解決之道在於利用短時間的採樣窗口進行監控，確認未知狀態佔比降至安全範圍後，方可逐步解鎖 API 的完整發送流量。

流量恢復期間未知 DLR 激增的運作機制

當簡訊活動因未知的狀態回條突增而暫凍結時，盲目恢復完整發送量將是代價高昂的錯誤。未解決的未知狀態代表上游電信路由正在丟棄回條或無法回報終端手機狀態。若僅憑樂觀而非乾淨的遙測數據來擴大流量，恐會將餘額燒在未驗證的路徑上。若要理解最初的觸發原因，請參閱我們的 DLR 異常週：未知佔比是停止線指南。恢復作業需要先確認下游電信商已承認終端狀態，才能解鎖更高的傳輸量。我們必須確保所有網路路徑在重新導向大量訊息前都經過完整壓力測試，以避免不必要的成本浪費。此過程涉及仔細檢查每個路由節點的 DLR 報告，特別是那些回報為「未知」的狀態。這些未知狀態可能源於網路延遲、臨時性故障，或更糟的情況，即終端網路根本不發送回條。在恢復流量之前，必須透過 console 介面或 API 查詢，確認這些未知狀態的比例已降至零。僅有當所有先前出現問題的路由都已回報清晰的終端狀態（例如：已送達、已投遞、失敗）時，才能逐步增加流量。此階段的關鍵是耐心與嚴謹的數據驗證，而非急於恢復業務量。

凍結後測量真實的未知佔比

為了判定路由是否真正準備好恢復流量，應透過緊密的 15 分鐘取樣窗口來計算未知佔比，而非依賴每日平均值。若未確認回條的比例持續超過 5%，該路由即被視為不穩定。若透過含糊的路徑持續推送 OTP 或交易型訊息，將導致無聲的投遞失敗。若高未知率持續存在，您的帳戶恐將陷入DLR 第二個月：演變成習慣的未知佔比狀況，導致回報準確度永久劣化。透過精確的數據分析，技術團隊可以迅速辨識並隔離表現不佳的節點。具體操作上，應設定監控警報，當任意 15 分鐘窗口內的未知 DLR 比例超過預設閾值（例如 5%）時，自動觸發通知。這需要定期檢查平台 console 中的 DLR 報告儀表板，或透過 API 串接即時數據流。一旦發現未知佔比升高，應立即暫停該路由的流量，並進入調查模式，而非等待每日報告。這種即時反應機制是防止問題擴大的關鍵。

清除 DLR 遙測：逐步審計

在恢復流量之前，請追蹤整個帳戶的 webhook 與狀態回呼。參考未送達、拒收與過期狀態指南，區分未確認網路確認、有效期限過期以及電信商硬拒收。使用 JIT 號碼指派執行低流量金絲雀測試，以觀察乾淨的 webhook 回應。唯有當終端狀態比例恢復正常時，才能放寬自動化流量限制。落實每一個審計步驟有助於建立長期穩健的訊息傳遞生態系統。此審計應包含驗證接收 DLR 的 webhook 端點是否正常運作，確保其能夠即時處理並儲存回條數據。檢查 webhook 的日誌，確認是否有錯誤或延遲。同時，應確認平台設定的 DLR 逾時（timeout）參數是否合理，以避免過早將可恢復的狀態標記為失敗。金絲雀測試的流量應足夠小，以最小化潛在損失，但又足以觸發 DLR 機制並產生可供分析的數據。觀察這些測試流量的 DLR 回報，確認其準確性與及時性。

表格：DLR 恢復指標與流量規則

此表格是恢復流量的決策樹。當未知 DLR 佔比超過 15%，必須立即停止所有流量，並暫停任何自動恢復機制。只有當未知佔比降至 5% 到 15% 之間時，才允許進行小規模的金絲雀測試，以驗證路由的穩定性。只有當未知佔比穩定地低於 5%，且終端狀態回報清晰準確時，才能逐步、謹慎地恢復流量。這需要持續監控，並準備好在任何指標惡化時再次凍結流量。

設定預付費閾值與平台防護機制

當您測試未驗證的路由時，財務控管機制能保護您的平台。請維持至少 USD 20 的預付費下限，以保持線上 webhook 活躍，並避免在恢復階段發生計費中斷。當流量恢復且每月花費接近 USD 1,000 的溫和審查門檻時，合規監控能確保路由品質維持在可接受範圍內。利用預付費保留機制可確保資金僅在即時路由檢查通過時才會撥付。嚴格的財務防護措施能讓平台在應對突發流量波動時更加從容不迫。預付費錢包的餘額是防止意外超支的最後一道防線。設定自動充值規則，確保錢包餘額始終高於最低閾值。在恢復流量的關鍵時期，應密切關注帳戶餘額消耗速度，並與 DLR 恢復進度進行比對。若發現餘額消耗異常快，但 DLR 數據並未顯示對應的投遞成功率，這可能意味著流量正被導向無效或欺詐性路由，需要立即停止並調查。此外，應考慮啟用「quiet hours」功能，在非工作時間自動降低流量或暫停發送，以避免在夜間發生不可控的 DLR 問題或高額費用。

開始使用 IOSOR

恢復走廊上的 unknown 佔比必須清掉，量才能回來。匯出清理證明——unknown 百分比下降、終態已標、同一相關視窗。unknown 還坐著就別拉下一波。本週是清理閘，不是維護抽空劇本，也不是第二個月的習慣獵。此階段的重點是徹底清除所有未知的 DLR 狀態，確保每一個發送出去的訊息都有明確的終端回報。這可能需要與電信商溝通，了解其 DLR 回報延遲或丟失的原因。利用 IOSOR 平台的 console 功能，可以清晰地看到各個路由的未知 DLR 比例，並設定警報。只有當所有路由的未知佔比降至零，並且持續一段時間（例如數小時）保持穩定後，才能考慮逐步恢復流量。切勿在未知狀態尚未完全清除前，就急於恢復原有的發送量，這只會導致問題的惡性循環。

IOSOR 要點

恢復週只有 unknown 清掉才放量——不是視窗結束就放。

要做：這條走廊 unknown 佔比沒了再拉升。

不要：報表裡還有 unknown 就恢復轟炸，或把抽空的佇列叫清理。

在恢復流量的過程中，必須嚴格遵守「未知佔比歸零」的原則。這意味著在恢復任何流量之前，必須確保所有路由的未知 DLR 狀態比例為零。這不是一個可以妥協的指標。一旦未知佔比再次出現，即使比例很小，也應立即暫停流量，並重新進行調查。恢復流量的過程應該是逐步的，每次增加的流量比例應與 DLR 監控指標的改善程度相匹配。例如，當未知佔比降至 1% 以下時，可以嘗試恢復 10% 的流量，並密切觀察 DLR 數據。如果數據保持乾淨，則可進一步增加流量。此過程需要耐心和持續的監控，確保平台的穩定運行和訊息的可靠投遞。確保所有 OTP 和關鍵交易訊息的路由都經過嚴格的 DLR 驗證，避免因未知狀態導致的潛在風險。