站点说明
来源登记
每条外部来源只支持明确范围；“可访问”不等于能证明某次故障原因。下列页面已于 2026-08-14 通过批准的 Clash 代理核对，动态内容仍以访问当日官方页面为准。
| 发布者与主标识 | 支持的主张 | 适用范围与核验日期 |
|---|---|---|
| Steam Support | Steam 官方支持与当前故障入口 | 只支持 Steam 平台操作；2026-08-14 |
| PlayStation Support / Connectivity | PlayStation 官方连接支持入口 | 不支持第三方线路性能结论；2026-08-14 |
| Xbox Support / Network connection | Xbox 官方网络连接排查范围 | 仅适用于 Xbox 支持文档覆盖的步骤；2026-08-14 |
| Nintendo Support / NAT | Nintendo 对 NAT 类型的官方说明 | 不等同端口全开放建议；2026-08-14 |
| IETF RFC 768 / UDP | UDP 数据报语义 | 不能推出某游戏或线路的表现；2026-08-14 |
| MDN / Fetch API | 浏览器 HTTP 工具使用的 Web API 边界 | 不是 ICMP 或游戏服务器 Ping；2026-08-14 |
更正时必须记录受影响 URL、旧主张、新来源与复验日期；来源冲突时优先官方当前文档，并将无法判断的部分保留为未知。
补充更新｜2026-10-19：新增主张边界、协议区别与复验模板；动态支持页和菜单名称可能随平台或客户端更新变化，以当前页面为准。
简答：来源登记的核心不是“链接越多越好”，而是明确每个来源究竟能证明什么、不能推出什么。Steam 官方页适合支持 Steam 自身的连接排查，RFC 适合支持协议语义，浏览器文档适合支持 HTTP 请求行为；它们都不能单独证明某条游戏线路、某个节点或某次对局的真实延迟。
定义：来源登记是把外部页面按证据等级、支持主张、适用范围和复验日期记录下来，防止把相关现象误写成已证实结论。
先看主张—来源对照表
遇到“延迟高、丢包、掉线或网页测速正常但游戏仍卡”的问题，先按下表选择证据，不要直接用一个测试结果替代另一类网络事实。
| 准备写入文章的主张 | 优先来源 | 可以支持的内容 | 不能直接推出的结论 |
|---|---|---|---|
| Steam 客户端无法连接 | Steam 官方网络连接排查 | Steam 服务状态、路由器、有线连接、防火墙、后台程序和部分 ISP 连接问题的排查方向。 | 不能证明某个第三方节点更快，也不能证明某款游戏服务器正在故障。 |
| UDP 的基本特征 | RFC 768：UDP | UDP 是面向数据报的协议，交付和重复保护不作保证。 | 不能据此证明某款游戏一定使用 UDP，除非另有游戏官方或可复现抓包证据。 |
| TCP 的基本特征 | RFC 9293：TCP | 现代 TCP 的规范范围，以及可靠传输、连接处理等协议层语义。 | 不能据此推断某个 TCP 节点的实际延迟、拥塞程度或游戏体验。 |
| ICMP 与 Ping 结果 | RFC 792：ICMP | ICMP 用于 IP 网络中的控制和错误反馈，说明 ICMP 报文的基本用途。 | 不能把 ICMP 响应时间直接等同于游戏进程使用的 UDP 或 TCP 往返时间。 |
| 浏览器请求耗时或 HTTP RTT | MDN Fetch API | 浏览器通过 fetch 发起网络请求，并在收到响应头后得到 Response。 | 不能单独代表游戏服务器的实时通信、UDP 路径、服务器排队或帧同步延迟。 |
| PlayStation 主机连接设置 | PlayStation 官方连接支持 | PS5、PS4 的网络设置入口和官方连接排查入口。 | 不能支持第三方线路性能、跨区延迟或端口“全开放”结论。 |
关键边界：“协议定义”“平台支持步骤”“浏览器请求结果”“游戏实测表现”属于四种不同证据，除非存在明确的测试过程，否则不能互相替代。
UDP、TCP、ICMP、HTTP RTT 怎么区分
UDP：RFC 768描述 UDP 提供数据报通信，并明确不保证交付和重复保护。文章可以据此解释 UDP 的协议语义，但不能凭 RFC 直接判断某款游戏采用 UDP。
TCP：RFC 9293是现代 TCP 的标准规范，并取代较早的 RFC 793 等相关基础规范。文章可以引用它解释 TCP 的标准范围，但不要把 TCP 的协议特征写成某条线路的实测结果。
ICMP：RFC 792说明 ICMP 用于报告 IP 数据报处理中的错误和网络控制信息。Ping 常使用 ICMP 回显机制进行探测，但目标主机可能限速、过滤或不响应，因此“Ping 超时”不自动等于游戏流量丢包。
HTTP RTT：MDN Fetch API说明 fetch 会在服务器返回响应头后得到 Response；因此浏览器请求耗时反映的是一次 HTTP 请求到指定 Web 资源的过程。本站判定：它可以作为网页服务连通性线索，但不能单独证明游戏内实时通信的延迟、抖动或丢包。
可照做的来源复验步骤
- 先定义问题：写清楚是 Steam 登录失败、游戏下载慢、游戏内 Ping 高、瞬时回弹、语音断续，还是主机无法联机。不同问题不要共用一个“测速结果”。
- 记录环境：保存复验日期、平台、操作系统、游戏名称和模式、网络方式（有线或 Wi-Fi）、所在地区、是否使用代理客户端或 TUN，以及当时是否处于晚间高峰。未记录这些条件的结果，只能标为“待复验”。
- 先查官方平台页面：Steam 问题先看Steam 官方网络连接排查；PlayStation 主机问题先看PlayStation 官方连接支持。官方页面支持的是平台自身的入口和排查步骤，不是第三方线路排名。
- 再分协议记录：ICMP Ping、TCP 连接、HTTP 请求和游戏内实时通信分别记录。不要把“网页能打开”写成“游戏线路正常”，也不要把“ICMP 不响应”直接写成“游戏一定丢包”。
- 再做对比：如果需要比较直连和某条线路，建议每个地区连续观察数分钟以上，在同一时段轮测，并分别记录平均延迟、峰值、丢包、抖动和实际游戏现象。这是本站的复验建议，不是 Steam、IETF 或游戏平台规定的官方测试标准。
- 最后写结论：只有当测试目标、协议、时间、平台和方法一致时，才可以写“本次条件下观察到差异”。如果缺少游戏服务器地址、官方公告或可复现抓包，应写“未核实”，不要写成确定的故障原因。
可复制的复验记录格式：日期｜平台｜游戏/模式｜地区｜网络方式｜测试目标｜协议｜测试时长｜平均值｜峰值｜丢包/抖动｜官方来源｜结论等级。
证据等级与冲突处理
- 一级：官方平台支持或状态页面。适合支持登录、连接入口、网络设置和平台已公开的故障说明。
- 二级：IETF RFC 或正式技术规范。适合支持 UDP、TCP、ICMP 等协议的定义和边界，不适合直接证明某个游戏、节点或服务商的实际性能。
- 三级：浏览器或开发者文档。适合支持 Fetch、HTTP Response 等工具行为，不适合替代游戏内网络测试。
- 四级：第三方经验文章或营销页面。可以作为排查假设或待核验线索，但其中的延迟阈值、端口、专线、排名和“零丢包”等说法，除非有独立且可复现的原始数据，否则不登记为已证实事实。
来源发生冲突时，优先采用与问题对象最接近的官方当前页面；协议问题优先采用对应的现行标准；第三方文章只能保留其明确写出的观察条件。RFC 页面如果标注已被更新或取代，应在登记中说明这一点，避免把旧规范误写成完整的当前实现指南。
安全与隐私边界
复验截图、日志或配置前，先删除账号、订阅链接、访问令牌、Cookie、设备序列号、支付信息和家庭公网 IP 等敏感内容。Steam 官方关于点对点网络的说明指出，部分点对点连接可能涉及玩家公网 IP 的共享或中继选择；这只能支持隐私风险提示，不能用来推断某一场对局一定采用点对点连接。
如需记录 Steam 点对点网络相关设置，应引用Steam 官方点对点网络与 IP 共享说明，并明确这是 Steam 设置和网络机制的说明，不是对具体游戏服务器拓扑的确认。
常见问题
Steam 官方网络排查页能证明某个游戏服务器故障吗？
不能。它主要支持 Steam 自身的服务状态、路由器、有线连接、防火墙和后台程序等排查方向；除非页面明确发布对应故障，否则不能把它扩展成某款游戏服务器故障结论。
UDP、TCP 和 ICMP 的测试结果可以互相替代吗？
不可以。UDP 和 TCP 是传输层协议，ICMP 用于 IP 网络控制和错误反馈。它们的目标、处理方式和响应条件不同，因此应分别记录；尤其不能用 ICMP Ping 直接证明游戏 UDP 流量的真实质量。
网页测速很低，为什么游戏里仍然会卡？
网页测速或 fetch 请求测到的是指定 HTTP 资源的请求过程，不一定经过游戏使用的服务器、端口或传输协议。应同时记录游戏内延迟、峰值、抖动、丢包和发生时间，并检查平台官方连接状态。
第三方文章写了固定延迟阈值，可以直接登记吗？
不能直接登记为事实。先确认测试地区、平台、游戏模式、服务器、网络方式、测试时长和原始数据；缺少这些条件时，只能标为待核验或排查假设。
来源登记多久复验一次？
动态官方支持页、平台状态页和客户端菜单应在文章更新时重新打开核对；页面已记录的日期为 2026-10-19。协议标准和浏览器文档也应检查是否出现更新、取代或行为变化。