# URnetwork 的工作原理

URnetwork 是一个由成员驱动的隐私网络。你的流量从另一位成员的设备出网，而不是数据中心的 VPN 服务器。网站看到的是那台设备的 IP 地址，而不是你的。这篇概览讲清这条路径，以及各方能看到什么。

出口是遍布 90+ 个国家、2,000 多个真实城市的数千台成员设备，而不是从少数几个数据中心提供的虚拟 IP。实时数字发布在 `api.bringyour.com/stats/last-90`。

## 路径

流量经过四段：你 → 扩展器 → 运营方 → 提供者 → 互联网。

- **客户端。** 你设备上的应用或 SDK 实例。*网络*（network）是 URnetwork 对你账户的称呼，是计费和身份的单位；一个网络可以包含多个用户、设备和客户端。
- **扩展器。** 由志愿者运行、使用独立地址的转发节点，是路径的第一段。它把你的加密会话原样转发到平台，而不在自己这里终止，所以它承载的是自己无法读取的字节。作为你的第一跳，它确实能看到你的 IP 地址。
- **运营方。** 即 BringYour, Inc.，负责协调网络的一方。它的平台（`connect.bringyour.com`、`api.bringyour.com`）验证客户端身份、为你匹配提供者、中继流量，并处理合同与付款。
- **提供者。** 共享自己互联网连接的成员设备，它把你的流量转发到互联网，所以网站看到的是提供者所在城市的一个住宅地址。

运营方和提供者是两个中继方，这套设计把信息分割在两者之间。扩展器是这个分割之外的一个可达性节点，自身不增加任何加密。它的作用是在平台被封锁的地方保持网络可达。

![路径：四段、信息分割 — 各方能看到什么、不能看到什么](/docs-assets/diagram-the-path.svg)

## 谁能看到什么

在默认路径上，没有任何单独一方同时掌握你的身份和你的活动。这句话建立在两条适用范围不同的性质之上。

**提供者永远不知道你是谁。** 运营方站在你和提供者之间，所以提供者只看到一个设备 id 和它所服务的目的地，永远看不到你的地址。这一条在每条中继路径上都成立，不存在可能配错的设置。

**运营方无法读取你发送的内容。** 客户端↔提供者会话端到端密封，在原生应用中默认开启，所以运营方承载的只有密文，外加时序和数据量。这一条在默认的密封路径上成立；下表列出了没有密封的路径。

浏览器扩展和代理端点完全没有密封会话。这是适用范围，不是默认设置，而且由架构决定：浏览器或普通代理客户端无法运行这个网络的引擎，所以运营方在自己内部远程运行客户端设备，并在协议之间做转换 — 从那台设备发起的密封会在运营方内部开始，而密封的存在恰恰是为了让运营方看不见。这个实现用密封换来了对这些平台的支持。在那里，防止运营方积累你的目的地的是被测试钉住的存储纪律，而不是加密（[威胁模型](/docs/threat-model) §2.4）。

| 模式 | 运营方看到 | 提供者看到 | 默认与可用性 |
|---|---|---|---|
| **中继密封** | 账户/来源连接、提供者关联、密文及时序/数据量 | 目的地流量、设备/合同 id，**不含**你的真实来源 IP | 原生应用的默认状态，开箱即用 |
| **中继标准** | 账户/来源连接、提供者关联、内层目的地和数据包字节 | 目的地流量、设备/合同 id，**不含**你的真实来源 IP | 浏览器和代理路径，或密封被关掉时；密封开着时，无法完成密封的提供者会被跳过，而不是改走这里 |
| **直连** | 更少的中继参与 | **你的真实来源 IP**及目的地流量 | 自行选择开启：关闭强匿名化（Strong Anonymization） |

这张表是权威版本。[威胁模型](/docs/threat-model)用同一套分割逐一对照具名的对手，包括恶意的运营方和合谋的提供者。

## 为什么是四段

速度是设计目标，不是妥协。每多一跳，你与互联网之间的往返路程就被拉长，这正是长链路在日常使用中吃亏的原因。把路径限定在四段，让信息分割保持在流媒体级的速度上。URnetwork 给出的全网平均流媒体速度为 40 Mbps+。

严格的描述是：延迟受限、带数据分离的多跳设计。线路协议支持串接更多提供者中间节点；实际运行的网络使用单提供者路径。其他设计做出其他取舍。Tor 用延迟为更长的链路买单。Apple 的 Private Relay 是加密的两方分割，实现闭源，两方都由同一家公司挑选并付费。大多数 VPN 根本不做分割。[对比图谱](/docs/comparison)逐个产品讲清这些差异。

## 连接时会发生什么

1. **登录。** 应用用一个约一天过期、自动刷新的令牌登录，所以被盗的令牌很快就会失效。工程师称之为 JWT。账户可以使用邮箱或手机号、Google 或 Apple 登录、Solana 或 Bittensor 钱包签名、恢复短语，或者一键创建、无需邮箱的即时账户（Instant Account），后者的全部凭证就是一份恢复短语（seedphrase）。这份短语与 Mullvad 的编号账户是同类机制，并且能在重装后找回账户；服务器生成它、只显示一次、之后只保留哈希，所以弄丢短语就等于失去账户。
2. **连接平台。** 客户端与平台建立加密通道：基于 WebSocket 的 TLS，或在网络允许时使用 QUIC/HTTP-3。通道穿过一个扩展器，终止于平台。客户端先并发尝试直连路由；直连失败时由扩展器一段接管。
3. **寻找提供者。** 客户端按你的选择请求匹配的提供者：最佳可用、列表中的某个国家，或在搜索框里输入名字找到的某个城市。平台按可靠性和实测速度持续为候选者打分，并返回排好序的集合。
4. **建立合同，开始传输。** 客户端维持一个由多个提供者组成的*窗口*（window），把你的连接分摊到它们之间。默认配置同时运行两个窗口：服务 HTTPS 的质量窗口，2–6 个提供者；服务其余流量的速度窗口，1–2 个。通常有三到八个提供者同时在线。对同一个网站的连接固定走同一个提供者，所以那个网站在你整个会话里只看到一个稳定地址。表现不佳或掉线的提供者会被替换；窗口里其余的提供者接过它的工作。每个字节都在一份*传输合同*（transfer contract）之下传输，这是计量每个提供者承载量的记账单位。

![复数的出口身份：提供者窗口 — 按站点固定与故障切换](/docs-assets/diagram-provider-window.svg)

你的出口身份是复数的：同时有多个提供者，并随时间轮换，所以任何单个出口最多只能看到你浏览活动的一小片。窗口同时也是速度策略：住宅连接比数据中心服务器波动更大，淘汰慢的提供者才能让流媒体保持流畅。

## 加密

客户端↔平台通道始终加密：TLS 1.3 或 QUIC。

**密封会话。** 应用把流量一路加密到提供者，所以运营方中继的是自己无法读取的字节。到达运营方的只有密文，外加时序和数据量。这个控制项在 Android、iOS、macOS、Windows 和 Linux 应用的连接抽屉里名为**后量子加密**（Post Quantum Encryption），五个平台都默认开启。密封本身是客户端与提供者之间直接完成的 TLS 1.3 握手，采用混合后量子密钥交换 **X25519MLKEM768**，每条消息使用 AES-256-GCM。身份密钥是 Ed25519；"后量子"仅指密钥交换。

适用范围：密封开启时，无法建立密封的提供者根本不会承载你的流量。客户端拒绝以明文发送应用数据，而不是悄悄回退 — 无法完成密封的提供者会被跳过，而不是在未密封的状态下被使用。当前所有提供者构建都支持密封，所以这主要影响旧构建，代价是可用性而不是机密性。关掉后量子加密，旧的行为就会回来：流量此时可以走标准路径，在那条路径上平台能读到数据包的地址和内容。

局限：目前还没有应用会报告某个连接是否已密封。这个缺口真实存在，但已不再是危险的那一个 — 密封开着的时候，你不会被静默降级。这一点，连同 URnetwork 不防御的其他情形，都写在[威胁模型](/docs/threat-model)里。

**强匿名化与直连模式。** 提供者能看到它所服务流量的目的地址，就像今天你的 ISP 一样。它不知道你是谁：默认情况下它永远看不到你的真实 IP，只有平台能看到。这个默认对应连接抽屉里的**强匿名化**开关，出厂即开启。关闭它就选择了*直连模式*：客户端直接与提供者通信，吞吐量随之上升。代价：那个提供者现在能看到你的真实地址。托管配置一律强制关闭直连模式。

![密封会话改变了什么 — 标准路径对比密封会话，以及提供者无法完成密封时会发生什么](/docs-assets/diagram-sealed-session.svg)

## 各方能看到什么

| 参与方 | 能看到 | 看不到，或不保留 |
|---|---|---|
| 运营方（平台） | 你的账户；你连接那一刻的地址；由它推导的粗粒度城市/地区/国家；你用过哪些提供者；字节数；密文及其时序和数据量 | 数据包的目的地和内容（默认密封）；你的原始地址（只存带密钥的地址块哈希）；传输账本中的任何目的地字段 |
| 提供者 | 它向外承载流量的目的地 IP/SNI；合同携带的一个设备 id | 在中继路径上你的身份或真实 IP；只有运营方能把设备 id 解析为账户 |
| 扩展器 | 加密字节；你的 IP | 隧道内的任何内容 |
| 网站 | 一个住宅提供者地址 | 你的 IP；你的 ISP 身份 |

运营方一行的背后：

- 你的连接地址以带密钥的单向哈希形式存储，哈希对象是所在的 /29（IPv4）或 /56（IPv6）地址块，而不是地址本身。由地址推导出的粗粒度城市/地区/国家会按连接保留。
- 这种纪律写在代码里，而不只是政策里。HTTP 日志只放行五个请求头的白名单。传输账本记录客户端和网络 id 以及字节数，根本没有可写入目的地、主机、URL、SNI、端口或域名的字段。代理数据路径不记录任何内容，并由回归测试钉住。
- 密封让运营方读不了你的流量。存储纪律覆盖运营方仍能看到的部分（提供者关联、字节数、粗粒度位置），并在没有密封的地方顶上：浏览器扩展、代理端点，以及关掉了密封的原生应用。
- 局限：这些是代码所写记录的属性。入口负载均衡器的访问日志从未被审计，带地址和 SNI 的日志行会到达服务的 stderr，而 stderr 在生产环境的去向尚未查明。完整记录见[威胁模型](/docs/threat-model)。

![运营方存储什么 — 以及什么从不存在](/docs-assets/diagram-what-is-stored.svg)

## 开源，以及尚未审计的部分

整个技术栈都是开源的：应用、SDK、协议引擎，以及运营方自己的服务器代码，所以这里描述的机制可以直接读代码验证，而不必凭信任接受。开源证明的是设计，而不是线上部署的是哪个构建。

尚无独立审计覆盖协议、连接引擎（connect engine）或运营方的服务器代码，而隐私承诺正落在这一层。2025 年有两项第三方评估覆盖了其他层面。一项是对 Web 应用和 API 的独立渗透测试（2025 年 4–5 月）。另一项是 Leviathan Security Group 对 Android 应用的 MASA AL2 评估，结果通过；Leviathan 自己界定它不是整体性的安全评估。面对一年一度的时点式审计，URnetwork 的回答是常年接受审视的公开代码。完整记录见[威胁模型](/docs/threat-model)。

## 安全共享：ip_security 层

共享连接不应该意味着替陌生人背上法律风险。提供者客户端内置 `ip_security`，这是连接引擎里的开源流量安全层，也是引擎最大的组件之一。它检查提供者自己的出口，也就是通往互联网的出网点。有风险的流量在离开成员的连接之前就被拦下：

- **DMCA 类过滤。** 有状态检测器识别 BitTorrent 和文件共享特征，并丢弃不匹配任何正当协议的不透明流量，所以侵权的点对点传输不会从成员的线路流出。
- **CFAA 类过滤。** 未授权访问、扫描和漏洞利用的模式会被黑洞化，所以这条连接不会成为别人入侵的跳板。
- **一个被造出来"不看"的检测器。** 文件共享检查会从自己的流键里清除服务器名。它只依据地址、端口和数据流的起始字节做判断，计数器按协议和端口统计，从不按地址统计。

命中的结果是数据包被丢弃。BitTorrent 命中还会向运营方发出一个滥用标记：对端的设备 id 加一个布尔值，不含目的地、域名或内容。运营方今天没有处理这个标记的代码，收到后什么也不会存储。不透明协议的丢弃是静默的，没有任何上报。

这一层运行在边缘，而且在边缘的两侧：一侧在你的设备上，你连接时网络不承载的流量根本不会到达提供者；另一侧在提供者的设备上，也就是流量出网的地方。运营方不做集中检查，密封也绕不开这个过滤器，因为过滤器就运行在密封所连接的两个端点上。打开断网保护（kill switch）后（每个应用都有明确的开关，浏览器扩展默认开启），被拦截的流量会直接停止，而不是回落到你自己的连接。大多数国家都有 CFAA 和 DMCA 同类的法律；同一套标准在每个出口回应这些法律，URnetwork 在其分发到的每个国家都遵守当地法律。过滤器是持续维护的，不是一次定稿：它的威胁清单在每次发布时从公开的恶意软件、滥用和僵尸网络情报源（Spamhaus DROP、abuse.ch 的僵尸网络追踪器、Emerging Threats 等）重新生成，所以保持应用最新就能拦截最新的已知恶意地址段。[服务条款](/terms)约定共享连接的相关责任。

![ip_security：在边缘执行、不做监控 — 命中的流量在提供者自己的出口被黑洞化](/docs-assets/diagram-ip-security.svg)

## 穿过封锁

扩展器带着路径穿过本地和区域防火墙。每个扩展器都在可信的服务端口（443、DNS-over-TLS 853、LDAPS 636 等）上应答 TLS，在扫描器眼里像一个配置不当的 CDN。每个扩展器都硬编码为从自己的地址把加密流转发到平台，所以封锁 `connect.bringyour.com` 封不住入口。客户端轮换生成的扩展器伪装身份，配合随机化的数据包分片和乱序，直到某一个能用为止。在只有 DNS 能出去的网络里，DNS 形态的传输把 QUIC 数据包重塑成 DNS 查询和应答。任何人都可以运行扩展器。

![穿过封锁：扩展器与 DNS 形态的传输](/docs-assets/diagram-getting-through.svg)

## 提供者与覆盖

位置以真实在线为准：只有当某位成员的设备在一个城市在线时，那个城市才会被提供。平台对它观察到的连接做地理定位；提供者不能自行申报城市。看起来像数据中心、VPN 或重新通告地址段的地址会被降级，而不是被信任。局限：尚无外部机构测量过这支提供者队伍，也没有机制验证分配给同一客户端的提供者彼此独立、且独立于运营方。见[威胁模型](/docs/threat-model)。

共享连接是对闲置带宽的自愿共享：不打开就一直关闭，除非你允许蜂窝网络否则仅走 Wi-Fi，并且可以面向公共流量，也可以只面向你自己的设备。公共流量按量计量：平台给每份传输合同盖上只有该提供者掌握的密钥印记，所以提供者能核验一份合同是真实的、并且面向它同意服务的对象。托管额度以字节计价；两端各自上报承载量，结算数字取两者在容差范围内的平均值。提供者参与 UR protocol；奖励在 [ur.xyz](https://ur.xyz) 有完整说明，本页不再复述。免费档之所以存在，是因为付费成员为网络的成长出资。任何人都可以成为提供者。

## 套餐与运营方 API

套餐有两档：免费档提供每日流量额度；Pro 档提供大额的月度额度、更多并发客户端，以及代理和 WireGuard 便利功能。Pro 可以用钱包里的链上 USDC 支付。额度是计量制，不是限速制：额度用完后，网络停止建立新的传输，而不是给你降速。隧道归于安静，你自己的连接不受影响，额度按周期重新补满。当前数字见 [ur.io/products](https://ur.io/products)，机器可读版本在 `GET https://api.bringyour.com/x402/skus`。

应用做的每一件事都经过公开的运营方 REST API（认证、设备、提供者发现、订阅、统计），文档在 [API 参考](https://ur.io/docs/api)。智能体获得一等支持：`mcp.bringyour.com` 上的 MCPv2 服务器（OAuth；提供 `providerLocations` 和 `fetch` 工具），以及 x402 按需付费购买。见 [ur.io/agents](https://ur.io/agents)。

## 后备端点：HTTPS、SOCKS5、WireGuard

对无法嵌入 SDK 的软件，运营方运行桥接端点：HTTPS CONNECT 代理、SOCKS5，以及供标准 WireGuard 应用使用的 WireGuard 端点。SOCKS5 支持 CONNECT 和 UDP associate；不支持 BIND，超过 2 KiB 的 UDP 数据报按设计丢弃。局限：WireGuard 路径分配一个稳定的隧道地址，取自平台分配的私有地址池，不是你的真实 IP。这个稳定地址让同一个客户端可以被跨提供者关联起来，而且端点会向客户端下发一个固定的公共解析器（1.1.1.1）。应用和 SDK 仍是使用这个网络最私密的方式。

## 接下来去哪里

- 安装设置：Android、iOS、macOS、Windows、Linux、浏览器扩展和 SDK 的[入门指南](/docs)。
- 各平台的深入内容：导览文档。
- 其他产品：对比文档与[对比图谱](/docs/comparison)。
- 协议本身：白皮书、经济模型与提供者奖励见 [ur.xyz](https://ur.xyz)。