家里有一台跑着服务的机器，可能在家里，可能在公司内网，想让它通过一个域名被外面访问到，这件事听起来简单，做起来会卡在第零步：你多半没有公网IP。宽带运营商给你的地址藏在几层NAT后面，你拿不到一个能从外面直接敲到的入口，端口映射也就无从谈起，很多人就是卡在这里放弃的。
围绕这个限制，市面上有几条老路子。DDNS能解决公网IP会变的问题，但前提是你得先有一个公网IP；frp一类的内网穿透工具能绕开这个前提，代价是你得另外准备一台有公网IP的服务器当跳板，还得自己维护它，带宽、稳定性、被扫描的风险全归你管。这几条路都成立，只是各自都要多摊一份运维成本，对只想跑几个小服务的人来说有点重。如果你手上只有一台机器和几个自用的小服务，这些额外成本往往比服务本身更让人头疼。
它不要求你有公网IP，也不要求你开入站端口
Cloudflare Tunnel走的是一条不太一样的路。按官方说明，它让你在不拥有公网可路由IP的情况下，把资源安全地接到Cloudflare网络上。做法是不再让外面的流量来找你，而是在你的机器上运行一个叫cloudflared的轻量守护进程，由它主动向Cloudflare的全球网络发起连接。官方把这个模型叫仅出站连接：连接一旦建立，流量就能在这条隧道里双向流动，但你始终没有对外开一个能直连的入口。方向反过来了，安全模型也跟着变：不再是把门开一条缝再想办法堵，而是根本不留那扇门。
这个方向上的差别带来了一个很实际的好处。绝大多数防火墙默认允许出站流量，所以cloudflared能顺利连出去；反过来，你可以把入站规则收得很紧，甚至全部关掉，让外部除了Cloudflare之外没有任何途径直接碰到你的源站。传统发布方式要靠打开一个入站端口把服务露出来，端口一开，扫描和攻击就跟着来了；隧道模式下源站压根不监听公网入口，这道口子自然就不存在了。这也是它常被推荐给没有固定公网地址、又不想折腾端口映射的人的原因。
官方文档里还有一个细节值得记住：一条隧道是用一个UUID标识的持久对象，你可以在这同一条隧道里运行任意多个cloudflared进程，官方把这些进程叫作连接器，每个连接器会把流量送到离它最近的Cloudflare数据中心。这意味着你可以把同一份配置铺到多台机器上做冗余，某台掉了，另外的还在，对访问者来说域名那头始终是同一个入口，不需要改动任何外部配置。对手动维护过frp的人来说，这一点的省心程度是能直接感受到的。
隧道能接的内容也不止网页。官方列举的用途里，HTTP服务器、SSH服务器、远程桌面都在其中。这带来的想象空间比想象中大：家里那台NAS的管理界面、开发机上跑着的测试环境、只允许内网访问的数据库管理面板，都可以挂上域名从外面访问，而不必把它们直接暴露在公网上。用法也不复杂，装好cloudflared之后用一条命令登录并关联到账号，或者直接在控制台里创建远程管理的隧道，把本地地址映射到域名路径上。整套流程走下来，不需要你去租一台中转机器，也不需要维护一台长期在线的跳板。
能用域名访问之后，权限这道关还得自己把
要用起来，门槛主要在一个地方：你得有一个域名的解析托管在Cloudflare上。把域名的NS指向它，然后在控制台里创建隧道、把域名绑定上去，剩下的它会帮你把证书这类事处理好。免费计划就能做这些，这也是它被大量个人开发者选中的原因。代价也很直白——你把服务重新放到了公网上，只是换了一个入口，方便和暴露是同一件事的两面。
所以入口打通之后，真正要花心思的是权限。用隧道把内网面板挂上域名，等于把原本只有你能点开的页面，交给了整个互联网去尝试。基本的三件事一件都不能省：管理界面开强密码并且尽早上两步验证，能限定来源IP的接口就限定，不需要长期开放的服务用完就把隧道关掉。官方文档里还提到一点，因为隧道模式不在源站上做入站监听，原本用于校验回源流量的双向认证对它是不起作用的，源站的信任是靠隧道凭据建立的。
内网服务发布这件事，过去卡在公网IP和端口映射上，现在是入口这一头变容易了。好处是你省下了一台跳板机和一堆配置，代价是这套东西的可控范围需要你自己重新想一遍。判断它适不适合你，可以问自己一个问题：如果这个服务明天出现在搜索引擎的收录里，你能不能接受。能接受，隧道是条省事的路；不能接受，先把它关在内网，等把权限想清楚了再挂出去也不迟。
A5创业网 版权所有