多店家登入狀態總掉線：依Cookie過期、快取堆積、代理切換三步排查

週三15:04，第4個店家後台彈出了登入頁。你剛做完第2個店的批次改價，切回第4個店準備查庫存，螢幕已經變成"Please sign in again"。連續一週，每天至少兩次，五個店家隨機掉線。這不是平台"抽風"——是Cookie到期、多分頁快取溢載、代理IP漂移三層訊號疊加後的必然結果。依層排查，每層有獨立可驗證判據；三層都修完仍掉線，說明手動維護已越過臨界點，需要重新評估工具档位。

第一層：Cookie過期——掉線時間窗是否匹配平台TTL

各平台會話有效期差異很大：Amazon Seller Central約24小時，TikTok Shop約48小時，Shopify admin約30天，eBay約72小時。如果你的掉線節奏與某個平台的TTL吻合——比如每天固定時段彈登入頁——根因就在這一層。

1. 用筆記本記錄連續5次掉線的精確時間戳（精確到分鐘），標註對應店家與平台。
2. 對照各平台TTL±2小時窗口：5次中4次以上落在同一平台的窗口內，確認是Cookie自然過期。
3. 修復：在瀏覽器為該平台開啟"始終保持登入"（平台支援時），或在TTL到期前30分鐘手動刷新後台續期。若無法開啟持久登入，將續期動作寫入每日固定流程，避免遺忘。

第二層：快取堆積——多分頁共享儲存溢出的隱性代價

五個店家開在同一瀏覽器裡，每個分頁的 localStorage 和 IndexedDB 各自獨立但共享同一套瀏覽器儲存量配額。單分頁約佔用 40–80MB，五店疊加輕鬆突破 200MB。瀏覽器的 LRU 策略在儲存逼近上限時優先淘汰「最久未存取」分頁的資料——你剛切回的那個店家，它的會話 token 可能兩小時前已被靜默清除，一重新整理就顯示登入頁面。

1. 打開 DevTools→Application→Storage，逐分頁檢視各平台的 token 欄位是否仍存在。
2. 若某分頁的 Storage 為空或 token 缺失，但該分頁並未關閉，說明被 LRU 擠出。最小清理：關閉不活躍分頁→重新整理目標店家→重新登入→計時觀察 24 小時是否復現。
3. 長期方案：將不同平台的店家分屬不同瀏覽器執行個體，避免共享儲存量配額互相擠佔。

第三層：代理切換——IP 漂移觸發平台風控的靜默重置

代理節點切換後，瀏覽器發出的 Canvas 指紋、WebGL 渲染特徵、系統時區與新 IP 的地理歸屬不再一致。平台風控層將這次重新整理判定為「異常登入環境變更」，靜默重置會話而非彈出驗證碼——你看到的「掉線」實際上是風控側主動踢出，操作日誌裡不會有任何報錯。

1. 切換代理前：截圖各店家後台的「上次登入時間」與會話有效期作為基準。
2. 切換後 10 分鐘內逐店重新整理確認。出現異常的店家立即重新登入並記錄時間戳。
3. 若同一批代理切換後連續三天都有兩三個店家同時掉線，問題在代理綁定策略（同一出口 IP 被多店共用），而非單次操作失誤。

更深入的跨平台登入隔離配置與四步排查路徑，可參考TikTok Shop 賣家中心登入異常與 Shopify 多帳號風控頻發時的排查步驟與帳號隔離實操，其中按登入憑證、網路出口、瀏覽器指紋、資料行為四層信號給出了當天可跑完的最小隔離清單。

三層都修了還掉？按店鋪數×平台數判斷是否該升級工具