折腾过远程访问方案的人应该都有同感：最烦的不是配置有多复杂，而是工具太碎。

暴露 Web 服务要配反向代理，访问内网资源要搭 VPN，身份认证又得单独搞一套。三个系统三套配置，一出问题跟破案似的——到底是代理挂了、VPN 断了，还是认证失效了？权限同步更是让人头大，改了这边忘了那边是常态。

问题出在哪？传统方案把「访问控制」和「网络连接」当成两件事来处理，结果就变成了工具拼凑。

最近 GitHub 上有个项目在尝试打破这种局面，而且反响还挺不错。

一、Pangolin 是什么

GitHub 上有个叫 Pangolin 的项目，目前 Star 数 19.9k，而且还在涨。

官方 slogan 是 "Identity-aware VPN and proxy for remote access to anything, anywhere"——身份感知的 VPN 和代理，随时随地访问任何资源。

Pangolin 是一个基于 WireGuard 的开源远程访问平台，把反向代理和 VPN 整合到一起。不管是浏览器访问 Web 应用，还是用客户端连 SSH、数据库、RDP，都用同一套身份认证和权限管理。

Pangolin 用零信任（Zero Trust）架构，默认不信任任何连接，每次访问都要验身份、过策略。传统 VPN 是「连上就能访问整个内网」，Pangolin 则是「管理员明确指定你能访问什么」，真正实现最小权限。

这个项目 2024 年 9 月才开源，半年多拿到近 2 万 Stars，在远程访问这个赛道算是相当亮眼的成绩。代码双许可：社区版 AGPL-3.0 开源，企业版用 Fossorial 商业许可（年收入低于 10 万美元的企业可以免费使用）。

二、核心功能详解

2.1 Sites（站点连接器）—— 让任意网络触手可及

Sites 要解决的是一个老大难问题：怎么安全地连接那些没有公网 IP 的远程网络。

老办法要么开放端口（不安全），要么用内网穿透工具（不稳定）。Pangolin 的做法是部署一个轻量级 Site 连接器，自动建立 WireGuard 安全隧道，不用公网 IP、不用开放端口，还能穿透大多数防火墙。

具体能做什么：

• • 连接家里的 NAS、树莓派集群
• • 接入办公室的本地开发环境
• • 打通多云环境下的私有网络
• • 管理分布在各地的 IoT 设备

每个 Site 都是一个独立的网络边界，你可以给不同 Site 设置不同的访问策略。比如开发环境的 Site 可以给工程师完全访问权限，而生产环境的 Site 只允许特定人员访问特定服务。

2.2 浏览器级反向代理 —— Web 应用的零信任入口

对于 Web 应用，Pangolin 提供了开箱即用的反向代理能力。

与传统反向代理的区别：

• • 身份感知：每个请求都带用户身份信息，应用可以根据用户做个性化响应
• • 上下文感知：支持基于设备、位置、时间等上下文信息的动态访问控制
• • 自动 SSL：内置 Traefik 集成，自动申请和管理 HTTPS 证书
• • 负载均衡和健康检查：生产环境必备的高可用特性

用户访问流程很流畅：打开浏览器 → 跳转到统一登录页（支持 Google、Azure AD、Okta 等 OIDC 提供商）→ 认证通过后看到自己有权限访问的应用列表 → 点击即可使用。

这种体验既保留了反向代理的便利性，又增加了零信任的安全性。

2.3 客户端级私有资源访问 —— 不只是 Web

真正体现 Pangolin 野心的是它的客户端功能。

安装 Pangolin 客户端（支持 macOS、Windows、Linux、iOS、Android）后，你可以：

• • 通过本地端口转发访问远程数据库（如 localhost:5432 映射到生产数据库）
• • 直接用 SSH 连接内网服务器，就像它们在本地网络一样
• • 远程桌面（RDP/VNC）到办公室的电脑
• • 访问整个网段，比如在咖啡店也能访问公司内网的所有设备

技术亮点是智能 NAT 穿透。 Pangolin 客户端使用多种 NAT 穿透技术（包括 UDP 打洞和 DERP 中继），即使在严格的防火墙环境下也能建立连接。如果直接连接失败，会自动切换到中继模式，确保可用性。

DNS 别名功能也很实用：你可以给资源起友好名称（如 prod-db.internal），Pangolin 会自动处理 DNS 解析和路由，不用记复杂的 IP 地址。

2.4 统一的访问控制策略

这是 Pangolin 区别于拼凑方案的核心优势。

无论用户通过浏览器还是客户端访问，权限检查走同一套逻辑：

• • 基于角色的访问控制（RBAC）
• • 细粒度的资源级权限（可以精确到某个端口、某个路径）
• • 动态策略（根据用户身份、设备状态、地理位置实时决策）
• • 审计日志（记录谁、何时、访问了什么）

管理员在一个控制面板里管理所有资源的访问权限，用户在一个入口看到自己能访问的所有资源。这种一致性大大简化了运维工作，也减少了配置错误导致的安全隐患。

三、技术架构深度解析

3.1 整体架构：三层设计

如果简化理解，Pangolin 的架构可以分为三层：

控制层（Control Plane）：负责身份认证、策略管理、配置下发。这是整个系统的大脑，对应 Pangolin 的控制面板。

数据层（Data Plane）：负责实际的网络流量转发。包括反向代理组件（基于 Traefik）和 WireGuard 隧道管理。

接入层（Access Layer）：用户和设备的接入点，包括浏览器、桌面客户端、移动客户端，以及部署在各个网络的 Site 连接器。

3.2 核心技术：WireGuard 的威力

Pangolin 选 WireGuard 做底层隧道，这个选择挺有意思。

比起 IPSec 和 OpenVPN，WireGuard 的优势很明显：

• • 代码量小：约 4000 行代码 vs OpenVPN 的数十万行，审计更容易，攻击面更小
• • 性能更高：基于内核态实现，吞吐量比 OpenVPN 高数倍
• • 连接速度快：握手过程极简，冷启动连接时间从几秒降到毫秒级
• • 漫游友好：IP 地址变化时能快速恢复连接，非常适合移动设备

Pangolin 在 WireGuard 之上构建了自己的控制协议，实现了动态密钥交换、多路径传输、NAT 穿透等高级功能。

3.3 创新点：身份与网络的解耦

传统 VPN 的思路是「先连上网络，再谈访问权限」。一旦连上 VPN，用户就在内网里了，能访问什么全靠防火墙规则。

Pangolin 的思路是「先验证身份，再决定你能访问什么网络资源」。身份验证发生在网络层之前，每个资源访问请求都带身份上下文，权限检查可以在应用层完成。

这种解耦带来了几个好处：

• • 更细粒度的控制：可以精确控制到用户 + 资源 + 动作的级别
• • 更好的可观测性：知道谁访问了什么，而不是只知道谁连上了 VPN
• • 更灵活的部署：控制平面和数据平面可以独立扩展

当然，代价是架构更复杂，需要维护更多的组件和状态。但从长远看，这是零信任架构的必然选择。

四、行业背景与趋势分析

4.1 远程访问领域的变局

疫情那段时间，远程办公需求把 VPN 市场推上了高峰，但也把传统 VPN 的问题暴露无遗。

传统 VPN 的逻辑是「内网 = 安全，外网 = 不安全」。只要连上 VPN 进了内网，你就是可信用户，内网资源随便访问。这套「城堡 + 护城河」模型在边界清晰的时代还行，但在云原生、分布式、移动办公的今天，明显已经跟不上节奏了。

零信任网络访问（ZTNA）应运而生。 Gartner 预测，到 2025 年，60% 的企业将逐步淘汰传统 VPN，转向 ZTNA 方案。

主要玩家包括：

• • 商业方案：Zscaler、Cloudflare Access、 Palo Alto Prisma Access
• • 开源/半开源：Tailscale、ZeroTier、Headscale、Netmaker
• • 新兴力量：Pangolin、OmniEdge

4.2 Pangolin 的差异化定位

在这个竞争格局中，Pangolin 的位置很有意思。

相比商业 ZTNA 方案：

• • 优势：完全开源、可自托管、无供应商锁定、成本可控
• • 劣势：企业支持体系不如成熟厂商、生态集成较少

相比 Tailscale/ZeroTier：

• • 优势：完全开源（Tailscale 客户端开源但控制平面闭源）、内置反向代理能力、更细粒度的访问控制
• • 劣势：社区规模较小、第三方工具支持较少

独特价值主张：Pangolin 是少数同时提供「VPN 组网 + 反向代理 + 统一身份管理」的开源方案。如果你既需要安全的网络层访问，又需要方便的 Web 应用暴露，Pangolin 可以减少工具链复杂度。

4.3 趋势判断

零信任架构是大势所趋，但落地过程会分化：

大型企业倾向于采购成熟的商业方案（合规、支持、SLA 保障），中小企业和技术团队会更关注开源方案（成本、可控、定制化）。

Pangolin 的机会在于服务后者——那些希望拥抱零信任、但不想被商业方案绑定或支付高额许可费的用户。如果能在易用性和生态建设上持续投入，有机会成为这个细分领域的领导者。

风险在于赛道竞争激烈，Tailscale 等品牌已经建立了较强的用户心智，Pangolin 需要在差异化功能上持续创新。

五、实际场景与案例

5.1 典型使用场景

场景一：个人开发者/技术爱好者

小明在家里搭建了 NAS、树莓派集群和 Home Assistant，希望能从公司或外出时安全访问。以前他用 frp 做内网穿透，但配置繁琐且担心安全性。

用上 Pangolin 后，他在家里部署了一个 Site 连接器，在公司和手机上安装客户端。现在访问家里的服务就像访问本地服务一样简单，而且所有连接都经过身份验证和加密。

场景二：初创公司

一个 10 人左右的创业团队，有本地开发环境、测试服务器和云上的生产环境。以前用传统 VPN 让工程师连入内网，但权限管理粗放，每个人连上后都能访问所有东西。

迁移到 Pangolin 后，他们实现了：

• • 开发人员只能访问开发环境和测试环境
• • 运维人员可以访问生产环境，但需要 MFA 验证
• • 设计师只需要访问内部的 Figma 代理和设计资源
• • 所有访问都有审计日志

场景三：分布式团队

一家有 50 名远程员工的咨询公司，员工分布在全球各地，需要访问客户的内网资源做项目实施。

他们为每个客户项目创建独立的 Site 和访问策略，员工根据当前项目获得相应权限。项目结束后一键撤销访问权限，避免了权限累积的安全隐患。

5.2 用户真实反馈

从 GitHub Issues 和 Discord 社区的讨论来看，用户对 Pangolin 的评价集中在几个方面：

好评：

• • "终于不用同时维护 Nginx + WireGuard + Keycloak 了，一个平台搞定"
• • "Site 连接器的部署确实简单，5 分钟就在 NAS 上跑起来了"
• • "权限管理比 Tailscale 细粒度很多，能满足我们的合规要求"

槽点和踩坑：

• • 初期文档不够完善，有些功能需要看源码或问社区才能搞明白
• • 部分用户反映高并发场景下性能还有优化空间
• • OIDC 配置对一些非标准 IdP 的支持需要手动调整

5.3 进阶使用技巧

与 CI/CD 集成：可以将 Pangolin 的 API Key 注入到 GitHub Actions 或 GitLab CI 中，实现部署流水线安全访问内部资源。

多地域部署：在不同地区部署多个 Site，配合 GeoDNS 实现就近访问，降低延迟。

备份与恢复：定期导出 Pangolin 的配置数据，灾难恢复时可以快速重建控制平面。

六、部署教程

Pangolin 提供多种部署方式，从最简单的 Cloud SaaS 到完全自托管都有覆盖。

方式一：Pangolin Cloud（最简单）

不想折腾基础设施的话，直接用官方托管服务：

1. 1. 访问 https://app.pangolin.net 注册账号
2. 2. 创建 Organization
3. 3. 下载对应平台的客户端，登录后即可使用
4. 4. 在需要接入的网络上部署 Site 连接器（提供 Docker 一键部署命令）

优点：零运维，有免费额度
缺点：数据走官方服务器，对合规要求严格的场景不适用

方式二：Docker 自托管（推荐）

完全掌控自己的数据：

# 1. 创建配置目录
mkdir -p ~/pangolin/config
cd ~/pangolin

# 2. 下载官方 docker-compose.yml
wget https://raw.githubusercontent.com/fosrl/pangolin/main/docker-compose.yml

# 3. 启动服务
docker compose up -d

# 4. 访问 http://localhost:3000 完成初始化配置

环境要求：

• • Docker 20.10+ 和 Docker Compose 2.0+
• • 至少 2GB 内存（推荐 4GB）
• • 一个公网 IP 或配合内网穿透使用

踩坑提示：

• • 首次启动后需要配置管理员账号，务必保存好初始密码
• • 如果使用自定义域名，提前准备好 SSL 证书或开启自动 Let's Encrypt
• • PostgreSQL 和 Redis 数据建议挂载到宿主机持久化

方式三：DigitalOcean 一键部署

DigitalOcean Marketplace 提供了预配置的 Pangolin 镜像，适合不想手动配置的用户。

✅ 版本要求：建议使用 1.16.0 以上版本，早期版本有一些已知问题已在近期修复。

七、适合谁用 & 不适合谁

适合人群

• • 自建基础设施的技术团队：需要替代传统 VPN，拥抱零信任架构
• • 远程办公的中小企业：员工分散各地，需要安全访问公司内网资源
• • IoT/边缘计算场景：有大量分布在各地的设备需要统一管理
• • 注重数据主权的企业：不希望远程访问数据经过第三方服务器
• • 开源工具爱好者：喜欢自己掌控技术栈，愿意投入时间学习和调优

不适合人群

• • 完全没有技术背景的个人用户：虽然 Cloud 版本相对简单，但相比 Tailscale 等产品的开箱即用还有差距
• • 需要即时企业支持的大型组织：Pangolin 的企业支持体系还在建设中，关键时刻可能无法提供 7x24 技术支持
• • 只需要简单文件同步的用户：Syncthing、Resilio Sync 等专用工具更合适
• • 预算充足且倾向采购商业方案的企业：Zscaler、Cloudflare Access 等商业 ZTNA 方案在合规和支持方面更成熟

决策建议

如果你符合以下条件，建议尝试 Pangolin：

1. 1. 需要同时解决「Web 应用暴露」和「内网资源访问」两个需求
2. 2. 有自托管能力或意愿，希望完全掌控基础设施
3. 3. 对零信任架构有一定了解，愿意接受新的访问控制模型
4. 4. 团队规模在 5-200 人之间，太大或太小可能都不合适

八、局限与避坑指南

主要局限

1. 生态还在早期
相比 Tailscale 等成熟方案，Pangolin 的第三方工具集成、客户端生态还不够丰富。比如没有现成的 Chrome 扩展、VS Code 插件等。

2. 高并发性能待验证
从 GitHub Issues 来看，部分用户反映在数百并发连接的场景下遇到过性能瓶颈。虽然官方在持续优化，但超大规模部署前建议先做压测。

3. 移动端体验有提升空间
iOS 和 Android 客户端功能相对桌面端有删减，部分高级功能（如自定义 DNS、分流规则）暂不支持。

避坑建议

使用前必查：

1. 1. 确认你的身份提供商（IdP）支持标准 OIDC/OAuth2，非主流 IdP 可能需要手动配置
2. 2. 评估网络环境，如果所有设备都在严格的企业防火墙后，可能需要配置额外的 DERP 服务器
3. 3. 查看 GitHub Issues 中是否有与你场景相关的已知问题

生产环境注意事项：

• • 务必配置数据库自动备份
• • 控制平面的高可用需要额外配置，单点部署有风险
• • 定期更新到最新版本，安全修复通常随版本发布

替代方案建议：

• • 如果只需要简单的组网，Tailscale 上手更快
• • 如果只需要反向代理，Nginx Proxy Manager 或 Traefik 更简单
• • 如果预算充足且需要企业级支持，考虑商业 ZTNA 方案

九、写在最后

说到底，远程访问工具要解决的就是「方便连接」和「保证安全」之间的拉扯——既要让合法用户轻松访问资源，又要拦住未授权访问和数据泄露。

传统 VPN 偏向前者，连上内网就完事，安全靠内网边界来扛。零信任架构则倒向后者，每次访问都验身份、过权限，连接只是验证通过后的副产品。

Pangolin 的价值在于用开源的方式把零信任的落地门槛打下来了。不用买昂贵的商业方案，也不用拼凑一堆开源工具，一个平台就能覆盖大部分远程访问需求。

开源地址：https://github.com/fosrl/pangolin
官方文档：https://docs.pangolin.net
官方网站：https://pangolin.net