解決 apt update 重複來源設定錯誤

重複 apt 來源錯誤的含義

重複 apt 來源錯誤代表同一個軟體庫在兩個不同的檔案中被宣告，且 APT (advanced package tool) 發現了這兩份副本。在 Ubuntu 24.04 及更新版本中，這通常是因為第三方安裝腳本寫入了一個舊式的 .list 單行檔案，而該軟體庫的 .sources deb822 格式檔案早已存在於磁碟中。系統並未損毀，套件也沒有風險。刪除其中一個宣告，錯誤訊息就會消失。

這是使用者貼入搜尋框的內容：

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

請從結尾處開始閱讀。兩個檔案各標示了行號，宣告了相同的內容。Target Packages 是 apt 下載的索引，用以得知軟體庫提供哪些套件；stable/binary-amd64/Packages 則指定了該索引涵蓋的元件 (stable) 與架構 (amd64)。因此，apt 是在告知您，stable 元件的 amd64 索引已在 docker.list 的第 1 行設定，且在 docker.sources 的第 1 行又被設定了一次。

在 apt 3.0 及更新版本（即 Ubuntu 25.04 與 Debian 13 之後）中，相同的訊息會以 Warning: 開頭，而非 W:。前綴之後的文字內容則相同。

上述警告屬於輕微情況。apt 會合併這兩項宣告，更新作業仍可執行，因為兩者描述的是帶有相同金鑰的同一個封存檔。嚴重的情況則會導致作業完全停止：

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

apt 在此拒絕執行，因為這兩項宣告為同一個封存檔指定了不同的簽章金鑰。apt 可以合併兩項完全相同的宣告，但無法在兩個 Signed-By 值之間進行選擇，因為選錯會導致套件簽章檢查失敗（因為封存檔擁有者並未使用該金鑰簽署）。因此，apt 將不會讀取任何來源。在您手動編輯檔案之前，apt update 與 apt install 都會因為這兩行錯誤而失敗。

重複項的產生方式

這兩種格式分別存放在不同副檔名的檔案中，因此磁碟層級並未限制兩者同時存在。apt 直到將所有來源檔案展開為預計擷取的索引目標清單時，才會發現重疊。在此之前，docker.list 與 docker.sources 僅是兩個互不相關的檔案。

以下四種常見情況會導致此類重複：

• 廠商的安裝腳本，或是從舊文章複製的指令，寫入了包含 tee 行的 /etc/apt/sources.list.d/vendor.list 檔案。
• 廠商隨後發布了軟體包 /etc/apt/sources.list.d/vendor.sources 並為您安裝。
• Ubuntu 24.04 及更新版本中的 add-apt-repository 會寫入 deb822 格式的 .sources 檔案，因此您先前手動加入的 .list 來源，會以 .sources 的形式再次出現。
• 發行版升級將系統原有的來源設定重寫為 deb822 格式，但保留了您手動建立的 .list 檔案。

上述每一種路徑在單獨執行時皆屬合理。當其中兩者發生在同一台機器上（通常相隔數月）時，就會產生重複項。

兩種格式並列比較

舊格式為每個儲存庫佔用一行，且每一部分的順序皆為固定。

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

順序固定如下：類型（二進位套件使用 deb，原始碼套件使用 deb-src）、方括號內的選項、封存檔的 URI（統一資源識別碼）、發行套件名稱（suite），最後是一個或多個元件（components）。由於意義取決於位置，空格位置錯誤會導致 apt 讀取錯誤。

deb822 格式則以具名欄位的段落（stanza）呈現相同資訊。其名稱源自 RFC 822，即 Debian 已用於套件控制檔的郵件標頭格式。

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

相同的儲存庫、相同的金鑰，無需額外設定。對應關係非常直接：deb 變為 Types，封存檔位址變為 URIs，發行套件名稱變為 Suites，元件變為 Components，而每個方括號內的選項則各自成為獨立欄位，例如 signed-by= 變為 Signed-By:，arch= 變為 Architectures:。

每個欄位名稱皆為複數形式，因為每個欄位均可接受以空格分隔的清單。單一段落中的 Suites: noble noble-updates noble-backports 可取代三行獨立的 deb。空白行代表段落結束，因此單一 .sources 檔案可包含多個儲存庫。deb822 亦支援舊格式難以處理的設定：用 Enabled: no 停用儲存庫、Trusted、Check-Valid-Until，以及直接貼入 Signed-By 的內嵌金鑰（每行縮排一個空格，空白行以單一點號表示）。

檔案存放位置

• /etc/apt/sources.list：原始的單一檔案。在 Ubuntu 24.04 及更新版本中，此檔案通常為空，或僅包含指向新位置的註解。
• /etc/apt/sources.list.d/*.list：單行條目，通常每個軟體庫對應一個檔案。
• /etc/apt/sources.list.d/*.sources：deb822 格式的段落。Ubuntu 24.04 及更新版本將發行版自身的軟體庫存放在 ubuntu.sources。
• /etc/apt/keyrings/：存放您自行加入的金鑰。/usr/share/keyrings/ 則存放來自套件的金鑰。

apt 僅會讀取以 .list 或 .sources 結尾的檔案，且檔名僅能包含字母、數字、底線、連字號與句點。任何其他副檔名的檔案將被忽略並顯示通知，這對於下方的修正步驟至關重要。

尋找重複的配對

從目錄列表開始：

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

兩個具有相同主檔名但副檔名不同的檔案是常見的配對，但不要只看名稱。請讀取內容，因為重複的檔案可能隱藏在任何名稱之下：

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

該配對是兩個具有相同主機與相同套件庫的項目。兩者皆指向 https://download.docker.com/linux/ubuntu 與套件庫 noble，因此它們是重複寫入的同一個儲存庫。它們的 Signed-By 路徑也不一致，這就是導致先前顯示 Conflicting values 錯誤的原因。

在此步驟請使用 grep 而非 apt 指令。當 apt 因為衝突而停止運作時，它也無法列出您的來源，因此 apt-cache policy 只會印出相同的錯誤，而非您需要的答案。

修正方式：保留 deb822 檔案，移除舊版檔案

請保留 .sources 檔案。這是目前 apt 工具所採用的格式，也是 Debian 與 Ubuntu 未來的發展方向。在刪除任何檔案前，請先檢查磁碟上存在的是以下哪一個金鑰路徑：

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

若僅存在 /etc/apt/keyrings/docker.asc，則代表 deb822 檔案才是正確的來源，而 .list 檔案指向的是已移除的金鑰。若您打算保留的檔案中指定了不存在的金鑰，請先將可用的路徑複製進去，再刪除另一個檔案。

請將舊版檔案移出該目錄，而非直接刪除：

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

將其重新命名為 docker.list.bak 並留在原處也是可行的，因為 apt 會忽略未知的副檔名，但每次執行 apt 時都會出現以下提示：

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

將檔案移至他處可避免螢幕出現此通知，同時又能保留備份。執行後正常的 apt update 應如下所示，不會出現同時指定兩個檔案的行：

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

現在請確認儲存庫在編輯後仍可正常運作：

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

若供應商的文件仍預設使用單行格式的檔案，您可以保留該檔案並刪除 .sources 檔案。無論採取哪種方式，請遵循一項原則：針對特定的歸檔（archive）與套件組合（suite），僅能由一個檔案進行宣告。

Why one broken third-party source wedges apt update

The neighbouring failure looks different and has the same root, a third party source apt cannot use. The first version is a missing key:

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

The Signed-By field is missing, or it points at a file that is not a usable key, so apt cannot verify the signature on the archive's InRelease file. It then throws that whole repository away rather than trust package lists it cannot check. Look at the key file itself:

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

A working key prints a pub line with a key id and a uid line naming the vendor. gpg: no valid OpenPGP data found. means the file is not a key at all, which usually means the download saved an error page because the key URL moved. Fetch the key again, check the file, then run apt update.

The second version arrives after a release upgrade:

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

The PPA has published nothing for that suite, so the path does not exist on the server and the request returns 404. Your other repositories still update, and the packages you already have are untouched. The run exits non-zero, though, so any script that checks the exit status of apt update now reports a failure every time it runs. That is why one dead source is worth clearing on a box with unattended security upgrades configured: the daily noise is where a real failure hides.

停用單一來源而不影響其他設定

針對 deb822 格式的檔案，請在該區段（stanza）中加入一個欄位並儲存：

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

apt 手冊建議採用此方式，而非註解掉區段中的每一行，且此方法更易於復原。若是單行格式的檔案，請在該行開頭加上 #。對於上述任一格式，將檔案移出 /etc/apt/sources.list.d/ 目錄也是可行的方法，若該軟體庫已永久停用，則應選擇此選項。

再次執行 sudo apt update。該軟體庫的 Err: 區塊將會消失，且結束狀態碼會回傳 0，您可在下一行透過 echo $? 進行確認。

切勿使用 sudo rm /etc/apt/sources.list.d/* 修復損壞的軟體來源。在 Ubuntu 24.04 及更新版本中，此指令會刪除 ubuntu.sources，該檔案包含發行版自身的軟體庫設定，導致 apt 失去所有套件清單，並針對明顯存在的軟體回報 E: Unable to locate package curl 錯誤。若您已執行過該指令，請將檔案寫回：

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

將其儲存為 /etc/apt/sources.list.d/ubuntu.sources，並將其中的 noble 替換為您從 lsb_release -cs 取得的發行版名稱，接著執行 sudo apt update。

將舊版 .list 檔案轉換為 deb822

自 2026 年 8 月起，apt 3.0 及更新版本內建了此轉換工具。Debian 13、Ubuntu 25.04 以及之後的所有發行版（包含 26.04）皆已包含此功能。請先檢查版本，再執行以下指令：

apt --version
sudo apt modernize-sources

此指令會將 /etc/apt/sources.list.d/ 下的單行格式檔案重寫為 deb822 格式的 .sources 檔案。請閱讀輸出訊息，接著自行列出目錄內容，並在確認結果無誤前執行 apt update。Ubuntu 24.04 搭載的 apt 版本較舊，不支援此子指令，執行時會顯示 E: Invalid operation modernize-sources。在該版本上，請依照上述欄位對應表手動轉換。

目前轉換作業並非強制，因為 apt 仍可讀取兩種格式。對於預計長期維護的伺服器，建議進行轉換，因為目前所有會寫入軟體來源的工具皆已改用 deb822 格式，若系統僅保留 .sources 檔案，即可避免此類重複設定的問題。

保持伺服器第三方來源的整潔

第三方軟體庫是伺服器中最容易老化的部分。每一個軟體庫都代表第三方開發者承諾為您的 Ubuntu 版本持續提供更新，而發行版升級則會在同一個下午測試所有這些承諾是否兌現。

• 僅在發行版套件無法滿足需求時，才新增第三方軟體庫。標準的 Ubuntu 24.04 上的 LAMP stack 不需要任何第三方來源：Ubuntu 官方歸檔庫已包含其使用的所有套件，並在該版本生命週期內提供安全性更新。
• 將金鑰存放在 /etc/apt/keyrings/ 中，每個供應商使用一個檔案，權限設為 644。非特權使用者 _apt 負責執行下載並需要讀取金鑰，因此若金鑰檔案僅限 root 可讀，將導致每次從該軟體庫擷取資料時出現權限錯誤。
• 在每個設定區塊中，將 Signed-By 指向該特定檔案。若將金鑰放置於 /etc/apt/trusted.gpg 或 /etc/apt/trusted.gpg.d/，該金鑰將被視為信任伺服器上所有軟體庫，這意味著多年前新增的供應商金鑰可能被用來驗證來自任何來源的套件。
• 在進行發行版升級前，請檢查您的來源設定，確認每個供應商皆已針對您即將升級的目標版本發布套件。

舊版全域金鑰環中的金鑰會在每次更新時發出警告：

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

請將該單一金鑰匯出至獨立檔案，並將設定區塊指向該檔案：

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

將 Signed-By: /etc/apt/keyrings/docker.gpg 新增至該軟體庫的設定區塊，並執行 sudo apt update。一旦沒有軟體庫依賴舊版金鑰環，警告便會消失，屆時您即可使用 sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 移除該項目。

養成另一個習慣能省去最多麻煩。do-release-upgrade 會在升級過程中停用第三方來源，並在升級後保持關閉狀態；手動逐一重新開啟這些來源，正是導致重複宣告產生的主因。在開始前，請先閱讀 Ubuntu 24.04 升級至 26.04 指南，並記錄下您仍需要的軟體庫。對於剛建置的機器，調整來源設定的最佳時機是在 新 VPS 的前十分鐘，此時伺服器上僅存在 Ubuntu 原生提供的項目。

FAQ

為什麼 apt 顯示目標被重複設定？

因為在 /etc/apt/sources.list.d/ 下有兩個檔案宣告了相同的儲存庫、套件集與元件。錯誤訊息會列出這兩個檔案及其行號，例如 docker.list:1 與 docker.sources:1。apt 會合併這些設定並繼續執行，因此更新本身仍可運作。不過，清除重複設定仍是較佳做法：一旦這兩個檔案指定了不同的簽章金鑰，apt 就會以 E: Conflicting values set for option Signed-By 錯誤停止執行並拒絕讀取任何來源，這也會導致 apt install 無法運作。

我應該保留 .list 檔案還是 .sources 檔案？

請保留 .sources 檔案。deb822 是 Ubuntu 24.04 及更新版本中 add-apt-repository 所使用的格式，它為每個設定使用具名欄位，而非方括號內的定位文字，這也是發行版的發展方向。在刪除 .list 檔案前，請先確認 .sources 檔案內的 Signed-By 路徑指向一個確實存在的金鑰，可使用 ls -l /etc/apt/keyrings/ 進行驗證。請將舊檔案移出 /etc/apt/sources.list.d/，不要直接在該目錄內重新命名，因為殘留的 .bak 檔案會導致 apt 在每次執行時都顯示忽略檔案的通知。

如何在不移除的情況下停用 apt 儲存庫？

在 deb822 格式的 .sources 檔案中，請在該區段加入 Enabled: no。若為單行格式的 .list 檔案，則在該行開頭加上 #。無論採用哪種方式，隨後請執行 sudo apt update，該儲存庫的 Err: 區塊就會消失。當第三方儲存庫尚未提供適用於您 Ubuntu 版本的套件，且其 404 錯誤導致 apt update 以非零狀態碼結束時，這是正確的處理方式。

單行格式的 sources.list 會被淘汰嗎？

它已被棄用，但尚未移除。apt 仍會讀取 .list 檔案，且在未來很長一段時間內皆會支援，因此您的伺服器不會立即發生故障。新的工具會寫入 deb822 格式：Ubuntu 24.04 及更新版本將發行版儲存庫保留在 /etc/apt/sources.list.d/ubuntu.sources 中，而 add-apt-repository 則會寫入 .sources 檔案。在 apt 3.0 及更新版本中，可使用 sudo apt modernize-sources 將現有的檔案進行轉換。