⚠️ 警告：Tor VPN 是测试版软件。 请不要将其用于除测试以外的任何用途。 它可能会泄露信息，不应依赖它处理任何敏感信息。

Tor

Tor 网络可以理解为虚拟隧道网络，它能帮助您在互联网上提升隐私和安全性。 Tor 的工作原理是将您的流量通过 Tor 网络中的三个随机服务器（也称为中继）发送。 线路中的最后一个中继（“出口中继”）随后将流量发送到公共互联网。 使用 Tor 网络使得追踪用户的互联网活动变得困难，因为它防止网络上的任何单一点同时查看流量的来源和最终去向。 它会向您的互联网服务提供商（ISP）和任何您本地连接的监视者隐藏流量的目的地（即您访问的网站的名称和地址），而您访问的网站和服务的运营者及其监视者也只能看到来自 Tor 网络的连接，而不是您的真实互联网（IP）地址。

Tor VPN

Tor VPN 是由 Tor Project 开发的自由开源软件，基于 Tor 的应用，可用于通过 Tor 网络路由用户设备上的其他应用。 Tor VPN 利用 Tor 网络，通过 Tor 网络中的中继路由流量。 使用 Tor VPN 的一些主要用途和优势：

• 保护隐私。 您所访问的网站和服务的运营商及其所有监视者，可看到连接来自 Tor 网络，但看不到您真实的互联网 IP 地址或地理位置，并且不知道你是谁，除非您在网站上自曝个人信息。
• 阻止监视。 您的互联网服务提供商（ISP）或任何本地监视者皆无法追踪您的网络活动。
• 抵制审查。 Tor VPN 允许您访问某些地方可能被屏蔽的网站和应用，并在政府或互联网服务提供商（ISP）实施某种形式的互联网审查或过滤的地方访问自由互联网。
• 访问洋葱服务。 洋葱服务 是只能通过 Tor 网络访问的服务。 另外，洋葱服务可用于提供多种服务：让人们能够匿名浏览和发布内容；去元数据的聊天和文件共享，比如 OnionShare；支持记者与消息源之间进行安全的互动和资源共享，比如 SecureDrop；更安全的软件升级；以及更安全地访问热门网站。

Tor VPN 是自由软件。 免费，既是自由软件，也是免费提供的。 为确保您安装正确的 Tor VPN，请仅从下方提到的官方来源下载。

最低系统要求

Tor VPN 仅适用于 Android 操作系统，并且需要：

• Android 7.0 或更新版本。
• 支持 Aarch64、Arm、x86_64 或 x86 架构的 Android 设备。

不支持 Android 平板电脑和 Chromebook。

Google Play 商店

Tor VPN 可以从 Google Play 商店下载并安装。

F-Droid

Tor VPN 可以从 F-Droid 下载并安装。

• 点击“连接”即可启动连接。
• 将打开“连接请求”提示，以便 Tor VPN 建立 VPN 连接。
• 点击“确定”。

自动连接

您可以配置 Tor VPN，以便每次启动应用时使用之前保存的连接设置自动连接到 Tor 网络。

• 启动 Tor VPN 时，点击“配置”。
• 切换到“自动连接”。

您可以从应用商店更新 Tor VPN。

Google Play 商店

• 打开 Google Play 商店。
• 点击右上角的个人资料图标。
• 点击“管理应用程序和设备”。
• 点击“管理”选项。
• 点击“有可用更新”
• 从需要更新的应用列表中点击 Tor VPN。
• 点击“更新”。

F-Droid

• 打开 F-Droid 应用。
• 点击“设置”，然后打开“管理已安装的应用”。
• 在应用列表中点击“Tor VPN Beta”。
• 点击“更新”。

Google Play 商店

• 打开 Google Play 商店。
• 点击右上角的个人资料图标。
• 点击“管理应用程序和设备”。
• 点击“管理”选项。
• 从设备上安装的应用列表中点击 Tor VPN。
• 点击“卸载”。

F-Droid

• 打开 F-Droid 应用。
• 点击“设置”，然后打开“管理已安装的应用”。
• 在应用列表中点击“Tor VPN Beta”。
• 点击“卸载”。

设备设置

• 导航到设备设置。
• 导航到“应用”或“应用程序”部分。
• 选择 Tor VPN。
• 点击“卸载”。

您也可以仅允许某些应用使用 Tor VPN 并通过 Tor 网络对其进行路由。

如何为特定应用程序配置 Tor 连接设置

• 点击“应用”选项。 或者启动 Tor VPN 时，点击“配置”，然后点击“应用”。
• 关闭“保护所有应用”。
• 为每个单独的应用打开使用 Tor VPN 的选项。

连接到 Tor 网络时，网站和应用会认为您是从与 Tor 出口中继相同的国家/地区连接的。

配置 Tor 连接的出口位置：

• 点击“连接”屏幕上的“地球”图标。 或者在启动 Tor VPN 时，点击“配置”，然后点击“出口位置”。
• 该选项默认会设置为“每个线路随机”。 选中此选项后，每个配置的应用程序都会获得一个随机的 Tor 线路。
• 点击并从列表中选择国家/地区。

要激活“断网开关”：

• 启动 Tor VPN 应用并点击“配置”。
• 点击“断网开关”。
• 点击 Tor VPN 设置（⚙️）。
• 切换到“始终运行 VPN”。

应用图标和名称

要更改应用图标的外观和应用程序的名称：

• 启动 Tor VPN 后，点击“配置”。
• 点击“应用图标”。
• 从选项中选择。
• Tor VPN 仍将在主屏幕、通知、搜索、应用库和应用商店页面上可见。

在完成常见的故障排除步骤后，如果 Tor VPN 无法启动与 Tor 网络的连接，则可能是您的 Tor 连接受到了审查。 在这种情况下，连接其中一种内置的审查规避方法可能会有所帮助。

使用网桥：

• 点击“连接”。 或者启动 Tor VPN 时，点击“配置”，然后点击“网桥”。
• 切换到“使用网桥”。

Tor VPN 支持以下类型的网桥：

• obfs4：obfs4 使 Tor 流量看起来像随机数据，同时也阻止审查者通过互联网扫描找到网桥。
• Snowflake：Snowflake 通过志愿者运营的代理路由您的连接，使其看起来像是在进行视频通话，而不是使用 Tor。
• WebTunnel：WebTunnel 会隐藏您的 Tor 连接，使其看起来像是您正在通过 HTTPS 访问网站。

根据您所在的位置，某些类型的网桥可能效果更好。

如果使用内置的 obfs4 和 Snowflake 审查规避方法不起作用，您将必须请求其他网桥。 由于网桥地址不公开，您需要直接从应用中自行请求：

通过 Telegram 机器人获取网桥

• 点击“请求网桥”。
• 点击“给我新网桥”。
• 网桥机器人获取网桥地址后，点击“保存网桥”。

通过电子邮件获取网桥

• 使用 Gmail 或 Riseup 邮件地址向 bridges@torproject.org 发送邮件，并复制邮件中收到的网桥地址。

从网桥站点获取网桥

• 访问网桥网站。
• 点击“获取网桥”。
• 然后点击“Just give me bridges!”并复制网桥。

输入网桥地址

如果您通过电子邮件或网桥网站获得了网桥，则必须手动添加网桥。

• 要使用网桥，请点击“连接”。 或者启动 Tor VPN 时，点击“配置”，然后点击“网桥”。
• 切换到“使用网桥”。
• 点击“添加新网桥”。
• 粘贴复制的网桥地址。
• 点击“保存”。

如果 Tor VPN 无法连接，您可能会看到错误消息：

要进行故障排除，请尝试以下每种方法：

检查 Android 设置

• 确保您没有运行其他 VPN 应用。 Android 不允许同时使用多个 VPN 应用程序。
• 请确保网络防火墙应用程序未运行。 防火墙应用程序通常使用 VPN 连接，如果运行，将禁止 Tor VPN 建立任何连接。

检查 Tor VPN 应用程序

查看 Tor VPN 日志有助于诊断问题。 要获取 Tor VPN 日志：

• 在错误消息或“连接”屏幕上点击“查看 Tor 日志”。
• 点击“配置”。
• 滚动到 Tor VPN 设置的“高级”部分。
• 点击“Tor 日志”。

错误 #1：检查互联网连接

00:00:00:00 W/onionmasq: onion_tunnel::runtime: Arti failed to connect to [2a00:ccc1:1:2c::1]:9000: Network is unreachable (os error 101)
00:00:00:00 W/onionmasq: tor_chanmgr::transport::default: Connection to [scrubbed] failed: error: Network is unreachable (os error 101)

错误 #2：检查 Tor 是否在您的网络中受到审查。

00:00:00:000 E/onionmasq: onionmasq_mobile::ffi: runProxy() returned error: couldn't start onionmasq proxy
00:00:00:000 CONNECTION_ERROR
00:00:00:000 D/onionmasq: onionmasq_mobile: closing proxy...

在这种情况下，尝试某种审查规避方法可能会奏效。

如果您遇到的问题无法通过我们的文档解决，请尝试故障排除步骤。 如果这不起作用，请提交错误报告或联系我们的支持团队。

发送支持请求、意见反馈或缺陷报告时，请尽可能提供更多相关信息：

1. Android 版本。
2. Tor VPN 版本。
3. 逐步说明您如何遇到该问题，以便我们可以重现它。
4. 问题的屏幕截图。
5. Tor 日志。
6. 您连接到 Tor 的国家或地区。
7. 如果您知道或怀疑 Tor 在您所在的地区或网络中受到审查，请提及。

反馈和报告错误

Tor 论坛

在 Tor 论坛上，创建账号来提交新主题。 请在发帖前查看我们的讨论指南并检查现有主题。

Tor GitLab

如果报告错误，请在我们的错误跟踪器上报告。 请检查是否已报告该错误。 要搜索和查看与 Tor VPN 相关的所有错误报告，请导航至 Tor VPN 仓库。

要创建新的错误报告，请申请一个新账号来访问 Tor Project 的 GitLab 实例。 将错误报告提交至 Tor VPN 仓库。

联系支持

• 我们通过电子邮件、Telegram、WhatsApp 和 Signal 的用户支持渠道在周一至周四提供服务。 从周五到周日，帮助热线暂停服务，但请放心，我们的团队一定会回复您的消息。
• 我们所有的支持渠道提供英语、俄语和波斯语。 如果这些语言都不适合您，请使用您熟悉的任何语言书写，但请记住，我们需要更长的时间才能回复，因为我们需要翻译帮助才能理解。
• 我们在 Telegram、WhatsApp 和 Signal 上的支持渠道仅限文本消息；不支持视频或通话。

Telegram

发送消息至 @TorProjectSupportBot。

电子邮件

发送电子邮件至 frontdesk@torproject.org

请在您的电子邮件主题行中告诉我们您要报告的内容。 您的主题行越具体，我们就越容易理解和跟进。 有时，当我们收到没有主题行的电子邮件时，它们会被标记为垃圾邮件。

WhatsApp

发送消息至 +447421000612。

Signal

发送消息至 +17787431312。

Mike Perry

mikeperry@torproject.org

August 6, 2025

0. Introduction

Similar to Tor Browser, and unlike traditional VPNs, Tor VPN gives each application its own route through the Tor network. This feature prevents network adversaries from linking a user's private activity with their non-private activity.

In contrast to Tor Browser, the privacy benefits that Tor VPN provides depend highly upon the behavior of individual applications, the permissions granted to those applications, and the configuration of the base Android system.

For privacy-hostile applications in partial Tor mode, or for applications that users only occasionally use with Tor, Tor VPN provides only censorship circumvention and protection from network surveillance.

When used on properly configured privacy-enhanced Android distributions such as GrapheneOS, Tor VPN can provide additional privacy benefits even for privacy-hostile applications.

This document describes the nature of the benefits that Tor VPN provides and when they apply.

0.1. Table of Contents

• Tor VPN Threat Model
• Mike Perry
• 0. Introduction
• 0.1. Table of Contents
• 1. Overview
• 1.1. Threat Model Summary
• 2. Security Properties
• 2.1. Low-level VPN Security Properties
• 2.2. ICTM Security Invariants
• 2.3. ICTM Security Invariant Activation Conditions
• 3. Android App Types and Configurations
• 3.1. Application Types
• 3.2. Device Configurations
• 4. Threat Model Matrices
• 4.1. Tor VPN Per-App Mode Matrix
• 4.2. Tor VPN All-App Mode Matrix
• 5. Known Weaknesses
• 5.1. All Android Versions
• 5.1.1. Network Interface IP Address Visibility
• 5.1.2. Push Notification Linkability
• 5.1.3. Multicast DNS and SSDP Leaks
• 5.1.4. Android ID
• 5.1.5. SIM Card Operator ID
• 5.1.6. WiFi Calling
• 5.2. Stock Android
• 5.2.1. Apps Can Use Cell Network to Bypass VPN
• 5.2.2. Secondary User Profiles Bypass VPN at Start
• 5.2.3. Google Account Linkability
• 5.2.4. Various DNS Leaks
• 5.2.5. VPN Bypass Whitelist
• 5.3. GrapheneOS
• 5.3.1. Android Advertising ID Linkability

1. Overview

The Tor VPN threat model uses the ICTM methodology. ICTM specifies security invariants that the user can expect when using the software in a particular way or in a particular environment. An ICTM threat model starts from a point of "No Security" and adds security invariants when the software environment meets particular requirements.

We express what Tor VPN provides in terms of ICTM security invariants, which apply to specific application types and usage scenarios.

In our usage of ICTM, we define five ICTM security invariants that represent levels of privacy that Tor VPN provides. This document links these invariant terms in Capitalized Bold Italic to their definition sections.

These security invariants apply to the combination of four types of Android applications, two modes of Tor VPN (all-app or per-app), and five Android device configurations. This document links these classification terms in Capitalized Bold to their definition sections.

The combined outcome results in two threat model matrices that represent the ICTM security invariant that is active in a given situation.

1.1. Threat Model Summary

The level of pseudonymity that Tor VPN provides to the user guides the overall threat model.

Tor VPN provides at least censorship circumvention to all selected apps.

Tor VPN does not magically make all apps anonymous or pseudonymous. If the user used their real name or even created their account without Tor, then they have no pseudonymity.

If the user uses a privacy-enhanced version of Android and is careful about their Google account setup and app usage, then Tor VPN can help protect the usage of a single pseudonym for the user of the device. (The user may try to use different names in different apps, but app behavior can link these pseudonyms to the Google account and/or to each other).

If the user uses privacy-preserving apps with proper configuration, then Tor VPN can enable the usage of separate pseudonyms in those apps. (When properly configured, an adversary cannot link the different pseudonyms used in distinct privacy-preserving apps).

Essentially, this threat model describes the circumstances under which the user obtains these different levels of pseudonymity protection.

2. Security Properties

The low-level VPN security properties and the ICTM security invariants support the Tor VPN threat model.

2.1. Low-level VPN Security Properties

Two low-level security properties that the OnionMasq networking daemon provides support the ICTM security invariants. These low-level security properties must hold for the ICTM invariants to apply:

1. Network Leak Safety. Apps MUST NOT be able to bypass the VPN when it is enabled. This includes during device startup, if the VPN is not connected yet, or if the network is temporarily disconnected. The VPN industry calls this property a "Kill Switch", "Always On VPN Lockdown", or "On Demand". The Always-on Lockdown feature of Android 8 and above provides this property.

2. Network App Isolation. All network activity of each Tor-routed app MUST be isolated from other apps by using its own dedicated Tor circuit(s). Specific apps MAY bypass Tor entirely if the user chooses to allow this. The ConnectivityManager APIs of Android 10 and above provide this property.

2.2. ICTM Security Invariants

These are the security invariants that Tor VPN is capable of providing to individual apps. To simplify activation conditions, some invariants inherit the properties of earlier ones. We list these inherited invariants under each invariant.

The high-level conceptualization to keep in mind is that we are defining distinctions in the level of pseudonymity that the user can expect for an app: no pseudonymity, multi-app shared pseudonymity, per-app pseudonymity, and anonymity.

The next section lists the activation conditions under which they apply.

• No Additional Security
• Invariant Property: Tor VPN provides no additional security.

• Censorship Circumvention
• Invariant Property: A network adversary is unable to block application traffic.

• Network Privacy
• Invariant Property: A local network adversary is unable to determine which applications are used with Tor VPN, and apps are unable to determine the user's current IP address (i.e., approximate current location).
• Inherited Invariants: Censorship Circumvention

• Linkable Pseudonymity
• Invariant Property: App usage has pseudonymity, but this pseudonymity may be linked to other activity on the device or to a sandboxed and pseudonymous Google account. This is also known as Multi-App Shared Pseudonymity.
• Inherited Invariants: Censorship Circumvention, Network Privacy

  NOTE: Linkable Pseudonymity is a fragile state. As pseudonymous activity is linked together, the odds increase that there is some way to deanonymize some of that activity, thus deanonymizing all of it. One can conceptualize this invariant as providing "Multi-App Shared Pseudonymity," where all apps with Linkable Pseudonymity on the device effectively share the same pseudonym. This is why we require either the Pseudonymous Google Configuration or Google-Free Configuration for apps to gain this invariant. (Pseudonymity would otherwise vanish as soon as it was linked to a non-pseudonymous Google account.)

• Unlinkable Pseudonymity
• Invariant Property: App usage has unique pseudonymity that is not possible to link to other device activity. This is also known as Per-App Pseudonymity.
• Inherited Invariants: Censorship Circumvention, Network Privacy

  NOTE: One can conceptualize this invariant as providing "Per-App Pseudonymity." Because of Tor VPN's Network App Isolation, when this invariant is active for an app, its activity cannot be linked to non-private activity on the device. This is not the case for traditional VPNs, which allow the VPN operator and VPN endpoint observers to link such activity.

• Full Anonymity
• Invariant Property: App usage is unlinkable to other device activity, as well as to previous activity of that same app.
• Inherited Invariants: Censorship Circumvention, Network Privacy

2.3. ICTM Security Invariant Activation Conditions

Our security invariants activate depending on what type of app is in use, the Tor VPN mode (per-app or all-apps), and properties of the base OS and configuration.

The lowest numbered invariant where an app matches these clauses is the invariant for that app.

A device may have multiple apps operating at different security invariant levels, depending on these conditions.

The Threat Model Matrices present this same activation information in table form.

• No Additional Security
• Activation Condition: Active for all apps when the user installs Tor VPN but does not enable it at all.

  Rationale: Surprisingly, this is a common failure mode for VPN apps among people who do not understand how they work.

• Activation Condition: Active for all apps when the user installs Tor VPN on a device past the end-of-life for Android security fixes.

  Rationale: We cannot provide any additional security to a device that is already vulnerable to unfixed, publicly disclosed security flaws. We assume these public flaws can subvert any privacy or security properties the user would hope to gain by running Tor VPN.

• Activation Condition: Active for apps that are not selected to use Tor when the user runs Tor VPN in per-app mode.

  Rationale: In per-app mode, apps that are not selected for Tor use get no protection. (Though they could if we implemented a per-app network block feature).

• Censorship Circumvention
• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in per-app mode.

  Rationale: Privacy-hostile applications can trick the user into opening URLs in apps that are not selected to use Tor and can link non-Tor activity to their activity.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses the IP Address Privacy Configuration.

  Rationale: On all versions of Android, Privacy-hostile applications can use the ACCESS_NETWORK_STATE Android permission to determine the SIM card IP address and can engage in data sharing with the ISP, which removes Network Privacy. On Stock Google Android (but not GrapheneOS), they can bind to the cell network interface to directly bypass the VPN for arbitrary network connections.

• Network Privacy
• Activation Condition: Active for all privacy-hostile and pseudonymous Unmasked Apps not covered by the previous invariant when the user runs Tor VPN in either per-app or all-app mode.

  Rationale: We assume unmasked apps have no pseudonymity.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses only the IP Address Privacy Configuration (and not any further unlinkability configuration).

  Rationale: Privacy-hostile apps can link their activity to the user's real name and Google account unless the user takes further steps.

• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, when the device uses only the IP Address Privacy Configuration (and not any further unlinkability configuration).

  Rationale: Pseudonym-friendly apps can be accidentally linked to a user's real name and Google account through push notifications, phone number authentication, and other mechanisms, unless the user takes further steps.

• Linkable Pseudonymity
• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, and the device uses the Pseudonymous Google Configuration and the user grants push notification permission to the app.

  Rationale: The usage of Google push notifications links the pseudonymous app to the device's Google account, which is also pseudonymous in this configuration.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses the Pseudonymous Google Configuration or Google-Free Configuration.

  Rationale: Privacy-hostile apps can cooperate with other privacy-hostile apps on the phone to link activity, even without a device Google account.

• Unlinkable Pseudonymity
• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, and has configured the device and app with Pseudonymous App Configuration or Google-Free Configuration.

  Rationale: These device configurations prevent linkability of the pseudonymous app to the device's Google account.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and has configured the device with Isolated User Profile Configuration.

  Rationale: This device configuration isolates privacy-hostile apps from the device's Google account and from each other.

• Full Anonymity
• Activation Condition: Active for Anonymity Apps when the user runs Tor VPN in either all-app mode or per-app mode.

  Rationale: Anonymity apps have no other identifiers other than the current IP address, which is now a Tor exit IP address.

3. Android App Types and Configurations

As can be seen, our security invariants depend upon the app type and the Android device configuration. In this section, we define those applications and configurations specifically.

3.1. Application Types

We classify Android applications into four types:

• Unmasked Apps Unmasked apps are apps that were previously used outside of Tor, associated with a non-pseudonymous phone number, or associated with a real name/email. In essence, these apps have been unmasked to the user's real name. Unmasked apps can no longer have any strong pseudonymity expectations and can at most gain only Network Privacy from Tor VPN.

  NOTE: Once an app is unmasked on a device, creating a new pseudonymous account in the same app does not remove this classification. In fact, due to the Android ID identifier behavior, deleting the app and reinstalling it in the same profile still allows a new pseudonym to be linked to the deleted one. A user must use the Isolated User Profile Configuration to create a new device user profile to use the app in an unlinkable way with respect to the current profile's Android ID for that app.

• Examples of unmasked usage include:
• Signal registered with a regular phone number.
• A ProtonMail account accessed over non-Tor.
• An Element account linked to an email address in the user's real name.
• Any app that has been linked with a non-pseudonymous Google account (via push notifications, location usage, etc.).
• Any app that has been linked to a pseudonymous Google account that is later accessed over non-Tor.

• Privacy-hostile Apps Privacy-hostile apps are apps that use every available mechanism to attempt to link their activity to other user activity. They make use of the Android Advertising ID, identifiers, network state, location, sensors, etc. In a stock Android configuration, these apps gain Censorship Circumvention from Tor VPN, but can gain higher Tor VPN invariants when used with privacy-enhancing Android distributions, as referenced in those invariants. See Device Configurations for specific configuration details. Example Apps: Facebook, Instagram, WhatsApp, TikTok, X, and Reddit.

• Pseudonym-friendly Apps These are apps that provide accounts with some degree of pseudonymity, either as an explicit design goal or as a consequence of not actively trying to link user activity together or otherwise track the user. Unfortunately, the Android OS can easily subvert their pseudonymity through misconfiguration or even basic usage. In a default Android configuration, these apps gain Network Privacy from Tor VPN. These apps can gain Unlinkable Pseudonymity from Tor VPN on stock Android, under the device configuration conditions specified in that invariant. Example Apps: Signal, Session, Element, ProtonMail, and TutaMail.

• Anonymity Apps These are apps that do not store long-term identifiers or logins. In some cases, such as private browsers, the app clears identifiers upon restart or otherwise regularly. In other cases, such as Zcash wallets, the app uses Zero-Knowledge proofs rather than trackable identifiers. These apps gain Full Anonymity from Tor VPN. Example Apps: Zashi, Cake Wallet, and private browsers.

3.2. Device Configurations

Architecturally, Tor VPN is capable of providing a high degree of unlinkability to applications on the same device, as we can see from the security invariants. Unfortunately, Android is an extremely privacy-invasive platform. The Android ecosystem has been built upon the same advertising model that the web has been built upon. Because Google controls Android and is the primary benefactor (if not sole conduit) of Android advertising revenue, Google designed the platform to maximize the ability to track usage and to link user activity together to build a comprehensive advertising profile of the user. This linkability is problematic even for apps that provide pseudonymity as a design goal, merely through their usage of the system APIs. The primary way that the system subverts pseudonymity is by associating the pseudonym with the Google account, most often through push notifications, but also through associating location information with the Android Advertising ID. On a stock Google Android, the device's Google account gets full device information: serial number, IMEI, IMSI, phone number, WiFi MAC address, full location history, and installed application list. We assume that any linking mechanism to the stock Android Google account provides deanonymization of a pseudonym. In these cases, apps can gain Network Privacy at most. The good news is that there are ways of configuring an Android device that improve the ICTM security invariant that Tor VPN can provide:

• IP Address Privacy Configuration From a VPN provider's perspective, the most unfortunate aspect of Android is that every app on the device typically has the ACCESS_NETWORK_STATE permission, which gives access to all IP addresses on the device, along with a lot of other network interface information that can be used to track the user. For a good overview of all the information that is available by default, install Network Analyzer or use the Device ID test in our VPN Test App. Unfortunately, even privacy-preserving Android distributions such as GrapheneOS do not provide the ability to redact non-VPN network information and non-VPN IP addresses when a VPN is active. Additionally, on stock Android, apps can bypass the VPN interface by binding to the cell network interface, regardless of Always-on and Block Connections Android settings. Until those tickets are fixed:
• The device must be in Airplane mode and used with a WiFi hotspot or tethered to another phone.

• Pseudonymous App Configuration As per the app classification, Pseudonym-friendly Apps are privacy-focused apps that provide a pseudonym and do not actively try to deanonymize the user. They also may not necessarily ensure that this pseudonym is fully unlinkable. To ensure that Pseudonym-friendly Apps are unlinkable to other device activity, the user must do the following:
• Do not use the device phone number for app registration. Use an online SMS or VoIP provider over Tor.
• Do not use the device's Gmail account for app registration.
• Disable notifications from within the app (disabling push permission is insufficient).
• For apps that are capable of making voice and video calls, either use IP Address Privacy Configuration, or configure the app to always relay these calls for you.

When these properties are met, the app will not be linked to the device's Google account, which is a common source of deanonymization.

NOTE: Removing push notification permission is NOT ENOUGH to prevent apps from being able to register with Firebase (Google) to receive a push token that links the app to the Google account. See the Push Notification section of Known Weaknesses for more information. For now, if an app does not provide settings to disable notification registration, then you must use one of the following configurations instead. (For example: Session Messenger allows push registration to be disabled or switched to non-Google; Signal currently offers no such configuration).

• Pseudonymous Google Configuration On stock Android, linking activity to the Google account typically means deanonymization. The Google account is typically in the user's real name, and even if not, it has access to all device identifiers, including cell network and location history. There are two levels of reducing the damage that this linkability can do while still retaining key device functionality:
• Make a new pseudonymous Google account on GrapheneOS.
• Use a GrapheneOS device with the Google Service Framework package installed, but without a Google account.

It turns out that from the point of view of our ICTM security invariants, both of these are equivalent: they both result in Linkable Pseudonymity for both pseudonym-friendly apps and privacy-hostile apps because they significantly reduce the amount of linkable information, but they do not eliminate it. The primary reason is due to the remaining push notification linkability. See the Push Notification Linkability section of Known Weakness for more info. If the push notification linkability weakness is mitigated, then pseudonym-friendly apps will have Unlinkable Pseudonymity in this configuration when using push notifications. The first option accepts linkability through the Google account but mitigates deanonymization through careful management of this Google account. In this configuration, the user creates a new Google account over Tor and relies on the GrapheneOS Google Sandbox to provide pseudonymity for the device's Google account. In this sandbox, the system treats Google as a normal app, with revocable permissions and no access to hardware identifiers. Additionally, GrapheneOS requires the user to manually disable the Android Advertising ID. Doing so eliminates a large source of excess linkability. The Android Advertising ID is heavily used to link pseudonyms to location data. In the second option, the user configures a new privacy-enhanced Android device without a Google account but still uses push notifications with sandboxed Google Play Services on GrapheneOS. The user can use F-Droid or Aurora Store to install apps without a Google account. Without a Google account, there is less linkability risk between apps through other Google APIs other than push.

NOTE: The device must always use Tor to avoid linking its device push registration to a non-Tor IP address. This may be problematic in censorship scenarios where configuration information is delivered over push notifications. In this case, without a device Google account, it may be possible to clear registration data and re-register to remove linkability. But the effectiveness of this will depend on the data retention duration of the services involved for expired push tokens. See the Push Notification Linkability section of Known Weaknesses.

• These properties define this configuration:
• Configure with the IP Address Privacy Configuration to prevent Google Services and hostile apps from using the cell IP address for linkability.
• Optional Google Account Config:
• Create a new pseudonymous Google account over Tor for the device, using an SMS or VoIP phone number.
• The Android Advertising ID of this account has been disabled.
• Do not use the device phone number or Google account for app registration. Use a different online SMS or VoIP provider over Tor.
• If Tor VPN is in per-app mode, all Google Play Services and Google apps must be selected to use Tor in this configuration.
• Disable Private DNS and Connectivity Checks.

• Google-Free Configuration In this configuration, the user installs GrapheneOS without Google Play Services installed at all, yielding a fully "de-Googled" Android device. The user can still use Aurora Store to install apps without a Google account, though many apps may crash or fail without access to Google Play Services. This configuration entirely prevents linkability through push notifications and other Google API usage. For the apps that function, these foot-guns will be completely unavailable. We still assume that privacy-hostile applications can link their activity in this mode if they cooperate on-device or via sensor side channels. This is why these apps are still listed as having Linkable Pseudonymity, but this linkability is significantly less than with a Google account or Google APIs involved.
• These properties define this configuration:
• Install GrapheneOS, but do not install Google Play Services.
• Configure with IP Address Privacy Configuration.
• Use Aurora Store to install apps.
• Do not use the device phone number for app registration. Use a different online SMS or VoIP provider over Tor.

• Isolated User Profile Configuration Privacy-hostile apps are considerably harder to make unlinkable. Because the Android system allows apps to communicate with each other, and because there is evidence of apps willfully abusing this communication to link activity, the only real option to make privacy-hostile apps unlinkable is to install them in their own Android user profile on an Android distribution that supports strong profile isolation. The main downside of this approach is that each user profile must run its own instance of Tor VPN.
• The properties of this configuration are:
• Configure with IP Address Privacy Configuration.
• GrapheneOS is needed to ensure apps from separate profiles cannot communicate or bypass the VPN.
• The profile needs its own installation of Tor VPN.
• The profile should not install Google Play Services.
• Do not use the device phone number or Google account for app registration. Use a different online SMS or VoIP provider over Tor.

4. Threat Model Matrices

The active security invariant for a given scenario can be summarized in two matrices: one for Tor VPN per-app mode and one for Tor VPN all-app mode. These two matrices exactly represent the ICTM security invariant clauses from Section 2.3.

4.1. Tor VPN Per-App Mode Matrix

App Type / Android Config	Base Android	IP Address Privacy Configuration	Pseudonymous App Configuration	Pseudonymous Google Configuration	Google-Free Configuration	Isolated User Profile Configuration
Unmasked Privacy-hostile Apps	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention
Unmasked Pseudonym-friendly Apps	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Privacy-hostile Apps	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention
Pseudonym-friendly Apps	Network Privacy	Network Privacy	Unlinkable Pseudonymity (without push registration**)	Linkable Pseudonymity (with push registration**)	Unlinkable Pseudonymity	Unlinkable Pseudonymity
Anonymity Apps	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity

4.2. Tor VPN All-App Mode Matrix

App Type / Android Config	Base Android	IP Address Privacy Configuration	Pseudonymous App Configuration	Pseudonymous Google Configuration	Google-Free Configuration	Isolated User Profile Configuration
Unmasked Privacy-hostile Apps	Censorship Circumvention	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Unmasked Pseudonym-friendly Apps	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Privacy-hostile Apps	Censorship Circumvention	Network Privacy	Network Privacy	Linkable Pseudonymity	Linkable Pseudonymity	Unlinkable Pseudonymity
Pseudonym-friendly Apps	Network Privacy	Network Privacy	Unlinkable Pseudonymity (without push registration**)	Linkable Pseudonymity (with push registration**)	Unlinkable Pseudonymity	Unlinkable Pseudonymity
Anonymity Apps	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity

5. Known Weaknesses

In this section, we list the known weaknesses of both stock Android and privacy-enhancing Android, where fixing a weakness would significantly improve the available security invariants.

For each weakness, we list the Consequences for the user and the mitigating configurations the user must perform, when possible.

We also provide fix Recommendations for developers of GrapheneOS, Android, and pseudonym-friendly apps.

5.1. All Android Versions

The following Android privacy issues apply to all Android versions, including GrapheneOS and CalyxOS.

5.1.1. Network Interface IP Address Visibility

In all versions of Android, when apps have the ACCESS_NETWORK_STATE permission (which nearly all Android apps have), they can examine properties of all network interfaces, including the IP address. For a good overview of all the information that is available by default, install Network Analyzer or use our VPN Leak Test App.

Consequences: This weakness prevents Tor VPN from providing Network Privacy (or further invariants) to Privacy-hostile apps. This weakness also exposes the user to IP address leaks even for Pseudonym-friendly apps that disclose all device IP addresses during WebRTC calls. In both cases, the user must use their phone with a mobile WiFi hotspot, rather than a SIM card, to mitigate this weakness.

Recommendation: When a VPN is enabled, the Android OS should simulate non-VPN interfaces as disconnected, or it should spoof unused RFC1918 addresses for non-VPN interfaces. If addresses are spoofed, the system should not provide the same values to all apps, to prevent the use of spoofed values as identifiers (which likely already happens with IP address values today). These mitigations are essential because they enable VPNs to provide Network Privacy. Most VPN users naturally want their IP addresses to be unavailable to apps for tracking purposes.

5.1.2. Push Notification Linkability

All versions of Android (and also all versions of iOS) are currently subject to linkability through push notifications, even when the user has denied push notification permission to all apps.

When registering for Google's Firebase push notifications, apps obtain an FCM "token" from Firebase, which they submit to their servers. Their servers use this token to deliver messages to Google, who then uses the token ID to look up the device and send it the message.

Our VPN Leak Test App verifies that this registration ability is possible without any push notification permission, in the Device ID test.

This means that a series of record requests (sent first to the app developers and then to Google) will discover the Google account in use with a particular app. From there, even if there is no device Google account, the other push tokens associated with the device can be used to make further record requests to other app service providers for account data associated with their respective token IDs.

Because Google (and many apps) operate internationally, these requests can come from arbitrary jurisdictions. The Anti-Foreign Sanctions Law in China is one such example of a law that can be used for this purpose, although no direct reports of China using push notifications have been made public. It seems likely that Wyden's concerns did not come from nowhere, though.

This linkability is possible even for apps like Signal that do not send any actual content in the push notification and use it only as a wake-up notification. Because Signal still stores the token ID with the user's account on their servers, this linkability also exists for them.

This makes it impossible to have distinct pseudonyms for Signal, or any other app that registers with FCM, unless the user configures their device without Google Play Services or creates a separate user profile without Google Services for these apps.

Consequences: This weakness makes the Pseudonymous App Configuration impossible for many apps, because FCM push registration cannot actually be disabled by the user by denying push notification permission to an app. It also makes Pseudonymous Google Configuration have far more app linkability to the Google account (or device) than would otherwise be the case, linking many privacy-hostile apps to Google and to other pseudonym-friendly apps. The user has no real mitigation options, because disabling push notifications still allows this registration and resulting linkability.

Recommendations:

There are a few different approaches that can reduce the user's exposure to this linkability:

• Permissions Enforcement for Push Registration: Access to the FCM Push Registration APIs (or their Google Service Framework downstream calls) should be blocked if the user has not granted push permissions to an app, because users expect that denying push notifications prevents an app's ability to register for push notifications with their Google account.
• Sandbox Registration APIs Separately: On GrapheneOS, since it already has a Google sandbox, FCM Registration APIs could be directed to separate instances of the Google Services Framework that are not associated with the device's Google account or any of the device permissions that may have been granted to the main GSF instance (such as SMS permission or Location permission). Separate sandboxing is useful, because it will allow users to register for push notifications without associating push registration with their Google account.
• Blinded FCM Registration Tokens: At Google Firebase itself, either Blind Signatures or Privacy Pass could be used during push registration such that the push server authenticates the registration in the normal way, but the actual token is blinded. The push tokens would then be unlinkable to the actual device or Google account, but are still authenticated themselves through the blind signature. This blinding will be beneficial to both users and to Google, because it will save Google the cost of answering push-related record requests from arbitrary international jurisdictions, since push tokens would not be possible to associate with account or device info.
• App Config Options: In the meantime, privacy-preserving apps can offer the option to disable push registration or use an alternate provider such as Unified Push. Note that Signal already provides the ability to deliver notifications through its own WebSocket mechanism, but this is only used if Google Play Services are absent. There is no exposed user option for WebSocket push for users with Google Services installed. Alternate push configuration will be useful because it will help users have push notifications without associating their Google account to their app accounts, before the above options are available.

5.1.3. Multicast DNS and SSDP Leaks

In our testing, we discovered that apps can bypass the VPN by using mDNS requests and SSDP activity. We have a reproduction case in our VPN Leak Test App. This test leaks on all versions of Android, including GrapheneOS. GrapheneOS has attempted to fix some multicast leaks, but our test app shows that these fixes are insufficient.

Additionally, these multicast leaks enable privacy-hostile apps to communicate on a local network, further linking user pseudonyms to other app activity on that same network.

This behavior is also observed in the wild, with Spotify engaging in communication over the local network through this bypass mechanism.

Consequences: This weakness allows Privacy-hostile apps to communicate on the local network to link their usage to other users on the network.

Recommendation: The Android OS should route this multicast behavior through the VPN interface. This will enable the VPN app to decide whether to allow these local network connections.

5.1.4. Android ID

The Android ID is essentially a 64-bit identifier that is shared by all apps in a user profile with the same signing key.

This identifier persists across re-installations of the same app, which can be verified using our VPN Leak Test App using the Device Identifier test. Users who expect to be able to delete an app and then reinstall it to sign in under a different pseudonym will have their pseudonyms linked by Privacy-hostile apps that make use of this identifier.

Consequences: This weakness prevents users from being able to reinstall apps to change pseudonyms without linking those pseudonyms together. Basically, due to this weakness, once an app is linked to the user's real identity on a profile, that app will always be an Unmasked App, even after reinstallation. Users must install that app in a separate profile to avoid this linkability.

Recommendation: This ID should be randomized with every app installation, rather than persisting after uninstallation. This will allow users to delete an app to change pseudonyms.

5.1.5. SIM Card Operator ID

For some reason, no Android permissions are necessary to determine the cell network ID and the provider name of the user's SIM card. This information can be used to determine the user's rough geographic location, depending on the range of the cell provider (typically at least country-level, but sometimes regional, state, or province-level). The Device ID test of our VPN Leak Test app displays this information. It is also visible in Network Analyzer.

Consequences: This weakness does not directly impact any of our privacy invariants, but it is generally bad for privacy.

Recommendation: These APIs should always return NULL/empty (the default when no eSIMs are configured), because this information is not necessary for app operation.

5.1.6. WiFi Calling

We observed that when WiFi calling is enabled for an activated eSIM, the device makes IPsec connections to the eSIM provider, bypassing the VPN.

Consequences: This weakness does not directly impact any of our privacy invariants, but it is generally bad for privacy in that it exposes the user's WiFi IP address to their cell network.

Recommendation: Allow VPN interfaces control of routing this connection, so that it may be disabled if the user chooses to block it.

5.2. Stock Android

Stock Android has a number of edge cases that can leak DNS or multicast, which can remove the Network Privacy invariant by revealing to the local network that a particular app may be in use.

5.2.1. Apps Can Use Cell Network to Bypass VPN

Stock Android allows apps to bind to the cell network interface and then connect to an IP address, bypassing any VPN in place, regardless of Always-On or Block Connections VPN settings. Our VPN Test App has a reproduction case for this as part of the Leak Test. This leak is only possible over the cell network interface.

GrapheneOS fixed this issue in the 2025072700 Release.

Consequences: This leak allows Privacy-hostile apps to remove Network Privacy on stock Android. Users must use the IP Address Privacy Configuration and/or use GrapheneOS to prevent this leak.

Recommendations: Google shouldn't allow rogue apps to bind to the cell interface to bypass the VPN in Lockdown Mode, because VPN users expect that apps can't bypass the VPN in this mode.

5.2.2. Secondary User Profiles Bypass VPN at Start

On stock Android, user profile isolation can leak packets upon first use after restart.

Consequences: This leak prevents stock Android users from successfully using Isolated User Profile Configuration to isolate sensitive app activity. Users have to install GrapheneOS to mitigate this.

Recommendation: These leaks should be fixed, because users expect Always on VPN and Block Connection settings to work in all user profiles.

5.2.3. Google Account Linkability

On stock Android, the device Google account has access to all hardware identifiers, as well as SIM card identifiers and phone number. This access typically means that any form of linking to the device Google account (through push notifications, Gmail use, or Google OAuth sign-in) typically means deanonymization of a pseudonym.

Consequences: It is difficult for a user to maintain a pseudonym even in Pseudonym-friendly apps without careful configuration.

Recommendations: Both privacy-conscious apps and Google should have more transparency with respect to actions that link the app's account to the device Google account, because users tend to expect that pseudonymity is not actively subverted behind their backs. In the meantime, the GrapheneOS Google Sandbox enables Pseudonymous Google Configuration.

5.2.4. Various DNS Leaks

Multiple issues with DNS exist in stock Android. Apps that use getaddrinfo() from the C library can bypass the VPN. Our VPN Leak Test app reproduces this leak as part of the main Leak Test.

Additional, DNS leaks can happen if the VPN malfunctions or shuts down.

Consequences: DNS leaks can erode Network Privacy by allowing local ISPs to determine which apps are in use. Users must use GrapheneOS to avoid these leaks.

Recommendations: GrapheneOS has fixed these issues. Google Android should upstream these fixes, because users expect that their DNS activity will not bypass their VPN.

5.2.5. VPN Bypass Whitelist

Android has a secure setting Settings.Secure.always_on_vpn_lockdown_whitelist, which allows custom Android builds to define a list of apps that always bypass the VPN, regardless of VPN settings. Google and GrapheneOS both have this setting empty, but third-party Android builds may place their apps in this setting. The ReThink Firewall App has a ticket describing this issue.

Google Android also allows connectivity checks to bypass the VPN. GrapheneOS provides a setting to disable this.

Consequences: On Android rebuilds, various vendor apps may be exempted from the VPN, allowing them to connect outside of it. Users must use GrapheneOS to avoid these leaks.

Recommendations: Users should disable or remove vendor apps that they don't need.

5.3. GrapheneOS

The following weaknesses are unique to GrapheneOS. Note that the universal Android weaknesses also apply to GrapheneOS.

5.3.1. Android Advertising ID Linkability

Additionally, the default-on behavior of the Android Advertising ID is another source of linkability between apps. GrapheneOS requires users to manually disable this ID, but this is not prominently documented during setup.

A better default would be to have the Android Advertising ID disabled by default or to provide a prominent setup step that educates users about this privacy risk.

We list this as a GrapheneOS-specific weakness because other privacy-preserving versions of Android randomize this ID automatically.

Consequences: Users who are not aware that they need to configure their Google account to disable this identifier will have all of their Privacy-hostile app activity linked to their Google account and to each other. Users must manually disable the Advertising ID in their Google account settings.

Recommendation: Similar to how GrapheneOS proxies the Location APIs, this API should be proxied to return a random or zeroed number, because this API is an extremely invasive source of linkability that enables aggregation of location and usage data across apps.

Tor 依靠全球用户和志愿者的支持，来协助我们改进相关软件和资源，因此你的反馈对我们（以及所有 Tor 用户）而言极具价值。

反馈模板

给我们发送反馈或者报告漏洞时，请尽量包含以下信息，越多越好：

• 使用的操作系统
• Tor 浏览器版本
• Tor 浏览器安全级别
• 请逐步说明你如何碰到该问题，以便我们能够将其重现。（比如，“我打开了浏览器，输入 url，点击图标，然后我的浏览器就崩溃了。”）
• 问题的截屏
• 日志文件

如何与我们联系

有多种方式可以联系我们，请选择对你来说最方便的一种。

Tor 论坛

建议在 Tor 论坛寻求帮助。 您需要先创建账户才发表新帖。 在提问之前，请查看讨论指南。 目前，为了尽快获得回应，请使用英文书写。 如果发现漏洞，请使用 GitLab 反馈。

GitLab

首先，检查该缺陷是否已知。 您可以在 https://gitlab.torproject.org/ 上搜索并查看所有的议题。 想要新建问题，请申请新账户来访问 Tor Project 的 GitLab 实例，并找到正确的存储库来报告你的问题。 Or you can report bugs or send us feedback anonymously through Anon Ticket without needing to create an account. 我们用 Tor 浏览器的问题跟踪器 跟踪所有与 Tor 浏览器有关的问题。 网站相关的问题应在网页问题跟踪器处提交。

Telegram

如果需要帮助安装 Tor 浏览器或排查故障，并且所在地屏蔽或审查 Tor 论坛，可以通过 Telegram https://t.me/TorProjectSupportBot与我们联系。 Tor 支持专员将协助你。

WhatsApp

可发送文本消息我们的 WhatsApp : +447421000612 寻求协助。 该服务仅限文本消息，不支持视频和语音通话。

Signal

您可以向 Signal 号码 +17787431312 或 Signal 用户名 @torsupport.89 发送文本消息，来联系我们的团队。 Signal 是一款免费且注重隐私保护的通讯应用。 该服务仅限文本消息，不支持视频和语音通话。 在信息发送后，支持人员将为你提供指引和帮忙，以便排除故障。

电子邮件

请给我们发送电子邮件至 frontdesk@torproject.org。

在电子邮件的主题栏中，请简述你要报告的内容。 请使用更为明确的邮件主题（如“连接失败”“网站反馈”、“ Tor 浏览器反馈”、“需要网桥”），以便我们更容易理解并跟进你的问题。 如果电子邮件主题为空，有时将被视为垃圾邮件，导致我们没有看到你的邮件。

为了得到更快的回应，请使用英语、西班牙语或葡萄牙语写邮件。 如果以上语言都不适合，请选择你想用的任何语言，不过请注意，由于需要通过翻译来理解你的消息，回复将需更长时间。

博客文章评论

在与你的问题或反馈相关的博文下，你可以随时发表评论。 如果没有相关问题的博文，请使用其他方式联系我们。

Matrix/IRC

您可以在 OFTC 上的 #tor 频道或 #tor:matrix.org 提交反馈或漏洞/问题。 我们可能不会立即回复，但我们会查看近期收到的信息，然后尽快的回复。

了解如何连接到 OFTC 服务器。

邮件列表

如果想用邮件列表报告问题或反馈，建议使用相应的列表 。邮件列表的完整目录可以在这里找到。

有关运行 Tor 中继的反馈或问题： tor-relays

报告安全问题

如果有安全问题，请发邮件至 security@torproject.org。

如果需要对邮件加密，可以从这个地址keys.openpgp.org获得 OpenPGP 的公钥。以下是当前的指纹：

835B 4E04 F6F7 4211 04C4 751A 3EF9 EF99 6604 DE41

如果要参加漏洞赏金计划，请注意，向第三方网站报告安全问题会带来我们无法控制的风险，所以请直接向我们报告。

发送支持请求、意见反馈或缺陷报告时，请尽可能提供更多相关信息：

1. 所用的操作系统
2. Tor 浏览器版本
3. Tor 浏览器的安全级别
4. 逐步说明该问题如何出现，以便我们能够重现（例如，我打开浏览器，输入网址，点击设置中的选项，然后浏览器崩溃）
5. 问题的屏幕截图
6. 桌面版 Tor 浏览器控制台日志（在 Windows/Linux 上可以通过 Ctrl+Shift+J 打开，在 MacOS 上可以通过 Cmd+Shift+J 打开）
7. Tor 日志（设置 > 连接 > 高级 > 查看 Tor 日志）
8. 连接 Tor 时你的所在地。
9. 从“连接助手”中选择的区域（如果问题与“连接助手”相关）
10. 所在地是否屏蔽 Tor？
11. 如果 Tor 能够连接，它需要多少时间来启动？对浏览速度有什么影响？

Tor 用户支持团队的办公时间

周一至周四：电子邮件、Telegram、Whatsapp 和 Signal 支持渠道正常运行。

周五至周日：支持渠道关闭。 请放心，我们的团队将在周一回复您的消息。

如何联系我们

有多种方式可以联系我们，请选择对你来说最方便的一种。

Telegram

我们提供数个官方 Telegram 机器人和频道：

1. @GetTor_Bot 下载 Tor 浏览器。
2. @GetBridgesBot 获得obfs4 网桥。
3. @TorProject 获得最新的消息。
4. @TorProjectSupportBot 寻求帮助。 目前，Telegram 支持频道提供英语、俄语和波斯语服务。 如需规避审查帮助，请从菜单选项中选择所在地区，以便我们后续跟进。

Tor 论坛

建议在 Tor 论坛寻求协助。 你需要创建帐户才能提交新话题。 在提问之前，请查看我们的讨论指南，并检查现有的话题。 目前，为了尽快获得回应，请使用英文书写。 如果发现漏洞，请使用 GitLab。

WhatsApp

可发送文本消息我们的 WhatsApp : +447421000612 寻求协助。 该服务仅限文本消息，不支持视频和语音通话。

Signal

您可以向 Signal 号码 +17787431312 或 Signal 用户名 @torsupport.89 发送文本消息，来联系我们的团队。 Signal 是一款免费且注重隐私保护的通讯应用。 目前支持频道提供英语、俄语和波斯语服务，主要协助受审查地区的 Tor 用户。 该服务仅限文本消息，不支持视频和语音通话。 在信息发送后，支持人员将为你提供指引和帮忙，以便排除故障。

电子邮件

发送电子邮件至 frontdesk@torproject.org

在电子邮件的主题栏中，请简述你要报告的内容。 请使用更为明确的邮件主题（如“连接失败”“网站反馈”、“ Tor 浏览器反馈”、“需要网桥”），以便我们更容易理解并跟进你的问题。 如果电子邮件主题为空，有时将被视为垃圾邮件，导致我们没有看到你的邮件。

为了获得最快的响应，请使用英语、俄语、波斯语、西班牙语、印地语、孟加拉语或葡萄牙语。 如果以上语言都不适合，请选择你想用的任何语言，不过请注意，由于需要通过翻译来理解你的消息，回复将需更长时间。

IRC 和 Matrix

可通过 OFTC 的 #tor 频道或 Matrix 的 Tor 用户支持频道联系。我们可能无法立即回复，但会查看累积的记录并尽快回应。

了解如何连接到 OFTC 服务器。

GitLab

首先，检查该缺陷是否已知。 您可以在 https://gitlab.torproject.org/ 上搜索并查看所有的议题。 想要新建问题，请申请新账户来访问 Tor Project 的 GitLab 实例，并找到正确的存储库来报告你的问题。 我们用 Tor 浏览器的问题跟踪器 跟踪所有与 Tor 浏览器有关的问题。 网站相关的问题应在网页问题跟踪器处提交。