看到VPN字样时先问它指什么对象
WireGuard 官方将自身定义为 VPN，最初面向 Linux 内核，后扩展到多种平台。这个协议有自己的握手与传输，不是任何代理服务只要称为 VPN 就自动采用它。
| 名称所在位置 | 要核对的对象 |
|---|---|
| 服务称呼 | 实际提供者与配置来源 |
| 客户端功能 | 工具能够读取和运行什么 |
| 具体协议 | WireGuard等协议的字段和传输 |
| 核心类型 | 出站或endpoint的配置位置 |
服务名称中的一元，也不能推出 WireGuard 或其他协议的套餐条件。看当前交付内容，才知道要对照哪份技术说明，而不是从宣传称呼补出节点。
看到WireGuard配置时按公钥和UDP理解
WireGuard 的认证模型基于双方交换公钥，握手会轮换密钥。它的传输使用 UDP，官方明确不支持在 TCP 上建立自身隧道，不能把上层工具转换行为归成协议原生能力。
混淆也不是该协议专注的功能，相关需求在其上一层实现。读到安全能力时按定义保留条件，不从采用加密直接推导流量不可识别或所有环境都可用。
- 连接目标与公钥各有字段，不互换用途。
- 协议传输看UDP，不由承载的请求类型改名。
- 客户端列表只说明工具范围，实际服务另读配置。
内层请求与隧道传输是不同对象，承载TCP请求不等于隧道本身改成TCP。
Xray 的用户态 WireGuard 出站把路由到它的 TCP、UDP 请求封装为 IP 包，再经隧道发送。它还提醒 WireGuard 并非专为代理场景设计，不能只摘支持二字省去限制。
不同核心场景按配置形态对应
Xray 使用 wireguard 出站，mihomo 列有 WireGuard 代理类型。它们的配置组织各有自己的文档，不能把某个核心的字段路径直接复制到另一个核心。
sing-box 则从 1.11.0 起采用 endpoint，旧 WireGuard outbound 已弃用并在 1.13.0 移除。配置所在层级与版本一起看，不把新类型存在当成旧位置一直有效。
- 记下实际客户端与核心，再确认它使用哪个版本。
- 对照该版本的出站或endpoint对象，读取对应字段。
- 接着记录配置来源和实际返回，不凭名称假定已取得服务。
只有客户端时把配置服务单独留作核对项
WireGuard 官方采用配置文件，这次公开页面没有给出 URI 分享方案，相关格式没查到公开说明。不因为其他协议有分享前缀，就给它补一套官方链接写法。
一元机场如果交付其他协议，就按那个协议的说明读取，不强行写成 WireGuard。核心能运行某种协议与提供方实际销售什么是不同事实，不能让工具能力代替服务清单。
另找服务时可查看下方收录
若你需要比较其他机场，可从这里继续阅读收录信息。
常见问题解答
WireGuard能承载TCP请求，隧道就是TCP吗？
请求类型与隧道传输分开，Xray 可将 TCP、UDP 请求封装后交给 WireGuard。协议本身使用 UDP，官方不支持在 TCP 上建立自身隧道。
sing-box旧WireGuard出站可以一直沿用吗？
文档写 endpoint 自 1.11.0 起提供，旧 outbound 在 1.13.0 移除。按实际版本核对配置形态，不能只看到协议仍支持就保留旧对象不变。
服务叫一元VPN就能确定它提供WireGuard吗？
称呼不提供协议证明，需要实际配置或服务说明。先确定交付内容，再查对应客户端和核心，不能从 VPN 名称推导具体节点类型。