この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ゴールデンウィーク明け、出社前のコーヒー片手に運用機にSSHした瞬間、画面が止まりました。
2026年5月1日の朝のことです。前日4月30日の夕方（米時間）からCanonicalのインフラがDDoS攻撃を受けていて、archive.ubuntu.com も security.ubuntu.com も Snap Store も Launchpad も、ぜんぶ反応が鈍くなっていた。日本時間で見ると、5月1日朝に「世界的に何かおかしい」と認識された格好です。20年以上Linuxサーバーの運用に関わってきましたが、apt update がここまで広範に詰まる事象は記憶にないです。本稿では、現役の管理者目線で「apt update が急に遅い・失敗する」と感じたときに、現場でどう切り分けて、どう逃がすかを順序立てて書きます。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「apt update が急に遅い・失敗する」と感じたら、まず確認すべきこと
最初にやることは、深呼吸と「自分の環境か、上流か」の切り分けです。SSH 接続直後にいきなり apt 関連の作業へ飛ばないでください。切り分けの順番は、私はいつもこの3つです。
・自ホストのネットワーク: ping で外に出るか、DNSは引けるか
・上流（Ubuntu のミラーやsecurityフィード）: archive.ubuntu.com / security.ubuntu.com が応答するか
・apt の状態: ロックや前回失敗の残骸がないか
具体的には、まずこれを叩きます。
$ ping -c 2 8.8.8.8 $ getent hosts archive.ubuntu.com $ curl -I https://archive.ubuntu.com/ubuntu/dists/jammy/Release $ curl -I https://security.ubuntu.com/ubuntu/dists/jammy-security/Release
apt update が失敗する代表的な4パターン（普段から起こり得る要因）
DDoS のような事件がない平時でも、apt update は普通に失敗します。代表的なものを4つ整理しておきます。今回の事件と似た症状を、別の原因で何度も見てきました。1. ミラーサーバー側の一時障害
特定ミラー1台のディスクや Apache が落ちている、というのはよくあります。日本国内ミラー（jaist、kddilabs、riken など）でも、年に数回は計画/非計画の停止があります。2. DNS / ネットワーク経路の問題
社内の DNS キャッシュが古い、上位ISPの経路でパケロス、IPv6 だけ詰まっているのに IPv4 にフォールバックしない、といった話です。getent hosts と ping -4 / ping -6 で順に確認します。3. apt のロック・前回失敗の残骸
「E: Could not get lock /var/lib/dpkg/lock-frontend」「dpkg was interrupted」のたぐいです。unattended-upgrades が裏で走っていたり、前回 Ctrl+C で止めた残骸が残っていたりします。4. proxy / 認証 / 証明書まわり
社内 proxy 経由の環境で、proxy 側の証明書が更新されて apt が信頼できなくなった、HTTPSフェッチで TLS ハンドシェイクが詰まる、といったパターンも頻出です。今回のCanonical DDoSは、見た目の症状（タイムアウト、Hash sum mismatch、503）が上記1〜4と区別がつきにくいのが厄介な点でした。だからこそ「上流が落ちていないか」を最初に確認する癖をつけておきたいです。
2026年5月のCanonical DDoS障害の経緯と影響範囲
事件の事実関係を、確認できた一次情報ベースで整理します。・発生: 2026年4月30日（木）夕方（米時間）に開始。日本時間5月1日朝に世界的な障害として認識される。約20時間以上継続。
・主な影響対象: archive.ubuntu.com / security.ubuntu.com / Launchpad / Snap Store を中核に、ubuntu.com / canonical.com / login.ubuntu.com / Livepatch API / Landscape など Canonical配下サービス全般。
・Canonical公式の動き: 公式の Ubuntu Discourse（投稿者: arcticp）に2026年5月1日付で第一報、5月6日付で緩和措置の適用と謝罪を追記。
・引用（一次情報そのまま）:
・"we have implemented mitigations and restored services affected by the Distributed Denial of Service (DDoS) attack."
・"You may experience partially degraded performance on some of the services."
・"We sincerely apologize for the recent disruption to the availability of our services."
・攻撃集団: 自称「The Islamic Cyber Resistance in Iraq — 313 Team」（通称 313 Team）。報道では「親イラン系（Iran-aligned）とされる」ハクティビスト集団と紹介されています。Canonical公式のDiscourseアナウンスは、攻撃者名を直接名指ししていません。
・国内: gihyo.jp が2026年5月8日付で「DDoS攻撃の緩和措置を適用」「CVE-2026-31431（Copy Fail）」を含めて報道（記事URL）。JPCERT / IPA からの注意喚起は本稿執筆時点で未確認のため、本稿でも触れません。
ここで強調したいのは、apt update 文脈では「archive.ubuntu.com」「security.ubuntu.com」が落ちる影響が最も実害です。前者はパッケージ本体、後者はセキュリティアップデートの配信元。とくに後者が止まると、別件で公開されていたカーネル脆弱性 CVE-2026-31431（通称 Copy Fail、CVSS 7.8）のパッチが取れない、という二次被害につながります。CVE-2026-31431 自体は2026-04-22にNVD公開、4-29にTheori詳細公開、CISA KEV緩和期限は2026-05-15。本DDoSと因果関係はありませんが、時系列が重なって「直したいのに直せない」状況が広域で起きました。本稿の核心はここです。
「自分のapt失敗が事件起因か環境起因か」を切り分ける手順
事件起因か環境起因かを混ぜて考えると、対処も混ざって余計に時間がかかります。順番に切り分けます。1. 上流の生死を curl で見る
$ curl -ISs --max-time 10 https://archive.ubuntu.com/ubuntu/dists/jammy/Release | head -1 $ curl -ISs --max-time 10 https://security.ubuntu.com/ubuntu/dists/jammy-security/Release | head -1
2. apt 側のキャッシュとロックを確認する
$ ls -l /var/lib/apt/lists/ $ ls -l /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock 2>/dev/null $ sudo lsof /var/lib/dpkg/lock-frontend 2>/dev/null
3. 詳細ログで Hash sum mismatch / Connection timed out を見分ける
$ sudo apt update -o Debug::Acquire::http=true 2>&1 | tail -50
国内ミラー（jaist等）への一時切り替え手順
archive.ubuntu.com 系が詰まっているなら、国内ミラーへ一時的に逃がすのが最短です。再起動も不要、sources.list の書き換えだけで済みます。代表的な国内ミラーは以下です。
・JAIST: https://ftp.jaist.ac.jp/pub/Linux/ubuntu/
・理研: https://ftp.riken.jp/Linux/ubuntu/
・KDDI研究所: https://ftp.kddilabs.jp/Linux/distributions/ubuntu/
書き換えはバックアップを取ってから sed で一発です。
# まずバックアップ（必ず取る） $ sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%Y%m%d) # Ubuntu 22.04 / 24.04 の例: archive.ubuntu.com を JAIST に切り替え $ sudo sed -i.bak \ -e 's|http://[a-z]*.archive.ubuntu.com/ubuntu/|https://ftp.jaist.ac.jp/pub/Linux/ubuntu/|g' \ -e 's|http://archive.ubuntu.com/ubuntu/|https://ftp.jaist.ac.jp/pub/Linux/ubuntu/|g' \ /etc/apt/sources.list # 24.04 系の DEB822 形式（/etc/apt/sources.list.d/ubuntu.sources）の場合 $ sudo cp -a /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak $ sudo sed -i \ 's|http://[a-z]*.archive.ubuntu.com/ubuntu/|https://ftp.jaist.ac.jp/pub/Linux/ubuntu/|g' \ /etc/apt/sources.list.d/ubuntu.sources # 反映確認 $ sudo apt update
proxy / sources.list の修正の具体例
社内 proxy 経由の環境では、apt の挙動を proxy 設定が左右します。proxy 側で Canonical 宛の通信が詰まっている、というのも今回の事件で目撃されたパターンです。1. apt 専用 proxy 設定を確認する
$ ls /etc/apt/apt.conf.d/ | grep -i proxy $ cat /etc/apt/apt.conf.d/*proxy* 2>/dev/null
2. ミラー単位で挙動を分岐させる
「security だけは Canonical 直、それ以外は国内ミラー」のように使い分けたい場合、sources.list を分割する書き方が安全です。# /etc/apt/sources.list（メインリポジトリは国内ミラー） deb https://ftp.jaist.ac.jp/pub/Linux/ubuntu/ jammy main restricted universe multiverse deb https://ftp.jaist.ac.jp/pub/Linux/ubuntu/ jammy-updates main restricted universe multiverse # /etc/apt/sources.list.d/security.list（security は Canonical 直） deb https://security.ubuntu.com/ubuntu jammy-security main restricted universe multiverse
復旧後の整合性チェック（apt-cache・dpkg --configure -a 等）
ミラー切替や proxy 修正で apt update が通るようになったら、まず壊れていないかを確認します。慌てて apt upgrade を走らせると、中途半端な状態を上書きしてしまうことがあります。# 1. dpkg の中断を解消 $ sudo dpkg --configure -a # 2. apt 側の依存と壊れたパッケージを修復 $ sudo apt -f install # 3. インデックスを取り直す $ sudo rm -rf /var/lib/apt/lists/* $ sudo apt update # 4. キャッシュ整合性を見る $ apt-cache policy | head -20 $ apt-cache stats # 5. 取得済み .deb の検証 $ sudo apt-get check
再発に備える運用設計（複数ミラー登録・監視）
事件は終わりました。怖いのはここから先で「のど元過ぎれば」になりがちな点です。私自身、過去にRedhatのRHN障害で半日詰まった経験を、そのうち忘れて同じ穴に落ちかけました。今回ぶんは記録として残すのが筋だと思います。1. 複数ミラーを sources.list に併記する
apt は sources.list の上から順に試すので、平時は国内ミラー、フォールバックで Canonical 直、という書き方が現実的です。deb https://ftp.jaist.ac.jp/pub/Linux/ubuntu/ jammy main restricted universe multiverse deb https://ftp.riken.jp/Linux/ubuntu/ jammy main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse
2. apt の到達性を死活監視に組み込む
死活監視（Zabbix / Prometheus / Mackerel など）に、archive.ubuntu.com / security.ubuntu.com への curl チェックを足しておくと、事件発生時にメール / Slack で勝手に気づけます。# シンプルなcron監視例（5分おきに security の Release を取りに行く） */5 * * * * curl -ISs --max-time 10 https://security.ubuntu.com/ubuntu/dists/jammy-security/Release \ > /dev/null 2>&1 || echo "security.ubuntu.com unreachable" \ | mail -s "[ALERT] apt security mirror" admin@example.com
3. 緊急パッチの「取れない期間」を運用に織り込む
今回のように security.ubuntu.com が止まると、CVE 緊急パッチは取れません。Ubuntu Pro の Livepatch / Landscape など、Canonical の別経路サービスが使えるか、平時に整理しておくとよいです。「再起動なしでカーネル CVE を当てたい」「事件中でも別経路でパッチを撒きたい」が要件なら、ライセンス費用は十分に元が取れる場面が増えます。受講生から「Livepatch は払う価値がありますか」と聞かれたら、最近は「年に1回でも今回みたいな事件があれば、それだけで元が取れます」と答えています。まとめ — 依存リスクと、Linux管理者が日常で備えるべきこと
apt update が急に遅い・失敗する原因は、平時なら4パターン（ミラー障害、DNS / 経路、apt のロック残骸、proxy / 証明書）。事件下では上流が落ちていないかを最初に切り分け、国内ミラーに逃がす。復旧後は dpkg --configure -a と apt -f install で整合性を取り、保留にしていた緊急パッチを最優先で取りに行く。これが今回の事件から私が持ち帰った手順です。本質的に怖いのは、apt が止まったことそのものより「Canonical の単一インフラに依存していた」事実が顕在化したことだと思います。Linux は「無償で使えて、誰でも構築できる、自由な OS」と言われ続けてきました。でも実運用では、配布インフラと CVE 対応はディストリビュータに頼り切りです。今回の事件は、その依存の太さを可視化しました。
ふだんから自分の手で sources.list を書き、ミラーを切り替え、apt のログを読み、ロックを解除する。地味ですが、こういう作業を一度でも自分の指で通しておくと、事件が起きたときに固まらずに動けます。私が20年以上この仕事を続けてこられたのも、結局そういう小さな反復の積み重ねでした。
参考
・Canonical公式 Ubuntu Discourse（DDoS第一報・追記）: https://discourse.ubuntu.com/t/update-concerning-ddos-attack-on-canonical-and-ubuntu/81482・gihyo.jp Ubuntu Weekly Topics 2026-05-08: https://gihyo.jp/admin/clip/01/ubuntu-topics/202605/08
・NVD CVE-2026-31431（Copy Fail）: https://nvd.nist.gov/vuln/detail/CVE-2026-31431
・JAIST Ubuntu ミラー: https://ftp.jaist.ac.jp/pub/Linux/ubuntu/
「上流が落ちても自分の手で逃がせる」運用、自信を持てていますか？
sources.list、ミラー切替、proxy、dpkg --configure -a、死活監視。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます