ゲームラグ白書 › 症状から探す
接続不可・無限ロード：原因45件と担当
別名：ログインできない、ロードが終わらない
図のあるメインページの症状辞典で開く →
ゲームに入れない、またはロード・入場画面で止まったままになります。
「サーバーに接続できません」の繰り返し、キャラクター選択後にロードバーが終わらない。
新しい接続を受け付ける場所（サーバーの接続待ちキュー、ファイアウォール、ログインサーバー、DB）が満杯になっています。メンテ明けに特に多く起きます。
この症状を引き起こす原因
L2 クライアントのOS・端末
- セキュリティソフトによるパケット検査: ウイルス対策ソフト・ファイアウォールがすべてのパケットを検査すると遅延が増え、行き過ぎるとゲームを攻撃と誤認してブロックします。 (外部・外部)
L3 家庭内ネットワーク
L4 インターネット回線
- 国・通信事業者単位のUDP制限・パケット検査: 一部のネットワークでは、特定のUDPアドレス・ポートをブロックしたりUDPの速度を制限したりし、パケット検査装置が識別できないプロトコルを遮断します。UDPで通信するゲームは、そのネットワークでは接続できなかったり、頻繁に切断されたりします。 (外部・外部)
- DNSの障害・遅延: サーバー名をアドレスに変換するDNSが遅かったり失敗したりすると、ログインサーバーやアップデートサーバーを見つけられません。 (外部・外部)
- DDoSによる共有回線の飽和: ゲーム会社や同じネットワーク内の別の宛先を狙った大量の攻撃が、共有回線を埋め尽くします。 (インフラチーム・ネットワークインフラ)
- 通信事業者の共有IP（CGNAT）: モバイル回線や一部の通信事業者では、複数の契約者が1つのIPを共有し、アイドル接続のマッピングを短時間で削除します。 (ゲーム開発チーム・クライアント開発)
- VPN・ラグ軽減ツール経由: VPNやラグ軽減ツールを使うと、パケットはその会社の中継サーバーを経由します。中継サーバーが遠かったり混雑していたりすると、かえって遅くなります。 (外部・外部)
L5 データセンターのネットワーク機器
- ファイアウォールのセッションテーブル飽和: ファイアウォールは、通過させたすべての接続をセッションテーブルに記録して追跡します。テーブルがいっぱいになると、新しい接続を受け付けられなくなります。 (インフラチーム・ネットワークインフラ)
- DDoS対策の経由・誤検知: 攻撃を防ぐためにトラフィックをスクラビングセンターに回すと経路が長くなり、正常なユーザーを攻撃と誤認してブロックすることもあります。 (インフラチーム・ネットワークインフラ)
- クラウドのNATゲートウェイの接続・ポート上限: プライベートサブネットのサーバーから外部（プラットフォーム認証・決済・外部API）への接続は、NATゲートウェイがアドレスとポートを変換して送り出します。同じ宛先への同時接続がゲートウェイのポート上限を超えると、新しい接続が失敗します。 (インフラチーム・ネットワークインフラ)
- ロードバランサーの偏り・ヘルスチェックの誤判定: 接続が1台のサーバーだけに集中したり、すでに落ちたサーバーに人を送り続けたりします。 (インフラチーム・ネットワークインフラ)
- MTUの不一致（大きなパケットだけ消える）: 途中の区間のMTU（一度に送れるサイズ）が小さくなっているのにサイズ超過の通知がブロックされると、大きなパケットだけが消え続けます。 (インフラチーム・ネットワークインフラ)
L7 サーバーOS（カーネル）
- 接続待ちキュー（backlog）のあふれ: メンテ明けに数万人が同時に接続すると、カーネルの接続待ちキュー（backlog）があふれ、接続要求が破棄されます。 (ゲーム開発チーム・サーバー開発)
- ファイルディスクリプタの上限: 接続ごとにファイルディスクリプタ（fd。OSが開いているファイルやソケットに付ける番号）が必要ですが、1つのプロセスが開けるfdの数には上限があります。 (インフラチーム・サーバーインフラ)
- サーバーのconntrackテーブル飽和: Linuxのファイアウォールがすべての接続を記録する接続追跡（conntrack）テーブルが上限に達すると、新しいパケットを破棄します。 (インフラチーム・サーバーインフラ)
- サーバー間接続のエフェメラルポート枯渇: ゲームサーバーがDBやほかのサーバーへの接続を短時間で頻繁に張っては切ると、切れた接続がしばらくポートを占有し、新しい接続を開けなくなります。 (ゲーム開発チーム・サーバー開発)
L8 ソケットとプロトコル
- keepaliveのデフォルト2時間: 相手が終了の合図なしに消えると、TCPはかなり時間がたってから検知します。keepalive（アイドル接続が生きているかを確認するTCPの機能）はデフォルトで無効で、有効にしても2時間アイドル状態が続かないと確認を始めません。 (ゲーム開発チーム・サーバー開発)
- SO_REUSEPORTの振り分けの偏り: 同じポートを複数のプロセスで分担して受け付けると、カーネルは接続ごとにアドレスのハッシュで担当プロセスを決め、その後は変更しません。担当プロセスが1つ止まると、そこに割り当てられた人だけが待たされます。 (ゲーム開発チーム・サーバー開発)
L9 サーバーのゲームプロセス
- スレッドプールの枯渇: 処理を担うワーカースレッドがすべて遅い処理に塞がれると、新しいリクエストはいつまでも待たされます。 (ゲーム開発チーム・サーバー開発)
L11 ディスク
- コアダンプの書き出し: サーバーが落ちるときに数GBのメモリをディスクに書き出すため、再起動が数分遅れることもあります。 (インフラチーム・サーバーインフラ)
L12 データベース
- インデックスのないクエリ: インデックスがないと、条件に合う行を探すためにテーブル全体を読む必要があります（フルスキャン）。 (ゲーム開発チーム・サーバー開発)
- コネクションプールの枯渇: DBとの接続数は決まっているため、遅いクエリが接続を占有すると、残りの要求は待たされます。 (ゲーム開発チーム・サーバー開発)
- コールドキャッシュ（再起動直後）: DBを再起動するとメモリ上のキャッシュが空になっているため、しばらくはすべての読み込みがディスクから行われます。 (インフラチーム・DBインフラ)
- ログイン殺到とN+1クエリ: キャラクター1体を読み込むたびに数十回の個別クエリを発行していると、数万人の同時ログインは数百万件のクエリになります。 (ゲーム開発チーム・サーバー開発)
- DBのフェイルオーバー: プライマリが落ちてスタンバイDBに切り替わる間は書き込みができず、レプリケーションが間に合わなかった最後のデータは失われることがあります。 (インフラチーム・DBインフラ)
- キャッシュスタンピード: 人気データのキャッシュが同時に期限切れになると、数千件の要求が一斉にDBへ殺到します。 (ゲーム開発チーム・サーバー開発)
- Redisの遅いコマンド: Redisはコマンドを1つずつ順番に処理するため、遅いコマンドが1つあると、その後ろのすべての要求が止まります。 (ゲーム開発チーム・サーバー開発)
- 実行計画の変化によるクエリ遅延: コードは変わっていないのに、DBが同じクエリの処理方法（実行計画）を変えると、昨日2msだったクエリが今日は数百msになります。 (インフラチーム・DBインフラ)
- サービス中のスキーマ変更（DDL）によるロック: サービス中にテーブルへカラムやインデックスを追加すると、一瞬だけ必要なロック1つのために、そのテーブルを使うすべての要求が待たされることがあります。 (インフラチーム・DBインフラ)
L13 サーバー構成と運用
- ゾーン移動（サーバー間の引き継ぎ）: 別のエリアやダンジョンに入るとき、キャラクター情報を別のサーバーへ引き渡す過程で遅延や失敗が起きます。 (ゲーム開発チーム・サーバー開発)
- カスケード障害: 1つのサービスが遅くなると、それを呼び出すサーバーが応答待ちで塞がり、関係のない機能まで止まります。 (ゲーム開発チーム・サーバー開発)
- 補助サーバーの障害: チャット・パーティ・オークションのように、ゲームサーバーとは別に動くサーバーで障害が起きると、その機能だけが動かなくなります。 (ゲーム開発チーム・サーバー開発)
- デプロイ・再起動: アップデートのためにサーバーを再起動するとき、接続を移さずに止めると、そのサーバーにいた人は切断され、終了直前の保存と再接続が一気に集中します。 (ゲーム開発チーム・サーバー開発)
- オートスケーリングの遅れ: 人が集中するとサーバーを自動で増やしますが、準備に数分かかり、その間は既存のサーバーが過負荷になります。 (インフラチーム・サーバーインフラ)
- 外部サービスへの依存: プラットフォームのログイン、決済、本人確認などの外部サービスが遅くなったり止まったりすると、その段階で先に進めなくなります。 (外部・外部)
- TLS証明書の期限切れ・設定ミス: ログイン・API・アップデートサーバーの証明書が期限切れになったり中間証明書が抜けていたりすると、その瞬間から新たに接続するクライアントのTLS接続が失敗します。 (インフラチーム・ネットワークインフラ)
- ログイン待機列の上限・再接続猶予の不足: リリース直後やメンテ明けに接続が集中すると、ログイン待機列が上限に達して新たな待機を拒否し、待っていたユーザーは一瞬切れた間に順番を失って最後尾に戻されます。 (ゲーム開発チーム・サーバー開発)
同期設計
一部のユーザーだけに起きる問題
- 特定キャラクターのデータ肥大化: アイテム・郵便が数千個たまっていたり、フレンド・ブロックリストやバフが極端に多かったりするキャラクターは、接続時・保存時・周囲への通知で扱う量がほかの人の数倍になります。回線に関係なく、そのキャラクターでだけ重くなります。 (ゲーム開発チーム・サーバー開発)
- 固定UDPポートの衝突: クライアントが決まったローカルポートを使うように作られていると、同じPCの2つ目のクライアントはそのポートを使えないか、1つ目とパケットを分け合って受け取ることになります。 (ゲーム開発チーム・クライアント開発)
- 多重起動の制限: セキュリティモジュールやサーバーのポリシーが1台のPCでの複数クライアントを制限していると、2つ目のクライアントは起動・接続ができないか、先に起動した側が切断されます。一部のゲームは追加のクライアントの機能だけを制限します。 (ゲーム開発チーム・クライアント開発)
TCP再送の根本原因
- ファイアウォール・接続追跡による破棄: ファイアウォールやLinuxの接続追跡（conntrack、通過する接続をテーブルに記録する機能）は、テーブルが満杯になったり、接続の状態が合わないと判断したりすると、パケットを破棄します。 (インフラチーム・ネットワークインフラ)
- MTUブラックホール（大きいパケットだけ繰り返し失われる）: 途中の区間が受け取れるサイズが小さくなったのに「大きすぎる」という通知（ICMP）が遮断されると、大きなパケットは何度送り直しても消え続けます。 (インフラチーム・ネットワークインフラ)
- 接続要求（SYN）の再送: 接続要求が接続待ちキュー（backlog）のあふれやファイアウォールの遮断で消えると、クライアントOSは1秒後から間隔を延ばしながら送り直します。 (ゲーム開発チーム・サーバー開発)
図のあるメインページの症状辞典を見る