本文目錄
剛為工作與日常使用的訂閱取好名稱，重新整理後卡片卻都變成 auto，很容易以為設定檔被換掉了。先確認改變的是卡片名稱、訂閱內容，還是目前選取的項目，再核對完整應用程式版本，避免為了改名而刪除仍可使用的訂閱。
重新整理後只剩 auto，訂閱真的不見了嗎？
專案 #8365 回報 v2.5.9+autobuild.1020.9dd5aa6 在更新訂閱後，會把名稱改成 auto，回報環境為 macOS。維護者將此情況與 #8360 的遠端名稱更新改動連結；這不能證明所有平台或正式版都受影響。
另一個 #8348 需求正好相反：v2.5.8 使用者希望重新整理訂閱時，也同步伺服器端的名稱。兩份回報描述的是不同版本的行為，不能將後者視為 v2.5.8 也會覆寫手動名稱的證據。
先確認需要處理的是什麼
| 看到的變化 | 先做什麼 |
|---|---|
| 卡片名稱改變，但原訂閱網址、節點與選取狀態仍對應原設定檔 | 依名稱遭覆寫的情況排查，先保留訂閱，不要刪除後重新匯入。 |
| 節點、規則也變了，或目前選取了另一張卡片 | 檢查實際更新的內容與選取的設定檔；改名無法修正這些差異。 |
| 名稱沒有改變，只是未同步伺服器端已修改的名稱 | 先記錄使用的版本；這與新的自動建置版本覆寫手動名稱是不同問題。 |
名稱為什麼會取自網址中的 auto？
受影響的提交在重新整理遠端訂閱時，會將新取得的名稱寫回既有設定檔。核對的實作會參考回應的 content-disposition；若沒有這個回應標頭，可從訂閱 URL 移除查詢參數後的最後一段取得名稱，因此會出現 auto 或 main。
這裡的顯示名稱不是原則群組名稱或節點名稱。修改卡片名稱不等於修改訂閱 URL，也不代表節點驗證資料被換掉；但更新本身仍會取得設定內容，因此還要另外核對選取的設定檔與實際請求。
先在應用程式中記錄完整版本，不能只看 v2.5.9 這一段，也不能把自動建置版本當成正式發行版。本文針對回報中的特定建置版本與固定提交；後續建置是否仍有相同行為，應核對其發行說明與實際重新整理的結果。
上游隨後透過 #8366 撤回這次名稱寫回的改動，固定撤回提交為 27d8a71。原始碼撤回不代表已安裝的套件會自動取得修正；本次核對的最新正式版仍為 v2.5.8，不能據此將所有預覽建置都稱為已修正。
先備份，再還原卡片名稱
先記錄目標卡片的原名稱、訂閱來源、選取狀態與自動更新開關。訂閱 URL 常含驗證資訊，記錄只留在本機；螢幕擷取畫面或意見回報中應遮蔽路徑中的驗證資料與查詢參數，不要把完整網址放進名稱。
需要獨立備份時，從「設定 → Verge 進階設定 → 備份設定」建立本機備份，再開啟「檢視紀錄」，使用該筆紀錄的「匯出備份」儲存到獨立位置，並確認檔案可讀取。只在應用程式資料目錄中建立備份，不代表已經匯出。
只調整目標訂閱所需的設定
等待目前的更新結束
先確認目標訂閱已停止重新整理。關閉定時更新不會強制取消已送出的請求，太早改名仍可能被這次更新覆寫。
開啟編輯資訊
在「訂閱」頁面對目標卡片按滑鼠右鍵，選擇「編輯資訊」。在「編輯設定檔」視窗中確認訂閱 URL 與記錄一致，只修改「名稱」，不要誤用「編輯檔案」或刪除卡片。
需要時暫時關閉自動更新
若要在受影響的建置版本中暫時保留這個名稱，可關閉同一視窗中的「允許自動更新」並儲存，記錄原本的更新間隔與開關狀態。等待已送出的更新完成後，再確認名稱仍然正確。
重新啟動後確認用的是原設定檔
正常結束應用程式後重新開啟，核對名稱、目標卡片與選取狀態，並測試原本使用的網頁或應用程式。無須為了修改顯示名稱而清空設定檔、切換核心或修改 DNS。
暫停自動更新只能減少下次覆寫的機會，並未修正命名邏輯。手動點選「更新」仍會請求遠端設定檔，名稱仍可能再次改變；暫停期間也不會自動收到服務提供者的新節點，問題解決後應恢復原本的更新安排。
如何讓伺服器提供可辨識的名稱？
若訂閱由他人維護，可向服務提供者說明：受影響的建置版本在重新整理時會使用遠端名稱，目前回應是否提供了可辨識的 content-disposition？提供遮蔽敏感資訊後的現象與版本即可，不要將完整訂閱網址貼到公開 issue。
自行維護訂閱服務時，應在傳回訂閱內容的 HTTP 回應標頭中提供合適的檔名，不要將這個欄位寫進訂閱 YAML。下方僅示範回應標頭的位置與形式；既有後端的設定方式應依其文件操作。
content-disposition: attachment; filename="work-profile.yaml"修改後再檢查用戶端實際收到的名稱，並確認更新的仍是同一份訂閱。顯示結果可能經過檔名解析與清理，不能只因伺服器端某處寫過名稱，就斷定用戶端一定收到；不要為了改顯示名稱而擅自更換含驗證資訊的 URL。
用重新啟動與下次更新核對結果
核對這幾項後再決定是否保留設定
- 已獨立記錄目標卡片的訂閱來源、目前選取項目、原名稱與更新開關。
- 儲存並正常重新啟動後，名稱仍然正確，實際使用的訂閱與節點也沒有選錯。
- 同一網頁或應用程式的新請求可以完成；分別檢查名稱是否還原、連線是否正常。
- 暫停自動更新時，介面狀態與記錄一致；若手動更新後再次改名，應明確記錄這個暫時做法仍有限制。
- 確認伺服器端名稱或後續建置版本可用後，恢復原本的自動更新安排，再檢查下次更新與正常重新啟動的結果。
手動重新整理以比較結果前，先保留記錄，並暫停不能中斷的請求，因為訂閱更新可能重新載入目前的設定檔。記錄更新前後的名稱、版本、時間與實際內容；不能只因重新啟動一次後名稱沒變，就宣稱重新整理覆寫名稱的問題已修好。
仍遭覆寫時，先保留設定檔再處理版本
撤銷這次的名稱與開關修改時，依記錄還原原值，保留原訂閱與可用設定檔。若持續覆寫名稱而影響辨識，可先採用上述短期手動辨認方式，並等待維護者提供明確處理方法；不要反覆刪除、重新匯入來碰運氣。
需要更換應用程式版本時，先保留目前資料與獨立匯出的備份，從專案正式發行來源核對目標版本。本文未驗證跨版本資料相容性，不能讓另一版本直接覆寫唯一的資料目錄，也不保證降級一定能解決。
還原整份備份會覆寫應用程式資料並觸發重新啟動，不適合作為單純修改顯示名稱的第一步。確實需要還原時，先另外儲存目前狀態，核對備份來源與適用版本，再依應用程式的還原流程檢查所有訂閱與選取項目。
回報時提供完整應用程式版本、作業系統、是否手動更名、自動更新狀態、更新前後名稱，以及遮蔽敏感資訊後的回應標頭情況。後續修正應以明確提交與發行紀錄為準；issue 關閉本身不能證明已安裝的版本包含修正。