房間
「房間」（Instances），是指某個世界（Worlds）的各個獨立分流。用戶可以建立並加入某個世界的房間，進入同一個房間的用戶可以在同個世界中看見彼此並互動，但無法與同世界、其他房間的用戶直接互動。
每個房間本身可以設定其特定的屬性，用來控制誰可以加入、誰能發送邀請，或誰可以查看房間內有哪些人。此外，房間會需要指定所在的伺服器地區（Region），這個地區將對應至實際的伺服器位置，其負責處理房間中用戶之間的連線資訊傳遞。
房間類型
VRChat 中有各式各樣公開與私人環境可供探索，涵蓋多種主題。用戶也可以加入或建立各種社群團體，與有共同興趣的其他用戶互動交流。用戶可以選擇加入公開房間，或建立私人房間自己獨處，或在加為好友後邀請朋友加入。
房間的隱私層級由用戶自行決定，並依照下列不同的等級區分：
| 公開 Public |
此類型的房間會公開陳列給任何人，並能夠讓任何人自由加入的房間。 |
|---|---|
| 好友 + Friends+ |
此類型的房間能讓你的好友以及他們的好友加入。 |
| 好友 Friends |
或稱「僅限好友」。此類型的房間只有你的好友能夠加入。 |
| 邀請 + Invite+ |
此類型的房間要求任何用戶及用戶的好友必須先申請加入，並經通過後才能進入房間。除非你或已受邀加入的用戶之社交狀態，被設定成「加入我」（Join me）。 |
| 邀請 Invite |
或稱「僅限邀請」。此類型的房間要求任何用戶必須先申請加入，並經通過後才能進入房間。除非你的社交狀態設定成「加入我」（Join me）；已受邀加入的用戶好友，無法在沒有你好友的狀況下申請。 |
| 群組 Group |
或稱「僅限群組」。此類型的房間由群組建立，僅允許群組成員或具有群組內特定身分組進入。 |
| 群組 + Group+ |
此類型的房間由群組建立，允許群組成員的好友、他們的好友加入。該房間可指派群組管理員來管理房間，且加入此房間不需要是該群組的成員。 |
| 群組公開 Group Public |
此類型的房間由群組建立並公開列出，任何人都可以加入。該房間可指派群組管理員來管理房間。 |
| 任何人 | 房間擁有者 好友的好友 |
受邀請的 房間擁有者 好友的好友 |
房間擁有者 好友 |
受邀請的 房間擁有者 好友 |
指定 身分組的 群組成員 |
所有的 群組成員 | |
|---|---|---|---|---|---|---|---|
| 公開 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | - | - |
| 好友 + | - | ||||||
| 好友 | - | - | |||||
| 邀請 + | ✔️[note 1] | - | |||||
| 邀請 | - | ||||||
| 群組 | - | ✔️[note 2] | |||||
| 群組 + | ✔️ | ✔️ | - | ✔️ | |||
| 群組公開 | ✔️ | ||||||
公開房間
公開房間是最容易加入的房間類型，共分成「公開」及「群組公開」兩種類型。[1]
私人房間
私人房間需要透過邀請或其他進入方式才能加入，共分成「好友」、「好友+」、「邀請」、「邀請+」、「群組」以及「群組+」六種類型。[1]
群組房間
群組房間是由群組建立的房間，共分成「群組公開」、「群組+」及「群組」三種類型。
年齡限制房間
詳細資訊請參考年齡驗證的條目。
群組中擁有「建立年齡限制房間」（Create Age Gated Instances）權限的成員，可為任意群組房間設定 18+ 年齡驗證限制，限制只有已完成 18 歲以上年齡驗證的用戶才能加入。
當用戶已完成年齡驗證時，年齡限制房間將會被優先顯示在房間列表的頂部。
（即便管理員或是群主具備超額加入權限，仍不允許未完成年齡驗證的用戶加入房間）
指南
房間可在設定中啟用排隊機制。當房間人數超過容量時，便會開啟排隊功能，並以獨立圖示顯示目前排隊人數。「加入」（Join）按鈕也會變更為「開始排隊」（Join Queue）。具備群組優先排隊權限的用戶將被安排至排隊隊伍最前方（但會排在已具有相同權限的用戶之後）；其他用戶則會加入至隊伍最尾端。群主則可直接繞過排隊限制，直接加入房間。
如果用戶的另一個客戶端已經在房間內，則可以直接連線至該房間。新的客戶端在進入時會將舊的客戶端踢出，使你能在 VR 與 PC 模式之間切換，而不會失去在已滿房間中的位置。
角色效能限制
群組房間可選擇設定角色最低效能等級門檻限制。此限制只能在建立房間時進行設定，並會套用至房間內所有用戶。最低效能限制可設定為「Poor」（糟）、「Medium」（普通）或「Good」（佳）等級的角色，而預設則為「無」。
當最低效能限制生效時，牴觸效能門檻的用戶角色將受到以下限制：
- 嘗試加入房間時，系統會通知用戶其角色未符合效能限制要求。系統將顯示警告視窗，說明目前角色的效能等級、房間的效能限制，以及其他用戶將如何看見其角色。
- 在房間內，其他用戶將會看到該角色的後備角色（Fallbacks）或投影替身（Impostors）；但對於該用戶自己而言，客戶端仍會顯示其原本的角色。
群組可設定特定身分組，使其可略過角色效能門檻限制。
地區
在選擇房間類型時，用戶可以透過選擇不同的地區，最佳化你的遊戲體驗。選擇距離你現實中所在地最近的房間地區，可以有效降低延遲（Ping）數值，並確保與該房間之間有更穩定的連線品質，避免斷線和過高延遲的發生。
綜觀 VRChat 歷史，起初所有房間僅在位於美國西部地區的一台伺服器上運行。直到 2021 年 6 月 16 日，官方在「地區更新」（Regions update）[2]中新增了兩台伺服器，其分別位於「歐洲」（Europe）與「日本」（Japan）地區。同年 12 月 1 日，官方又在「美國東部」（U.S. East）地區[3]新增了一台伺服器，並將當時的美國伺服器同步更名為「美國西部」（U.S. West），現行的四大地區就此成形。
另外，官方也鼓勵用戶在發生伺服器服務中斷，或在連接 VRChat 時發現問題時，可以先行查看伺服器狀態官方網站，或其在社群平台 X 上的 伺服器狀態官方帳號，以掌握最新狀況。
| 地區
代碼 |
地理 位置 | |
|---|---|---|
| USW | 美國西部 U.S. West |
加利福尼亞州聖荷西市 San Jose |
| USE | 美國東部 U.S. East |
華盛頓哥倫比亞特區 Washington D.C. |
| EU | 歐洲 Europe |
荷蘭阿姆斯特丹 Amsterdam |
| JP | 日本 Japan |
東京都 Tokyo |
房間命名
創建房間時，房間創建者可以選擇更改其顯示名稱。房間名稱會顯示於快速選單（Quick Menu）的「房間資訊」（Here）標籤頁中，以及世界的房間列表裡。房間名稱最多允許 32 個字元，且不允許使用 .、/ 和 字元。
在客戶端內為房間命名屬於 VRC+ 的功能，但透過 API 為房間命名其實並不需要訂閱 VRC+。
短網址
房間可以透過 VRChat 的 vrch.at 短網址網域，搭配房間的短名稱來分享，例如：https://vrch.at/<shortName>。此連結會重新導向至 VRChat 網站上這個房間的頁面。
房間設定
加入房間後，房間擁有者可以選擇該房間內允許顯示哪些內容。如未特別設定，則房間將會套用這個世界的預設設定。變更允許的內容類型可在快速選單的「房間資訊」標籤頁中查看與操作。
若房間類型為「公開」或「群組公開」時，則房間擁有者將無法調整房間設定，系統會依循世界作者的設定。除此之外，相關項目僅能在「群組」房間中切換，且無論房間類型為何，都將始終遵循世界作者的設定。
可切換的內容列表如下：
房間權限
你管理房間的權限將取決於你是否為世界作者、房間擁有者，或是群組管理員。
房間擁有者
房間擁有者（Instance Owner）是指創建房間的用戶，而根據房間類型的不同，房間擁有者可以是一般用戶、群組、世界作者。房間擁有權一旦被指派後便無法更改。若要變更房間擁有者，必須由其他用戶或群組重新建立另一個新的房間才能變更。事實上，「房間擁有者」經常會與「房主」（Master）搞混，但會有「房主」的出現，通常與 Udon 世界設定有關。
房間擁有者將具有用戶管理工具權限，其包括將用戶踢出、警告或靜音。在群組房間中，群組管理員及其可使用的權限則會取決於被分配的身分組與權限。
公開房間不會指派任何用戶為房間擁有者，而是預設由世界作者兼任房間擁有者。
世界作者
世界作者擁有與房間擁有者相同的用戶管理工具，權限上包括踢出、警告以及靜音。此外，世界作者還擁有以下的額外權限，但會依據房間類型而有所不同。
權限表
| 房間類型 | 公開 | 好友 + | 好友 | 邀請 + | 邀請 | 群組公開 | 群組 + | 群組 |
|---|---|---|---|---|---|---|---|---|
| 世界作者 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | 否 | 否 |
| 房間擁有者 | 否 | ✔️ | ✔️ | ✔️ | ✔️ | 群組管理員 具有權限時 |
群組管理員 具有權限時 |
群組管理員 具有權限時 |
| 群組管理員 | 否 | 否 | 否 | 否 | 否 | ✔️ | ✔️ | ✔️ |
房間容量
世界的人數容量可以在 VRChat 官方網站上進行設定，而無需重新上傳世界。不過，容量數值並不代表房間內可容納玩家的固定最高人數。實際的最高人數將依照以下方式計算：
| 一般與特殊狀況 | 詳細說明 |
|---|---|
| Recommended Capacity | The configured recommended capacity value. Once the current user count reaches this value, the instance is no longer listed publicly. The Recommended Capacity cannot be set higher than Maximum Capacity. |
| Maximum Capacity | The configured maximum capacity value. Once the maximum capacity is reached, users will be unable to join the instance. If the instance is owned by a group, users may join a Queue if activated. The Maximum Capacity cannot be set higher than 80.[note 1] |
| Instance creator or group owner | The user who created the instance can always join, even if the instance is at its maximum capacity. For Group, Group+, and Group Public instances, this reserved slot belongs to the group owner instead. |
| World author | The user who uploaded the world can always join, even if the instance is at its maximum cap. |
The maximum configurable capacity on the VRChat website is 80, resulting in an effective maximum of 82 players in normal conditions. If the instance creator or world author is already in the instance, their reserved slot is occupied and cannot be used by other players to exceed the maximum capacity.
- ↑ 1.0 1.1 While the Maximum Capacity of a world cannot be set higher than 80 under normal circumstances, VRChat staff can manually increase the instance capacity. This usually occurs during events or instance capacity stress tests.
Instance duration and automatic resets
[[File:Instance shutdown notification.webp
|alt=A notification on the VRChat Quick Menu notification pane, in the Other section. The notification reads: "Warning: This instance will be reset in 60 minutes due to its age."|thumb|The notification that appears when the instance is due to reset.]]
Instances that have been running for long periods will automatically reset to prevent potential issues. If an instance is populated, users will rejoin upon reset, otherwise, they are sent to their Home World. A 180- and 60-minute warning can be given, 5-minute warning is always given before a reset. Instances may run for up to 7 days but can reset sooner due to server-side updates.
