Steamのサインインは通る、ゲームは通らない：各経路を確認する

Steamのサインイン、ダウンロード、マッチメイキングのセッションは別々の経路を通ることがあります。チェックリストを順にたどり、実際に失敗した手順を記録してください。

Steamを起動してサインインし、ゲームがセッションを見つけられないまではすべて正常に見えます。これは一つではなく三つの別々のネットワーク問題として扱ってください。ストアとアカウントの画面、コンテンツのダウンロード、ゲームのセッションは、それぞれ異なるトランスポートで異なるエンドポイントに到達します。これらの確認を順に行い、最初に失敗した時点で止めてください、その後のすべては推測だからです。

ステップ1：機能したのがサインインだけであることを確認する

サインインは、アカウントが資格情報とアカウントの要求する第二要素を伴って ID サービスに到達したことを証明します。コンテンツ配信については何も語らず、ゲーム自身のホスティング構成についても何も語りません。三つの操作のうち実際に試したものを書き留めてください、人はランチャーだけを試してゲームの不具合を報告しがちだからです。

ネットワークより先に失敗の文言を読んでください。利用可能なサーバーがないと報告するゲームは、ストアに到達できないランチャーとは別のことを伝えています。二つのエラーは異なる層から出ており、同じ意味になることはほとんどありません。この区別が、次の確認が名前解決・UDP・地域設定のどれに関するものかを決めます。

アカウント、地域、ゲーム、時刻を記録してください。この四つの値がなければ、後での比較はたまたま同じ名前を共有する二つの異なるテストの間の比較になります。

ステップ2：各操作のトランスポートを特定する

コンテンツ配信は大きな HTTP 転送のように振る舞い、遅延には損失よりもはるかに耐えます。マッチメイキングやゲーム内セッションはしばしば UDP を使い、そこではパケットを落とす経路が低速なダウンロードではなく壊れたゲームのように見えます。この二つの性質は同じトンネル上で異なる失敗の仕方をし、だからこそ速いダウンロードは正常なセッションを予測しません。

まずベンダーのポート一覧ではなく、宛先と稼働中のソケットを確認してください。一覧はプラットフォームが使えるものを示し、ソケットはこのクライアントが今何をしているかを示します。

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

転送経路が正常なのにゲームのプロセスが通信のある UDP ソケットを保持しているなら、失敗は UDP 側にあります。これで問題はアカウントやストアではなく、トンネルの UDP の扱いに絞られます。

ステップ3：ポート一覧より先に包含ポリシーを確認する

多くの VPN クライアントはポリシーをマシン全体ではなく、アプリケーション単位、アドレス範囲単位、アドレスファミリー単位で適用します。ランチャーがトンネル内にある一方、別に起動したゲームのバイナリが外にあると、両者は世界について一致しません。アプリ単位の包含は、ベンダーのクライアントが入ったゲーミングノートでよくある原因です。先月保存したプロファイルではなく、実際に有効なポリシーを読んでください。

ルーティングテーブルとデフォルトルートを持つインターフェースを見てください。宛先プレフィックスに基づく分割トンネルの規則はそこに現れますが、アプリ単位の除外は現れません。どちらかを変更する前に、この違いを知っておく価値があります。

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

ゲームの通信が物理アダプターから出ているのにストアがトンネルを通っているなら、包含ポリシーが原因です。ポートの例外はルーティングの判断を直せませんし、一つ追加しても対象が広がるだけです。

ステップ4：UDP を運べない SOCKS 経路を除外する

Tor は SOCKS プロキシを提供しますが、エコシステム全体の SOCKS 対応は UDP について一貫していません。Tor の文書化された動作は UDP ASSOCIATE を実装していないため、セッションの通信が UDP のゲームは、クライアントをどう向けてもその経路を使えません。プロキシ経由で動くブラウザーは、ブラウザーの TCP フローが動くことしか証明しません。

意図ではなく主張を試してください。同じプロキシ経由の TCP のみのテストが成功してもゲームが利用できないセッションを報告するなら、プロキシ経路はゲームに必要な通信を運んでいません。

ルーティングされた VPN と SOCKS プロキシを、能力の異なる別の道具として扱ってください。片方を他方に替えるのは構成の好みではなく設計の変更です。

記録を契約と照らし合わせる

ネットワークへの到達性とアカウントの許可は別の問題であり、動くトンネルが答えるのは前者だけです。制限は選んだプロトコルではなく、プロキシの背後にある意図に関するものです。有効な契約は、アカウント所有者の居住地を偽装する目的の IP プロキシを制限しているため、動く経路でも受け入れた条件の外にあることがあります。接続性を承認とみなさず、契約を読んでください。

公正な比較のために、一度に一つの変数だけを変え、同じゲーム、サーバー地域、アカウント、操作を保ってください。そのうえで、最初に記録した同じ四つの操作で結果を確認します。

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

記録がサインインは動き、ダウンロードも動き、セッションが失敗していると示すなら、残る問いは経路上の UDP です。三つとも動くなら、元の不満は別のことにあり、次に役立つのはトンネルではなくゲーム自身のログです。いずれにせよ、チェックリストは議論を具体的な観察に置き換えました。

関連記事