在无界面 Pi 上用 Proton VPN：应用还是 WireGuard 文件？

在无界面 Pi 上安装 Linux 应用听起来只有一条指令，其实藏着两条支持边界不同的部署路径之间的选择。一条是提供方的官方应用，它自带发行版与架构要求。另一条是手动配置文件，由系统已经打包的标准客户端使用。两者通往同一项服务，但在维护层面并不能互换。

架构问题排在第一位，因为 64 位板子可能运行着 32 位用户空间，而应用只提供其中一种。

两条支持边界，而非两个安装器

阅读提供方针对你打算使用的应用给出的最新安装页面，并与板子对照：发行版版本、软件包架构，以及任何桌面或会话要求。dpkg --print-architecture 和 uname -m 各用一行给出答案。Pi 支持 64 位运行，并不说明当前装的是哪个用户空间，而这正是包管理器要检查的值。若版本或架构超出文档范围，即使装得上，也不算受支持。

支持程度还随打包方式而变。为一种包格式记录的限制，不会自动适用于从仓库构建的版本；基于 Debian 的发行版也不自动等于受支持环境。社区软件包和旧安装配方有各自的维护模型，你可以有意接受，但不该无意照搬。

应用有、而配置文件没有的东西

官方应用不只是一条连接：它通常带有提供方的应急开关、DNS 处理与功能开关，而提供方把这些行为作为整体来支持。交给标准客户端的手动配置文件，这些都继承不到。手动客户端自己掌管连接生命周期和本地故障策略，你自己配置时没问题，一旦以为它们会跟着来就会出意外。两种选择都能连到同一批服务器，但只有一种包含周边逻辑。

如果某项功能重要，比如在隧道之外阻断流量，它必须存在于你的配置里，而不是提供方的应用里。

手动使用 WireGuard：真正重要的步骤

提供方记录了如何为标准兼容客户端生成 WireGuard 配置，并为手动方案推荐这条路径，较旧的设备则保留 OpenVPN。在账户面板生成配置文件，带到 Pi 上，放在只有所有者能读取的位置。永远不要把该文件贴进支持论坛：名字再友好，内嵌的私钥也不能公开。随后先用一个请求测试隧道，再往上面接别的东西。

服务器下线是常被遗忘的运维细节。手动选定的端点可能被撤回，提供方也提示可能需要替换配置。记下配置文件用的是哪个端点，日后出故障才可诊断。

确定 Pi 是否同时充当网关

Pi 自身应用使用的隧道，不会自动成为其后设备的网关。转发、回程路由、解析器归属，以及阻止流量漏出隧道的任何策略，都是另一套设计，有各自的故障模式。如果还有其他设备，请把它们当作独立案例评估，而不是假定 Pi 的连接已经覆盖它们。正是这种分离让小型部署可维护。

然后接受这套生命周期：来自 Pi 的新请求、经指定解析器的名称解析，以及你规划好的开机或重连行为。逐项验证，而不是假定应用或配置文件已经提供。

值得丢掉的一个误解是：Linux 安装器和 WireGuard 文件代表同一个决定。它们是两套运营模式，归属也各不相同。