2026年5月5日の朝、 VPS で sudo apt update を実行したところ、突然エラーが出て失敗しました。昨日まで何も問題はなかったのに、です。
調べてみると、原因は私のサーバーではなく、 Ubuntu の開発元である Canonical 社がサイバー攻撃を受けていたことでした。
何が起きていたのか
エラーを見ると、以下のようなメッセージが含まれていました。
Connection failed [IP: 2620:2d:4000:1::101 80]
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/InRelease
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing
2620:2d:4000:1::101 は IPv6 アドレスです。
エラーの表面上は「 IPv6 接続の失敗」に見えますが、それは現象であって原因ではありません。
接続先のサーバーそのものがダウンしていたことが本質的な問題でした。
Canonical への DDoS 攻撃
2026年4月30日夜（ UK 時間18時頃）、 Ubuntu の開発元である Canonical 社のウェブインフラが、大規模な DDoS 攻撃を受けました。
DDoS 攻撃とは、大量の偽のトラフィックをサーバーに送りつけて過負荷にし、正常なアクセスを遮断する攻撃手法です。 サーバー内のデータを盗んだり改ざんしたりするものではなく、「つながらなくする」ことを目的とした攻撃です。
攻撃者は誰か
「313 Team（イスラム・サイバー抵抗・イラク）」と名乗るイラン系ハクティビストグループが、 Telegram チャンネルで犯行を主張しました。 このグループは2026年4月にも SNS プラットフォームの Bluesky や eBay に対して同様の攻撃を仕掛けており、欧米のテクノロジー企業を標的にした攻撃を繰り返しています。
攻撃には「 Beamed 」という DDoS 代行サービスが使用されました。 このようなサービスは「ブーター」や「ストレッサー」とも呼ばれ、技術的な知識がなくても料金を払えば大規模な攻撃が行えます。 今回使用されたサービスは 3.5 Tbps を超える攻撃トラフィックを発生させられるとされています。
影響を受けたサービス
この攻撃によって、12以上の Canonical / Ubuntu 関連ドメインがダウンまたは著しく低下しました。
ubuntu.com/canonical.com（メインサイト）archive.ubuntu.com（パッケージリポジトリ）security.ubuntu.com（セキュリティアップデート）login.ubuntu.com（ Canonical アカウント）launchpad.net/snapcraft.io（開発者ツール）maas.io/jaas.ai（クラウド・自動化サービス）
ユーザーデータへの影響はなし
パッケージリポジトリの内容そのものや ISO イメージは侵害されていません。 あくまでサーバーへのアクセスが遮断されたという「可用性」の問題です。 個人情報の流出や、パッケージへの改ざんは報告されていません。
攻撃の経緯と復旧
攻撃開始から約23時間後の2026年5月1日14時44分（CET）に主要サービスは一度復旧しましたが、その後も断続的な障害が続きました。 5月4日時点では全サービスが正常な状態に戻ったとされています。
Canonical は公式の X アカウントおよびステータスページで随時情報を公開し、「国境を越えた持続的な DDoS 攻撃を受けており、全力で対応中」と声明を出しました。
なぜ apt update が失敗するのか
apt update や apt upgrade は、パッケージ情報や更新ファイルを Canonical のサーバーから取得する仕組みです。
設定ファイルに記述された接続先として archive.ubuntu.com や security.ubuntu.com が使われています。
これらのサーバーが DDoS 攻撃でダウンしていたため、接続できずにエラーが発生していました。
Ubuntu はデフォルトで DNS 解決時に IPv6 を優先します。 そのため、エラーメッセージには IPv6 アドレスが表示されますが、問題の本質はサーバーへの到達不能です。 自分のサーバーの設定に問題があったわけではありません。
対処法：ミラーサーバーへの切り替え
archive.ubuntu.com や security.ubuntu.com がダウンしていても、世界各地のミラーサーバーは独立して稼働しています。
ミラーサーバーとは、公式リポジトリの内容を定期的に同期し、別の場所から同じパッケージを提供するサーバーのことです。
今回はミラーサーバーに接続するよう設定を変更することで、問題を解決しました。
JAIST ミラーとは
今回利用したのは、 JAIST（北陸先端科学技術大学院大学）が運営する Ubuntu の公式ミラーサーバーです。
http://ftp.jaist.ac.jp/pub/Linux/ubuntu
国内に設置されているため接続が安定しており、信頼性の高いミラーとして広く利用されています。
Ubuntu 24.04 での設定ファイルの場所
Ubuntu 24.04（Noble Numbat）以降、 apt のリポジトリ設定は従来の /etc/apt/sources.list ではなく、以下のファイルに移動しています。
/etc/apt/sources.list.d/ubuntu.sources
/etc/apt/sources.list を開いてみると、以下の一行だけが書かれた状態になっています。
# Ubuntu sources have moved to /etc/apt/sources.list.d/ubuntu.sources
実際の設定は /etc/apt/sources.list.d/ubuntu.sources にあるため、こちらを編集します。
バックアップを取る
設定ファイルを編集する前に、必ずバックアップを取っておきます。
bashsudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak
このコマンドは ubuntu.sources を ubuntu.sources.bak という名前でコピーするものです。
何か問題が起きたとき、このバックアップから元に戻せます。
設定ファイルを編集する
バックアップが取れたら、設定ファイルを開きます。
bashsudo nano /etc/apt/sources.list.d/ubuntu.sources
ファイルの中身はこのような形式になっています。
Types: deb
URIs: http://jp.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
URIs: の行が接続先のサーバーを指定している部分です。この行を以下のように変更します。
元の URIs: 行は行頭に # を付けてコメントアウトし、 JAIST ミラーの行を新しく追加します。
Types: deb
#URIs: http://jp.archive.ubuntu.com/ubuntu/
URIs: http://ftp.jaist.ac.jp/pub/Linux/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/
URIs: http://ftp.jaist.ac.jp/pub/Linux/ubuntu
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
# でコメントアウトして元の接続先を残しておくのがポイントです。
どこを変更したか一目でわかり、復旧後に元に戻す作業もシンプルになります。
編集が終わったら、 Ctrl+O → Enter で保存し、 Ctrl+X でエディタを終了します。
動作確認
設定を変更したら、以下のコマンドで動作を確認します。
bashsudo apt update sudo apt upgrade
エラーが消えて正常に動作すれば完了です。
復旧後の戻し方
Canonical のサーバーが復旧したら、設定を元に戻します。手順は今回の逆です。
bashsudo nano /etc/apt/sources.list.d/ubuntu.sources
ファイルを開いて、以下の2点を変更します。
- JAIST の
URIs:行の先頭に#を付けてコメントアウトする - 元の
#URIs:行の#を外す
保存後に sudo apt update を実行してエラーがなければ元通りです。
バックアップから一括で戻すこともできます。
bashsudo cp /etc/apt/sources.list.d/ubuntu.sources.bak /etc/apt/sources.list.d/ubuntu.sources sudo apt update
今後の対応：復旧状況の確認方法
Canonical の公式ステータスページで、各サービスの状態をリアルタイムで確認できます。
https://status.canonical.com
archive.ubuntu.com と security.ubuntu.com の状態が「 Operational 」（正常）になっていることを確認してから、設定を元に戻すのが安全です。
このページでは過去のインシデント履歴も確認できます。 今後も同様の障害が起きたときに、まずここを確認する習慣をつけておくと、原因の切り分けがスムーズになります。
また、 X（旧 Twitter ）で @ubuntu をフォローしておくと、 Canonical からの公式アナウンスをリアルタイムで受け取れます。
今回の攻撃でも、 X での告知が最初期の情報源のひとつになっていました。
まとめ
今回の障害は、自分のサーバーの問題ではなく、 Canonical への外部攻撃が原因でした。
サーバーを管理していると、「自分は何もしていないのに突然動かなくなる」ケースに遭遇することがあります。 そういうときこそ、まず外部サービスの障害情報を確認する習慣が大切だと改めて感じました。
対処法自体はシンプルでした。 設定ファイルをバックアップしてからコメントアウトで切り替えるやり方は、変更箇所が明確で、復旧後の作業も迷いません。 今後も同様の状況で応用できると思います。
