エラーの概要
サードパーティのaptリポジトリ（Docker、Kubernetes、Spotifyなど）を追加しようとして、次のコマンドを実行します：
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ABCDEF1234567890
30〜60秒間フリーズした後、以下のエラーが表示されます：
gpg: keyserver receive failed: General error
エラーメッセージが少し異なる場合もあります：
gpg: keyserver receive failed: No keyserver available
gpg: keyserver receive failed: Connection refused
いずれにしても、パッケージのインストールがブロックされます。以下に解決方法を説明します。
原因
原因によって対処法が異なるため、どれに該当するかを把握することが重要です：
- キーサーバーがダウンまたは到達不能 — keyserver.ubuntu.com は定期的にオフラインになることがあり、数時間に及ぶこともあります
- ポート 11371 がブロックされている — ファイアウォール、企業のプロキシ、またはVPSプロバイダーがアウトバウンドのHKPポート 11371 をブロックしています
- DNS解決の失敗 — キーサーバーのホスト名がネットワーク内で解決できません
- GPGバージョンの不一致 — 古いバージョンのGPGは、最新のキーサーバーとのTLSハンドシェイクに問題があります
- 非推奨の
apt-keyワークフロー — Ubuntu 22.04以降ではapt-key advは完全に非推奨となっており、使用すべきではありません
修正方法1：別のキーサーバーに切り替える
深夜に最も手っ取り早い方法は、別のキーサーバーを試すことです。Ubuntuのキーサーバーは不安定なことで知られています。MITやOpenPGP.orgの方が負荷に対して安定しています。
# MITキーサーバーを試す
sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys YOUR_KEY_ID
# またはOpenPGP.org
sudo apt-key adv --keyserver hkp://keys.openpgp.org:80 --recv-keys YOUR_KEY_ID
# またはポート80でUbuntu（11371のファイアウォールブロックを回避）
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys YOUR_KEY_ID
:80 の指定は重要です。HKPポート 11371 の代わりにHTTPポート 80 で接続を強制します。11371 がブロックされているネットワークでは、これだけで問題が解決します。
修正方法2：curlで直接キーをダウンロードする
キーサーバーを使わない方法です。ほとんどのリポジトリメンテナーは、GPGキーを直接URLで公開しています（Docker、HashiCorp、GitHub CLIなどすべて対応しています）。ソースから直接取得しましょう：
# 方法1：curlからapt-keyに渡す（古いUbuntu/Debian向け）
curl -fsSL https://example.com/repo-key.gpg | sudo apt-key add -
# 方法2：モダンなアプローチ（Ubuntu 22.04以降）
curl -fsSL https://example.com/repo-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/repo-name.gpg
次に、sources.listエントリで参照します：
echo "deb [signed-by=/usr/share/keyrings/repo-name.gpg] https://repo.example.com stable main" | sudo tee /etc/apt/sources.list.d/repo-name.list
Dockerの公式ドキュメントでも、まったく同じパターンが使用されています：
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
修正方法3：hkps://でgpgを直接使用する
apt-key adv が何度も失敗する場合は、バイパスして gpg をHTTPSキーサーバーサポートで直接呼び出します：
gpg --keyserver hkps://keys.openpgp.org --recv-keys YOUR_KEY_ID
キーをエクスポートしてaptに渡します：
gpg --export YOUR_KEY_ID | sudo apt-key add -
# またはモダンな方法：
gpg --export YOUR_KEY_ID | sudo gpg --dearmor -o /usr/share/keyrings/repo-name.gpg
修正方法4：企業プロキシ環境の場合
HTTPプロキシを持つ企業ネットワークはよくある原因です。GPGのdirmngrdデーモンはプロキシ設定を自動的に読み取りません — 明示的に設定する必要があります。
~/.gnupg/dirmngr.conf に以下を追加します：
keyserver hkps://keys.openpgp.org
honor-http-proxy
次に、プロキシの環境変数を設定してdirmngrdを再起動します：
export http_proxy=http://proxy.company.com:3128
export https_proxy=http://proxy.company.com:3128
gpgconf --kill dirmngr
gpg --keyserver hkps://keys.openpgp.org --recv-keys YOUR_KEY_ID
修正方法5：ファイアウォールがすべてのキーサーバートラフィックをブロックしている場合
一部のVPSプロバイダー（例：Oracle Cloud Free Tierや特定のHetzner設定）は、デフォルトでキーサーバーポートへのすべてのアウトバウンドトラフィックをブロックしています。そのようなマシンからはどのキーサーバーも機能しません。
回避策：制限のないマシンでキーを取得し、コピーする方法です。
# ローカルマシンで：
gpg --keyserver keyserver.ubuntu.com --recv-keys YOUR_KEY_ID
gpg --export --armor YOUR_KEY_ID > repo-key.asc
scp repo-key.asc user@your-server:/tmp/
# サーバー側で：
sudo apt-key add /tmp/repo-key.asc
# またはモダンな方法：
sudo gpg --dearmor -o /usr/share/keyrings/repo-name.gpg /tmp/repo-key.asc
修正方法6：gnupgとdirmngrdを再インストールする
不完全なシステムアップグレードや失敗したマイグレーションにより、GPGツールチェーンが壊れた状態になることがあります（権限の誤り、古いソケットファイル、破損したキーリングデータベースなど）。クリーンな再インストールで通常は解決します：
sudo apt-get remove --purge gpg gpg-agent dirmngr
sudo apt-get install gnupg2 gnupg-agent dirmngr
# 古い状態をクリア
rm -rf ~/.gnupg
gpg --list-keys # 正しい権限で~/.gnupgを再作成
その後、元のキーインポートを再試行してください。
確認方法
キーをインポートしたら、実際に登録されているか確認します：
# 旧方法
sudo apt-key list
# 新方法（Ubuntu 22.04以降）
ls -la /usr/share/keyrings/
gpg --show-keys /usr/share/keyrings/repo-name.gpg
sudo apt update を実行します。正常な出力には NO_PUBKEY の警告もGPGエラーも表示されません：
sudo apt update
# 期待される出力："Hit:" または "Get:" の行のみ
予防策
プレイブックやセットアップスクリプトから apt-key adv --keyserver を削除してください。キーサーバーワークフローはUbuntu 22.04以降で非推奨となっており、どの環境でも不安定です。代替パターンは3ステップです：
curlを使用してリポジトリの公式URLからキーをダウンロードするgpg --dearmorを使って/usr/share/keyrings/に保存する- sources.listエントリで
signed-by=を使って明示的に参照する
キーサーバーへの依存がなくなることで、エアギャップ環境でも動作し、キーサーバーの障害にも影響されず、ネットワークアクセスが制限されたCI/CDパイプラインでも確実に実行できます。