PicoTowa Lab
2026-10-07 · failures

Quest 3は届いた。でもSteam Linkが繋がるまで約1週間かかった

Quest 3購入後、専用AP・Subnet・Tailscale・Windows NICを切り分け、単純な同一L2構成へ収束させた記録。

Meta Quest 3を買った。

PCは有線。Questは6GHz。専用APも用意した。

「これならPCVRはすぐ終わる」と思っていた。

実際には、Steam Linkがまともに通る構成へ持っていくまで、数日間ちまちまとネットワークを切り分けることになった。

途中ではQuestとPCを同じIP帯へ置き、相互pingまで通った。それでもSteam Linkは「接続中」のまま進まない。

最終的に残した構成はかなり普通だった。

Internet
   |
AXE5400
Router / DHCP / NAT
192.168.10.1
   |
L2 Switch
   |-- Windows PC
   |     Ethernet
   |     192.168.10.x
   |
   `-- AXE5400V
         AP Mode
         192.168.10.2
            |
            `-- Quest 3
                 6GHz
                 192.168.10.x

結局、一番効いたのは高価な機材ではなく、ネットワークを単純にすることだった。

最初は「Quest専用ルーター」を作ろうとしていた

Quest 3を買ったのは2026年9月22日。翌日には、PCVR用に6GHzをQuestへほぼ専有させる構成を考え始めた。

狙いは単純だった。

  • PCは有線
  • Questだけ高速な無線
  • 他端末との干渉をできるだけ減らす

問題は、Quest用の機器を「ルーター」として考えていたことだった。

ルーターモードで動かせば、その機器自身がDHCPやNATを持ち、メインLANとは別のIPネットワークを作ることがある。

今回欲しかったのは別のLANではなく、既存LANへ6GHzの無線だけを追加することだった。

つまり必要だったのは、Quest専用「ルーター」よりQuest専用「AP」だった。

L2スイッチを挟めば同じネットワークになる、ではなかった

途中ではQuest側が 100.64.1.x、PCのEthernet側が 192.168.0.x という状態にもなっていた。

物理的にはつながっている。でも論理的には別ネットワークだった。

L2スイッチはEthernetフレームを転送する。IPサブネットを作るのはルーター側だ。

この段階ではSteam Link以前に、構成そのものを整理する必要があった。

PCとQuestを同じ100.64.1.xへ揃えた。pingも通った

そこでPCとQuestを同じIP帯へ置いた。

当時の一例では、

  • PC: 100.64.1.46
  • Quest: 100.64.1.42

まで揃えて、相互pingも成功した。

ここで一度「これで直っただろう」と思った。

直らなかった。

Steam Linkはまだ接続できない。

ここで、pingが通ることとPCVRストリーミングが成立することは別だと実感した。

pingで確認できるのはIPレベルで通信できることの一部。その上には、アプリケーション側の探索、使用するNIC、Firewall、Socketのbind先、ルーティング、Steam側の状態がある。

「ping成功」はゴールではなく、スタート地点だった。

100.64.xとTailscaleを同居させていた

さらに構成をややこしくしていたのが 100.64.x だった。

100.64.0.0/10 はShared Address Spaceとして使われる範囲で、Tailscaleも同系統のアドレス空間を利用する。

当時のPCでは、

  • 家庭内LANも100.x系
  • Tailscaleも100.x系

という、障害解析にはあまり嬉しくない状態を作っていた。

これがSteam Link不調の唯一の原因だった、とまでは言えない。実際、Tailscaleを止めただけでは即座に解消しなかった。

ただ、Steam関連の待受を確認したとき、物理LANだけでなくTailscale系Interface側にもSocketがbindされている状態があり、「いま、どの経路を見ているのか」が分かりづらくなっていた。

最終的には家庭内LANを 192.168.10.0/24 へ戻した。

Windows側も一つずつ疑った

確認したものは、

  • Steam / SteamVR process
  • UDP / TCPの待受
  • Windows Firewall
  • Public / Private Network Profile
  • Tailscale停止
  • NIC
  • Gateway / Route

途中ではEthernetがPublic扱いになっていたのでPrivateへ変更した。ただし、これだけで直ったわけではない。

このあたりは「原因」ではなく「切り分け項目」の一つとして残している。

最終的には普通の構成へ戻った

AXE5400だけをRouterとして残し、DHCPもNATもここだけにした。

AXE5400VはAP Mode。6GHzの無線を既存LANへBridgeするだけ。

PCはL2スイッチへ有線。Quest 3はAXE5400Vの6GHz専用SSIDへ接続。全部 192.168.10.x。

この形まで単純化して、ようやくPCVR側をまともに詰められる状態になった。

2.5GbEより先に見るものがあった

今回優先したのは、

  1. PCを有線にする
  2. Questだけを6GHzへ載せる
  3. Quest用機器をAP Modeにする
  4. DHCP / NATを一箇所にする
  5. PCとQuestを同一LANへ置く
  6. APを近距離・低干渉にする
  7. Overlay VPNなど切り分けを邪魔する経路を一旦外す

という順番だった。

少なくとも今回、自分を止めていたボトルネックは「1GbEだから遅い」ではなかった。

一番学んだのは「原因を一個にしない」ことだった

この件をあとから整理しても、綺麗な一個のRoot Causeは出せない。

  • 別Subnetだった時期がある
  • 100.64.xとTailscaleを同居させていた
  • WindowsのNetwork Profileも触った
  • SteamのSocketも複数Interfaceへbindしていた
  • RouterとAPの役割も途中で変えた

どれか一つを犯人にすれば記事は分かりやすくなる。

でも事実としては、複数の曖昧な要因を一つずつ外し、最終的に「普通のPrivate LAN」「Routerは一台」「Quest側はAP」「PCは有線」「Questだけ6GHz」へ収束させた、というのが一番正確だと思う。

VR本体は届いているのに、数日間やっていることはPowerShellとルーター設定。

まあまあ虚無だった。

ただ、このおかげでL2とL3、RouterとAP、DHCPとNAT、Overlay Network、NIC、Application Discoveryが、教科書の用語ではなく実際の故障点として繋がった。

PicoTowaでは、完成したものだけではなく、完成までに踏んだ穴も残していく。

参考