VivaldiがWindowsで起動激遅になる原因はTCPソケットエラー10013かも：ログから分かる対処チェックリスト

Windows環境でVivaldiの起動が毎回15〜30秒固まり、UIが反応するまで待たされる――その症状、拡張機能やGPUよりも「起動直後のネットワーク初期化でTCP接続が弾かれてタイムアウト待ちになる」パターンが濃厚です。ログに tcp_socket_win.cc の connect failed: 10013 (WSAEACCES) が出る場合、原因はブラウザというよりWindows側のフィルタ／ポート予約／セキュリティ製品の影響であることが多いです。Vivaldi Forum+1

• VivaldiがWindowsで起動激遅になる原因はTCPソケットエラー10013かも：ログから分かる対処チェックリスト
  • 症状の核心：起動直後に「connect failed: 10013」が連発して待たされる
  • エラー10013（WSAEACCES）とは何か：要するに「ソケット操作が許可されていない」
  • 「DEPRECATED_ENDPOINT」は今回の主犯ではないことが多い
  • ここからが本番：Windows側の原因を潰すチェックリスト（効果が出やすい順）
    • 1) セキュリティ製品・VPN・通信監視の“フィルタ”を疑う
    • 2) Windowsファイアウォールのルールを作り直す（または初期化して再許可）
    • 3) Winsock／ネットワークスタックのリセットで“差し込み系”を外す
    • 4) “除外（予約）ポート”に引っかかっていないか確認する
    • 5) 「速いプロファイルがある」なら、最短の回避策はプロファイル再生成
  • まとめ：この症状は「ブラウザの不具合」より「Windowsのフィルタ／ポート／スタック」の問題になりやすい

症状の核心：起動直後に「connect failed: 10013」が連発して待たされる

起動時の詳細ログで早い段階（GCM登録などより前）にTCP接続が失敗し、OSが WSAEACCES（許可されていないアクセス）を返すと、Chromium系は接続の再試行やタイムアウト待ちに入りやすく、結果として「UIが固まって見える」時間が伸びます。フォーラム報告でも、まっさらな一時プロファイル（あるいは別ユーザー）だと速い、という切り分けが出ており、Windows側の設定・フィルタとの相性を疑う根拠になります。Vivaldi Forum

エラー10013（WSAEACCES）とは何か：要するに「ソケット操作が許可されていない」

WSAEACCES (10013) はWindowsソケットの「Permission denied」です。典型例として、アクセス権限的に禁止されたソケット操作、または別のアプリ／サービス／カーネルドライバが同じアドレスを排他的に掴んでいるケースが挙げられています。つまり「ブラウザが悪い」というより、間に挟まっている何か（防御・監視・仮想NIC・フィルタドライバ等）がブロックしている構図が多いです。Beckhoff Information System

「DEPRECATED_ENDPOINT」は今回の主犯ではないことが多い

ログに registration_request.cc の DEPRECATED_ENDPOINT が出ても、これはGCM系の古い経路で見える“サーバ側の応答エラー”として広く観測されています（SeleniumやCEFでも報告あり）。表示自体はうるさいものの、即時に返ってくることが多く、「起動が15〜30秒止まる」原因になりにくい、という整理が妥当です。Google Groups+2Stack Overflow+2

ここからが本番：Windows側の原因を潰すチェックリスト（効果が出やすい順）

1) セキュリティ製品・VPN・通信監視の“フィルタ”を疑う

10013は、サードパーティ製のファイアウォール／アンチウイルス／Internet Securityが原因になりやすい、という指摘が定番です。まずは一時的に停止して挙動が変わるか確認し、原因が特定できたら例外（許可ルール）を作るのが現実的です。Super User

見るべきポイント

• Vivaldi本体（vivaldi.exe）だけでなく、同梱の更新・補助プロセスもブロックされ得る

• VPNクライアントや広告ブロッカー系（DNS/HTTPSフィルタ）を入れていると、起動直後の接続が弾かれやすい

• 「別Windowsユーザーだと速い」なら、ユーザー単位のセキュリティ設定・ルール差分が濃厚

2) Windowsファイアウォールのルールを作り直す（または初期化して再許可）

Windows標準のファイアウォールでも、アプリ許可が壊れていたり、過去の残骸ルールで弾かれることがあります。再許可のために、いったんルールを初期化するのも手です（企業PCでは管理ポリシーに注意）。

その後、起動時に表示される許可ダイアログ（または設定）で再度許可します。

3) Winsock／ネットワークスタックのリセットで“差し込み系”を外す

Winsockカタログの破損や、過去に入れたネットワーク系ソフトの残骸が悪さをすることがあります。まずは定番のリセットを実施します。

再起動後に改善するケースがあります（効果がない場合もありますが、切り分け価値が高いです）。

4) “除外（予約）ポート”に引っかかっていないか確認する

意外な盲点が、Windowsの**excluded port range（除外ポート範囲）**です。Microsoftの資料では、除外したTCPポートへ再バインドしようとすると WSAEACCES (10013) になる条件が説明されています。仮想化・コンテナ・一部VPNなどがポート予約を作ることもあります。Microsoft Learn

確認コマンド例（管理者で実行）：

もし除外範囲が異常に広い／動的ポート範囲と衝突していそうなら、原因になっている機能（Hyper-V/WSL/コンテナ/VPN等）の見直しや、管理者ポリシーの確認が必要です。

5) 「速いプロファイルがある」なら、最短の回避策はプロファイル再生成

すでに「一時プロファイル（新規ユーザーデータ）だと速い」なら、完全に新しいユーザーデータで運用するのが最速の回避策です。原因がWindows側でも、プロファイル側のネットワーク関連キャッシュや拡張の残骸が引き金になっていることがあるためです。
ただし、今回のように“起動直後のTCP失敗”が核心だと、根本解決は上の1〜4が重要です。Vivaldi Forum

まとめ：この症状は「ブラウザの不具合」より「Windowsのフィルタ／ポート／スタック」の問題になりやすい

• connect failed: 10013 (WSAEACCES) は「ソケット操作が許可されない」状態で、フィルタや排他バインドが典型原因。Beckhoff Information System

• 起動が固まるのは、早期ネットワーク初期化で失敗→タイムアウト待ちが積み重なる構図になりやすい。Vivaldi Forum

• DEPRECATED_ENDPOINT は別件のノイズであることが多い。Stack Overflow+1

最優先の実行順は「セキュリティ/VPNの停止テスト → ファイアウォール再許可 → winsock/ip reset → 除外ポート確認」。ここまでで改善しない場合、怪しいネットワークドライバ（VPN・EDR・仮想NIC）を“入れ直す/外す”のが次の一手になります。