如何为 HTTP、TCP 和 UDP 选择 ngrok 的替代方案

公共链接解决了一个问题：让别人能够访问您计算机上运行的服务。但这并不能自动解决围绕该服务的所有网络问题。Web 演示、Webhook 接收器和多人游戏服务器可能需要不同的协议、访问规则和连接生存期。

这就是为什么选择 ngrok 的替代方案应从您的工作负载开始，而不是从流行工具列表开始。有用的问题在于实际层面：谁需要访问权限，必须通过哪些流量，以及重新启动连接时会发生什么？

本指南说明了如何将 localhost 暴露给 Internet、比较隧道选项，以及如何避免在首次连接成功后经常出现的配置错误。

1. 将隧道与应用程序匹配

在创建端点之前，请确定您的应用程序实际使用的协议。可运行的 HTTP 隧道并不能证明相同的设置可以转发任意 TCP 或 UDP 流量。

• 网站、API 或基于浏览器的演示： HTTP/HTTPS 隧道（HTTPS、重定向、Cookie 和 WebSockets，如果使用）
  
  
• Webhook 接收器： 公共 HTTPS 端点（正确的路径、签名验证和重试）
  
  
• SSH 服务： TCP 隧道或专用访问（基于密钥的身份验证和受限访问）
  
  
• UDP 游戏服务器： UDP 隧道（所需的端口、延迟和数据包丢失）
  
  
• 使用这两种传输的应用程序： TCP 和 UDP 转发（这两种协议和所有所需的端口）
  
  

检查应用程序的文档：两款游戏可能需要不同的传输协议，并且一项服务可能需要单独的发现或管理端口。

对于混合需求，Localtonet 是一个值得评估的选项。其隧道类型包括 HTTP/HTTPS、TCP、UDP、组合 UDP/TCP 和 TLS。当项目需要的不只是一个临时的 Web URL 时，它就变得很重要。

TCP 和 TLS 之间的区别也很重要。TCP 隧道转发字节流；它本身不保证连接各个部分的加密。检查 TLS 在哪里终止以及应用程序协议是否提供其自己的加密。

2. 了解什么是路由器端口转发的替代方案

传统端口转发将传入连接从路由器的公共地址定向到本地网络上的设备。在运营商级 NAT（通常称为 CGNAT）的后面，或者在无法更改路由器设置时，这将变得不那么简单。

典型的反向隧道的工作方式有所不同。在您的应用程序附近运行的客户端会打开与中继的传出连接。该中继提供一个公共端点，并通过该连接将传入流量发送到配置的本地服务。

这就是为什么 localhost 隧道可以作为端口转发的一种实用替代方案，而无需您拥有自己的公共 IPv4 地址。但是，客户端必须仍然能够访问该中继。网络策略、DNS 问题和出站防火墙规则可能会阻止该连接。

隧道也不会将您的应用程序移至云端。 如果计算机休眠、应用程序崩溃或本地 Internet 连接失败，则即使其公共主机名仍然存在，该服务也可能不可用。为了确保持续访问，请计划让应用程序和隧道客户端在合适的始终开启的设备上运行。

3. 确定访问者是否需要客户端

“支持 TCP”一词不足以描述用户体验。某些工具提供普通应用程序可以连接的公共主机名和端口。其他工具则提供专用访问，这需要在每个连接的设备上安装其他软件。

这种差异对于游戏服务器、外部集成以及无法安装网络客户端的客户尤为重要。

例如，Cloudflare 的已发布应用程序文档解释说，其发布的非 HTTP 服务需要客户端 cloudflared。这与可直接访问的公共 TCP 端点是不同的连接模型。

这两种模型都没有绝对的优劣之分。对于由小型团队进行的管理，专用网络可能是一个不错的选择。当第三方 Webhook 发送方或普通游戏客户端必须在不加入您的网络的情况下进行连接时，公共端点更为合适。

4. 仔细比较免费计划和永久地址

免费的 ngrok 替代方案对于简短演示可能足够了，但不适用于必须在一夜之间保持可访问状态的集成。阅读您所需的隧道类型的限制，而不仅仅是定价页面上的标题。

检查以下详细信息：

• 会话是否到期，以及限制是否因协议而异。
  
  
• 重新连接后端点是否改变。
  
  
• 每月流量、请求或连接配额。
  
  
• 浏览器警告或插页式广告是否会影响预期工作流程。
  
  
• 自定义域、保留端口和访问控制的可用性及成本。
  
  
• 达到配额时会发生什么：限制、暂停或额外收费。
  
  

永久 URL 对于 Webhook 注册、OAuth 回调和书签很有用。对于 TCP 或 UDP 服务，稳定的端口可能与稳定的主机名一样重要。

请记住，保留地址并不能保证正常运行时间。 它保留了用户连接的位置；它并不能使休眠的笔记本电脑或已停止的应用程序保持可用。请将运行可靠性与地址稳定性分开评估。

5. 在共享 URL 之前计划安全的远程访问

加密连接和授权连接是两码事。HTTPS 保护使用 TLS 的连接上的流量，但它并不决定谁应该被允许进入管理仪表板。

对于专用的 Web 应用程序，请使用身份验证并限制只有目标用户才能访问。根据服务，这可能意味着应用程序级登录、身份提供商身份验证、IP 允许列表或控制的组合。

Localtonet 的 SSO 文档描述了 HTTP 隧道前端的身份验证层，每个隧道都可以启用提供商，并提供可选的电子邮件或域检查。这在共享内部基于浏览器的工具时可能很有用。不应将其与任意 TCP 或 UDP 应用程序的身份验证混淆。

机器对机器流量需要采用不同的方法。Webhook 发送方通常无法完成交互式浏览器登录。使用提供商支持的验证方法保护接收端点，并将不相关的管理路由保留在其自己的访问控制后面。

例如，Stripe 的 Webhook 指南建议验证签名并处理重复事件。隧道使端点可达；它不会为您实现这些应用程序检查。

尽可能使用测试数据。避免暴露调试控制台、目录列表、数据库管理面板或生产环境机密信息。不熟悉的公共 URL 不是一种访问控制机制，并且开发服务器可能会暴露比生产部署更多的信息。

6. 测试完整的工作流程，而不仅仅是加载页面

一次性加载主页只是初步检查。有效的隧道测试应该重现对您的项目至关重要的流量和故障条件。

• 首先确认本地访问。 从运行隧道客户端的环境中直接访问该应用程序。验证地址、端口和协议。如果此操作失败，则更改公共端点无法修复本地服务。
  
  
• 检查容器边界。 当客户端在 Docker 容器内运行时，localhost 通常指代该容器，而不是自动指代主机或其他容器。针对您的网络配置使用适当的服务名称或可达地址。
  
  
• 配置最小必要暴露。 转发所需的服务，应用访问限制并避免发布不相关的端口。保持应用程序自己的身份验证处于启用状态。
  
  
• 从本地网络外部连接。 开启移动数据的手机有助于测试浏览器访问。对于 TCP 或 UDP 服务，请使用实际的应用程序客户端并测试特定于协议的行为，而不是依赖通用的 Web 端口检查器。
  
  
• 演练重要功能。 完成登录、跟随重定向、上传代表性文件或保持 WebSocket 连接。对于 Webhook，发送真实的测试事件并检查响应、签名处理和重复事件行为。
  
  
• 测试恢复和清理。 重新启动隧道客户端，中断连接并观察重新连接情况。检查公共地址是否发生变化。测试结束时，停止隧道并验证外部访问是否已关闭。
  
  

测量交互式应用程序的延迟变化和数据包丢失，而不仅仅是峰值传输速度。 从服务器和用户的角度比较中继位置；地理上最近的中继并不总是最快的路由。

7. 选择一种您可以持续操作的工具

考虑在项目结束时，您将如何更新客户端、保护凭据、检查故障和移除访问权限。

Localtonet 提供 Windows、macOS、Linux 和 Android 客户端，以及 Docker 选项。检查在所选设备上的后台运行行为，尤其是手机或笔记本电脑。

对于重复的开发工作，请记录本地目标、协议、公共地址和访问策略。将身份验证令牌存储在源代码控制之外，并避免将其包含在屏幕截图或共享日志中。在设备停用或不再需要访问权限时撤销凭据。

如果服务必须在无人值守的情况下运行，请验证重启后的启动情况，并监控应用程序的运行状况以及隧道的连通性。 已连接的客户端仍可能指向没有响应的应用程序。

当您需要控制基础设施并且可以维护服务器时，自我托管中继可能比较合适。当您希望避免运行该中继时，托管服务可能会更方便。请比较维护负担和订阅价格。

常见问题解答

我可以在没有静态 IP 的情况下暴露 localhost 吗？通常可以。出站隧道可以将本地服务连接到可公开访问的中继，而无需在您自己的连接上使用静态公共 IP。主机、应用程序和隧道客户端必须保持可用，并且网络必须允许所需的出站流量。

TCP 隧道可以代替 UDP 隧道吗？不会自动代替。TCP 和 UDP 是不同的传输协议。如果应用程序需要 UDP，请选择明确支持 UDP 的服务。当应用程序需要这两者时，请确认这两种传输协议和所需的端口均已转发。

localhost 隧道适用于生产环境吗？它可以成为生产架构的一部分，但仅靠隧道并不能构成生产就绪计划。评估可用性、访问控制、监控、流量限制以及主机和 Internet 连接的可靠性。临时开发设置不应悄无声息地变成永久性基础设施。

根据您的实际工作负载进行选择

最适合项目的 ngrok 替代方案是与其协议、用户和操作要求相匹配的替代方案。首先确定您是否需要公共 HTTPS URL、TCP 隧道、UDP 隧道或专用远程访问。

然后测试决定它明天是否能正常工作的详细信息：稳定的地址、身份验证、会话限制以及断开连接后的恢复。对于涵盖 Web 应用程序和非 HTTP 服务的项目，像 Localtonet 这样的多协议选项理应在候选名单之列。在选择它或其他工具时，请基于经过验证的工作流程，而不仅仅是功能数量。