NuGet V2フィードが404になる原因と解決策｜Visual StudioでV3フィードへ完全移行する手順

Visual Studio の NuGet パッケージマネージャーで「V2 フィードが 404」と表示され、パッケージの取得や復元が止まってしまう――。この現象は設定やネットワークだけでなく、NuGet の世代交代（V2→V3）に起因することが多いです。本記事では、最短の復旧手順から恒久対策、プロキシ環境や旧環境の落とし穴まで、実務でそのまま使えるノウハウを網羅的に解説します。

現象の概要と再現パターン

Visual Studio の NuGet パッケージマネージャーや復元処理（restore）で、次のようなエラーが出て取得に失敗します。

The V2 feed at 'https://www.nuget.org/…' returned an unexpected status code '404 Not Found'

UI での症状：パッケージの検索結果が表示されない／更新候補が空になる／インストールが進まない。
ビルド／CI での症状：dotnet restore や nuget restore が 404 を返し、依存関係の解決に失敗する。
間欠的発生：キャッシュが効いている時は成功し、クリア後に失敗する。

根本原因：NuGet の V2 から V3 への移行

NuGet は歴史的に V2（OData ベース）と V3（JSON/サービスインデックス）の二世代のフィードが存在します。現在は V3 が標準で、V2 は順次使えなくなっています。典型的な設定例は次の通りです。

世代	典型的な URL	現状
V2	`https://www.nuget.org/api/v2/`	非推奨・多くの環境で 404/エラー
V3	`https://api.nuget.org/v3/index.json`	推奨（既定）

Visual Studio の「パッケージソース」に古い V2 URL が残っていると、UI も復元も V2 にアクセスし、404 で失敗します。

最短の復旧：V3 フィードを登録して既定にする

Visual Studio での手順

[ツール] → [オプション] → [NuGet パッケージマネージャー] → [パッケージソース] を開く。
右上の [＋] でソースを追加。
名前：任意（例：nuget.org）
ソース：https://api.nuget.org/v3/index.json を入力し、[更新] または [OK]。
一覧で新しい V3 ソースにチェックを入れ、既定に設定する。
古い V2（…/api/v2/ など）があれば削除か 非アクティブ化 する。

nuget.config を直接編集する場合

ソリューションまたはユーザーの nuget.config から V2 を除去し、V3 を明示します。

&lt;configuration&gt;
  &lt;packageSources&gt;
    &lt;clear /&gt;
    &lt;add key="nuget.org" value="https://api.nuget.org/v3/index.json" /&gt;
  &lt;/packageSources&gt;
  &lt;activePackageSource&gt;
    &lt;add key="nuget.org" value="https://api.nuget.org/v3/index.json" /&gt;
  &lt;/activePackageSource&gt;
&lt;/configuration&gt;

「どの nuget.config が効いているか分からない」場合は、プロジェクト直下・ソリューション直下・ユーザー／マシン全体の順に優先されます。迷ったら CLI で現在のソースを一覧化しましょう。

CLI（NuGet.exe / dotnet）で置き換える

NuGet.exe を使う場合：

nuget.exe sources List
nuget.exe sources Remove -Name "nuget.org"  &amp;rem 既存がV2なら一旦削除
nuget.exe sources Add    -Name "nuget.org" -Source https://api.nuget.org/v3/index.json
nuget.exe locals all -clear  &amp;rem キャッシュクリア

dotnet CLI を使う場合：

dotnet nuget list source
dotnet nuget remove source nuget.org      &amp;rem 既存がV2なら削除
dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org
dotnet nuget locals all --clear
dotnet restore --no-cache --verbosity minimal

これで復元が通るか確認します。UI の検索結果が復活すれば切り替え成功です。

すでに V3 だが失敗する場合の総点検

「V3 を既定にしたのにまだ失敗する」ケースは、キャッシュ・ネットワーク・プロキシ・証明書などの外的要因がほとんどです。以下のチェックリストを上から順に潰すのが効率的です。

確認項目	コマンド／操作	期待される結果	失敗時の対処
有効なソースは V3 だけか	`dotnet nuget list source` または `nuget sources List`	`https://api.nuget.org/v3/index.json` のみ有効	無効な V2 を削除／無効化
キャッシュの影響を排除	`dotnet nuget locals all --clear` / `nuget locals all -clear`	復元が no-cache でも成功	キャッシュ破損ならクリア後に成功
プロキシ設定の整合	後述の「プロキシ環境」章	認証プロキシ越しで通信成功	nuget.config または環境変数で認証情報を設定
TLS 1.2 の使用	OS/ランタイム既定で 1.2 以上	ハンドシェイク成功	古い OS/ランタイムを更新（TLS 1.2 を有効化）
ファイアウォール	HTTPS 443 の外向き許可	`api.nuget.org` に到達	宛先許可リストに `api.nuget.org` を追加
企業ゲートウェイの改変	SSL インスペクション有無	改変なし	証明書配布／バイパス設定

ネットワーク健全性を PowerShell で素早く診断

# DNS 解決
Resolve-DnsName api.nuget.org

# 443 ポート到達性

Test-NetConnection api.nuget.org -Port 443

# HTTP ヘッダだけ確認（プロキシ経由なら自動設定に要注意）

Invoke-WebRequest [https://api.nuget.org/v3/index.json](https://api.nuget.org/v3/index.json) -Method Head -TimeoutSec 15

ここで 443 の到達が失敗する、もしくは Invoke-WebRequest がタイムアウト／認証要求になる場合は、プロキシやファイアウォール設定を最優先で見直します。

プロキシ・証明書環境でのベストプラクティス

nuget.config にプロキシを設定

認証つきプロキシでは、nuget.config（ユーザー単位が無難）に次のようなキーを追加できます。

&lt;configuration&gt;
  &lt;config&gt;
    &lt;add key="http_proxy" value="http://proxy.example.local:8080" /&gt;
    &lt;add key="http_proxy.user" value="DOMAIN\username" /&gt;
    &lt;add key="http_proxy.password" value="&lt;暗号化済みまたは空&gt;" /&gt;
  &lt;/config&gt;
&lt;/configuration&gt;

CLI から nuget.exe sources Add（または dotnet nuget add source）で資格情報を登録すると、Windows では DPAPI により暗号化保存されます。やむを得ずプレーン保存する場合のスイッチ（-StorePasswordInClearText / --store-password-in-clear-text）は、ポリシーに従い最小限の範囲に限定してください。

TLS と証明書の落とし穴

古い OS/フレームワークでは既定の TLS が 1.0/1.1 のことがあります。パッチ適用で 1.2 を既定化してください。
SSL インスペクションを行うプロキシでは、社内 CA のルート証明書を開発端末とビルドサーバーに配布する必要があります。
自己署名リバースプロキシをかませると、certificate verify failed で失敗します。可能ならば api.nuget.org をバイパス対象に。

packages.config プロジェクトでも V3 を使える

プロジェクト形式（PackageReference / packages.config）とフィードの世代（V2/V3）は独立しています。URL を V3 に切り替えるだけで、packages.config のプロジェクトでも問題なく動作します。復元は次のいずれかで実行します。

# ソリューションルートで
nuget.exe restore MySolution.sln

# または

dotnet restore MySolution.sln

「V2 を使っている私設フィードがある」場合の運用

社内 NuGet サーバーや古いリポジトリ製品で V2 しかない場合、次の指針が安全です。

nuget.org（V3）を既定にし、私設 V2 は必要な時だけ有効化する。
パッケージ解決順はソースの順番に影響を受けます。社内パッケージが優先なら順序を上げ、同名衝突を避ける命名規約を決める。
将来的には V3 対応のリポジトリ（例：プロキシ・キャッシュ型）へ移行し、外部への帯域やレイテンシも改善する。

よくある誤設定と見逃しポイント

URL のタイプミス：https://nuget.org や http:// 始まりを指定している。必ず https://api.nuget.org/v3/index.json を使用。
重複ソース：名前違いで nuget.org が複数登録され、V2 が先に解決されている。
ソリューション内の nuget.config：ユーザーの設定を上書きする形で V2 が残っている。
古い拡張機能：旧版の NuGet VS 拡張（Visual Studio 2013 以前）は V3 に非対応。復元は CLI または VS をアップグレード。
キャッシュ破損：ローカルキャッシュに壊れたメタデータが残る。locals all --clear で解消。

パフォーマンスと信頼性も改善される V3 への移行効果

V3 はサービスインデックスを起点とした分割エンドポイント構成で、メタデータとコンテンツ配信を最適化しています。結果として、次の実益があります。

高速化：必要な JSON を必要なタイミングで取得。検索や復元が軽量。
CDN 最適化：地理的に近いエッジから配信されやすく、CI/CD でも安定。
堅牢性：V2 の単一エンドポイント依存からの脱却により可用性が向上。

コマンド例：状況別クイックレシピ集

「今すぐ復旧したい」

nuget.exe sources Remove -Name "nuget.org"
nuget.exe sources Add -Name "nuget.org" -Source https://api.nuget.org/v3/index.json
nuget.exe locals all -clear
nuget.exe restore MySolution.sln

「ソリューション内の V2 を一掃したい」

# PowerShell：ソリューション配下の nuget.config から V2 を置換
Get-ChildItem -Recurse -Filter nuget.config | ForEach-Object {
  (Get-Content $_.FullName) `
    -replace 'https?://(www\.)?nuget\.org/api/v2/?', 'https://api.nuget.org/v3/index.json' `
    | Set-Content $_.FullName
}

「CI/CD の安定性を上げたい」

# CI の最初でキャッシュ/ソースを明示
dotnet nuget remove source nuget.org || true
dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org
dotnet nuget list source
dotnet restore --no-cache --verbosity minimal

nuget.config の配置と優先順位

NuGet は複数の nuget.config をマージして使います。どれが効いているか把握するのが重要です。

レベル	配置場所の例（Windows）	用途	備考
プロジェクト	プロジェクトフォルダー直下	そのプロジェクト限定のソース/設定	最優先。チーム共有しやすい
ソリューション	ソリューション直下	同一ソリューション共通	プロジェクトより下位
ユーザー	`%AppData%\NuGet\NuGet.Config`	端末ユーザー全体	個人の開発環境向け
マシン全体	`%ProgramFiles(x86)%\NuGet\Config\` / `%ProgramData%\NuGet\Config\`	端末全体の既定値	VS のオフラインソースなどが入ることあり

優先度は上から順。上位で <clear /> を使うと下位の定義を打ち消せます。

ログの見方：原因切り分けを早くする

復元に失敗した際は、まず詳細ログを出します。

dotnet restore --verbosity detailed
nuget.exe restore -Verbosity detailed
Visual Studio：[表示] → [出力] で「NuGet」を選択

V2 URL にアクセスしている記録があれば、設定の置き換えが未完了です。401/407（認証エラー） や Proxy Authentication Required が見えたらプロキシ設定を優先して修正します。

ケーススタディ：現場で遭遇した 5 つの落とし穴

ソリューション内にだけ V2 が残っていた
ユーザーの nuget.config は V3 だが、リポジトリに含まれる nuget.config に V2 が記載されており、CI でだけ失敗。→ ソリューションの設定を更新して解決。
プロキシ認証の更新切れ
パスワード変更後に DPAPI 保存された資格情報が無効化。→ nuget sources Update（または削除→再追加）で再保存。
証明書の透過型検査
SSL インスペクションが JSON の content-md5 検証を壊し復元失敗。→ api.nuget.org を検査対象外に。
古いランタイム
旧サーバーの .NET Framework で TLS 1.2 が既定外。→ OS 更新またはレジストリ設定で 1.2 を既定化し復旧。
オフラインソースが最優先
Visual Studio のオフラインパッケージが先に解決され、古いバージョンに固定。→ ソース順序を見直し、オフラインは必要時のみ有効化。

チームと CI のための再発防止チェックリスト

リポジトリ直下に 意図した nuget.config を置き、https://api.nuget.org/v3/index.json を唯一の外部ソースにする。
ビルド前に ソースの明示とキャッシュクリア を行う（上記 CI レシピ参照）。
プロキシ／証明書ポリシーを コード化（構成管理） し、環境差異を最小化。
旧版 Visual Studio を段階的に更新。どうしても残す場合は CLI での復元 を標準化。

トラブルと無縁になるための小技

ソース名を固定：「nuget.org」で統一し、重複や紛らわしい別名を避ける。
パッケージ参照の最新形式：可能なら PackageReference に移行。復元の安定性と速度が向上。
キャッシュの健全運用：CI では「成功後のキャッシュ保存」を徹底（壊れたキャッシュを配らない）。
ソース順序の明文化：社内ソースと外部ソースが混在する場合、順序ルールを README に明記。

まとめ：V3 への一本化が最も効果的な恒久対策

「V2 フィードが 404」の多くは、古い URL がどこかに残っていることが直接原因です。Visual Studio／nuget.config／CLI のいずれからでも構わないので、nuget.org を V3（https://api.nuget.org/v3/index.json）に統一し、キャッシュとネットワーク設定を合わせて点検すれば、ほとんどの環境で即時に復旧できます。プロキシや証明書、旧ツールチェーンなどの周辺要因も本記事のチェックリストに沿って整理すれば、再発を防止しながら安定した復元と配布が実現できます。

付録：代表的なエラーメッセージと対応早見表

メッセージ抜粋	原因の目安	一次対応	恒久対応
`V2 feed … 404 Not Found`	V2 URL を参照	V3 へ切替	nuget.config を共通化
`Proxy Authentication Required (407)`	プロキシ認証未設定	nuget.config に認証情報	SSO/資格情報管理で統一
`SSL/TLS secure channel`	TLS 1.2 未使用	OS/ランタイム更新	ポリシーで 1.2 既定化
`certificate verify failed`	証明書改変/検査	社内 CA 配布	検査バイパスの明文化
`Package not found`	ソース順序/権限	順序見直し	社内ソースの権限整備

付録：手動での URL 置換テンプレート

V2 から V3 への置換に使える正規表現（PowerShell / .NET の -replace 相当）の例です。

# 'http(s)://(www.)?nuget.org/api/v2[/…]' を V3 に置換
'https?://(www\.)?nuget\.org/api/v2/?' → 'https://api.nuget.org/v3/index.json'

最後に

V3 への切り替えは「いま直すべき不具合の修正」であると同時に、将来の停止を未然に防ぐ「品質改善」です。ソースを一本化し、ログ・ネットワーク・プロキシ・証明書・キャッシュの基本動作をチームで共有しておけば、NuGet 周りの事故は劇的に減らせます。本記事の手順をひな形として、あなたの環境に最適化して運用に組み込んでください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

NuGet V2フィードが404になる原因と解決策｜Visual StudioでV3フィードへ完全移行する手順

現象の概要と再現パターン

根本原因：NuGet の V2 から V3 への移行

最短の復旧：V3 フィードを登録して既定にする

Visual Studio での手順

nuget.config を直接編集する場合

CLI（NuGet.exe / dotnet）で置き換える

すでに V3 だが失敗する場合の総点検

ネットワーク健全性を PowerShell で素早く診断

プロキシ・証明書環境でのベストプラクティス

nuget.config にプロキシを設定

TLS と証明書の落とし穴

packages.config プロジェクトでも V3 を使える

「V2 を使っている私設フィードがある」場合の運用

よくある誤設定と見逃しポイント

パフォーマンスと信頼性も改善される V3 への移行効果

コマンド例：状況別クイックレシピ集

「今すぐ復旧したい」

「ソリューション内の V2 を一掃したい」

「CI/CD の安定性を上げたい」

nuget.config の配置と優先順位

ログの見方：原因切り分けを早くする

ケーススタディ：現場で遭遇した 5 つの落とし穴

チームと CI のための再発防止チェックリスト

トラブルと無縁になるための小技

まとめ：V3 への一本化が最も効果的な恒久対策

付録：代表的なエラーメッセージと対応早見表

付録：手動での URL 置換テンプレート

最後に

この記事を書いた人

コメント

コメントするコメントをキャンセル

NuGet V2フィードが404になる原因と解決策｜Visual StudioでV3フィードへ完全移行する手順

現象の概要と再現パターン

根本原因：NuGet の V2 から V3 への移行

最短の復旧：V3 フィードを登録して既定にする

Visual Studio での手順

nuget.config を直接編集する場合

CLI（NuGet.exe / dotnet）で置き換える

すでに V3 だが失敗する場合の総点検

ネットワーク健全性を PowerShell で素早く診断

プロキシ・証明書環境でのベストプラクティス

nuget.config にプロキシを設定

TLS と証明書の落とし穴

packages.config プロジェクトでも V3 を使える

「V2 を使っている私設フィードがある」場合の運用

よくある誤設定と見逃しポイント

パフォーマンスと信頼性も改善される V3 への移行効果

コマンド例：状況別クイックレシピ集

「今すぐ復旧したい」

「ソリューション内の V2 を一掃したい」

「CI/CD の安定性を上げたい」

nuget.config の配置と優先順位

ログの見方：原因切り分けを早くする

ケーススタディ：現場で遭遇した 5 つの落とし穴

チームと CI のための再発防止チェックリスト

トラブルと無縁になるための小技

まとめ：V3 への一本化が最も効果的な恒久対策

付録：代表的なエラーメッセージと対応早見表

付録：手動での URL 置換テンプレート

最後に

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル