★ FEATURED ARTICLE 折腾服务器也有一阵子了真正让我觉得“网络配置是一项系统工程”而不是“把服务跑起来就行”的转折点就是这次 cloudflare-os 项目的经历。简单说这个项目想解决的问题很常见手上有几台不同系统、不同用途的机器有的跑 NAS有的跑下载机有的是测试用的 Linux 发行版但它们散落在局域网里访问起来要么记 IP、要么走网盘中转体验非常割裂。而我想做的是给这些操作系统统一套上一层 Cloudflare 生态——域名解析、证书、反代入口、访问策略全部由 Cloudflare 接管让每一台机器的 Web 服务都能通过一个干净的 HTTPS 域名访问对外只暴露一个入口。这个方案不需要自己买公网 IP不需要在路由器上做复杂的端口映射更不用去记一堆端口号。对玩 NAS飞牛 os、玩刷机比如 esplus 刷飞牛 os 的机器、玩各种 Linux 发行版Cachy OS、Debian、Ubuntu的人来说这套架构能大幅减少日常维护的心智负担。而且 Cloudflare 的免费额度对个人项目来说完全够用成本几乎为零。这篇文章不打算讲得太抽象我会从项目整体的拆解思路开始逐步走到实操层面最后把我踩过的几个坑原原本本摆出来希望能给准备给家里机器做统一入口的朋友节省几个晚上的时间。1. 项目整体设计与思路拆解先聊聊我最初的困惑。为什么标题叫 cloudflare-os 而不是“cloudflare 建站教程”因为项目真正的重点不是搭一个博客而是把 Cloudflare 当成一套“操作系统的配套组件”来用。传统思路下一台 Linux 机器要做公网访问你得先搞定公网 IP、DDNS、路由器端口转发、SSL 证书续期、防护攻击这五个环节只要有一个出问题服务就上不了线。而 Cloudflare 把其中绝大多数环节都吸收了它提供 DNS 托管、CDN 缓存、边缘侧 HTTPS 终止、DDoS 防护还有 Tunnel 方案能让你不开放入站端口直接由边缘节点主动连回你内网的机器。这意味着什么意味着你的操作系统不需要拥有公网 IP不需要在防火墙里开一堆端口甚至连证书都不用在自己机器上安装。所有入站流量先到 Cloudflare 的边缘再由 Cloudflare 决定是否转发到你机器上的某个本地端口。对这个项目来说我把它看作一次“操作系统外围基础设施”的重构。1.1 为什么要用 Cloudflare 而不是市面上其他内网方案市面上可以把内网服务暴露出来的工具并不少常见的就有 frp、ngrok、花生壳等很多朋友也玩过。我最终选择 Cloudflare主要是基于三个维度的考量。第一是稳定性和域名归属。frp 需要一台有公网 IP 的中转服务器这台服务器的带宽、流量、可用性都要自己维护出了问题排查链路非常长。而 Cloudflare 的骨干网规模和容灾能力是个人自建很难达到的把服务挂在这一层相当于把网络可用性的短板外包给了头部厂商我自己只需要关注操作系统这一层就行。第二是生态整合度。Cloudflare 能在一个控制台里批量管理 DNS、缓存规则、防火墙策略、访问身份验证、日志监控这和我给家里多台设备做统一规划的目标高度匹配。比如我可以在 Dashboard 里一键给某个子域名加上 Access 身份验证要求访问者通过邮箱验证码才能进入管理后台或者给下载站单独配置缓存规则这些操作不需要改动任何服务器代码。第三是免费额度够用。免费套餐包含 50 条 DNS 记录、无限流量对合法普通站点来说Tunnel 服务本身也不收费。个人和家庭实验室场景几乎没有被打爆的风险性价比无可挑剔。当然这套方案也有缺点最大的问题就是 Cloudflare 的节点在某些网络环境下访问质量不稳定国内用户访问速度可能不太理想。如果你主要服务对象是国内用户可能需要另加备案和 CDN 方案但如果是自用、海外节点应用、或者面向海外用户这个组合就非常顺手。这也是我在方案选型时反复权衡的一个点不要因为别人说某个工具好就无脑上你得先搞清楚你的流量特点和使用者分布。1.2 项目架构选型哪台机器承担什么任务我手上机器大概分三类。第一类是主力 NAS跑的是飞牛 osfnOS主要承担文件存储、相册备份、下载任务。第二类是性能测试机装了 Cachy OS 和一些容器化服务跑开发测试用的数据库和 API 服务。第三类是一台刷了 Debian 的小主机常年跑监控脚本和反向代理转发。如果把所有任务都塞到一台机器上统一管理确实省事但风险也大一个服务崩溃或者系统升级出问题所有服务全部中断。所以我最终决定让每台机器保持各自职责然后在每个操作系统内装一个 Cloudflare Tunnel 客户端让它们各自和 Cloudflare 边缘建立一条出站连接。这样形成了非常漂亮的拓扑每台内网机器只主动向外发起 HTTPS 连接不需要入站端口。Cloudflare 作为统一入口把域名流量按主机名路由到对应 Tunnel。用户访问 https://xxx.example.com 时请求经过 Cloudflare 边缘处理后直接沿着 Tunnel 到达内网对应服务。这个设计的好处是即使某一台机器彻底挂了其他机器的服务依然可以通过各自 Tunnel 正常工作互不影响。这也符合我对“操作系统集群”的理解不在于机器数量多而在于每一台机器都在它该在的位置上。2. 核心细节解析与实操要点架构听起来很简单但真正落地时你会发现细节全藏在系统初始化和客户端配置里。这里先说几个我认为最关键、最影响成败的环节如果你的环境和我类似可以直接照着抄。2.1 操作系统初始化的几个基础动作很多人装完 Linux 第一件事是装 Docker、配防火墙这样容易给后面埋雷。我在这轮项目里的经验是先做基础配置再上应用层。具体来说包含以下几步。第一步是更新系统和安装必要工具。不管是飞牛 os 这种面向 NAS 的发行版还是 Debian、Cachy OS装好之后第一件事就是apt update apt upgrade或者对应的包管理器更新命令把内核和基础软件包拉到最新。这一步能避免很多因为系统组件版本过旧导致的兼容性问题尤其是内核模块和文件系统相关的 bug。第二步是配置好主机名和时区。Tunnel 建立后仪表盘上显示的主机名和状态信息都来自系统自身如果主机名乱糟糟的排查问题时分不清哪台是哪个服务。建议用一个清晰规则比如nas-01、dev-02、monitor-03一眼就能分辨。时区建议统一为 UTC8避免日志时间出现歧义。第三步是创建一个专用的服务账号不要用 root 直接跑 cloudflared。虽然 root 能跑通但一旦 Tunnel 配置文件或者客户端进程被入侵攻击者拿到的就是 root 权限代价太大。我用的做法是新建一个名为cloudflared的系统用户只给它读取配置和运行服务的权限这样即使出问题影响面也被限制了。这三步大概花十分钟但后续价值非常大。我见过不少朋友跳过这些步骤直接装服务之后排查问题时光分辨日志就浪费了大量时间。2.2 cloudflared 安装架构和版本要对上cloudflared 是 Cloudflare Tunnel 的客户端组件名字可能有点陌生但它的作用非常直接建立一条从你的机器到 Cloudflare 边缘的出站连接并在本地维护一个路由表决定哪些内网服务可以被外部访问。安装时最容易出错的坑就是 CPU 架构没选对。多数家用服务器是 x86_64 架构但是不少新出的 NAS 和开发板是 ARM64。如果你在 ARM 设备上装了 x86 版本的 cloudflared立刻会报Exec format error服务起不来。下载前先跑一下uname -m确认架构再去官方下载对应版本这个习惯能帮你省掉一个很隐蔽的坑。以最常见的 Linux amd64 机器为例你可以直接从 GitHub Releases 拉取二进制wget -q https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O /usr/local/bin/cloudflared chmod x /usr/local/bin/cloudflared cloudflared --version放到/usr/local/bin的好处是路径已经在系统环境变量里后续任何地方都可以直接调用。当然如果网络环境拉 GitHub 不稳定也可以从 Cloudflare 官方仓库添加 apt 源安装具体方式官方文档写得很清楚这里就不展开了。2.3 Tunnel 创建与认证绑定安装好客户端以后第一件事不是直接改配置文件而是先做登录认证。执行cloudflared tunnel login这时终端会打印一个授权链接。在浏览器打开登录 Cloudflare 账号选择你要绑定的域名授权后客户端会自动把证书保存到~/.cloudflared/cert.pem这个位置。之后创建 Tunnelcloudflared tunnel create my-home-os创建成功后会生成一个 Tunnel ID以及对应的 JSON 凭证文件路径一般是~/.cloudflared/tunnel-id.json。这个 JSON 文件非常关键它相当于 Tunnel 的身份证只能放在目标机器上不要随手传到网盘或者 Git 仓库里。这里有一个容易忽略的细节Tunnel 创建之后你可以在任意多台机器上用同一个 Tunnel ID 运行客户端Cloudflare 会自动做负载均衡。但这个模式不适合我的场景因为多台机器共用 Tunnel 会导致路由入口混淆。我更建议一台机器一条 Tunnel然后通过域名把流量区分开。2.4 通过路由表把域名绑定到本地服务创建好 Tunnel 之后需要把对外域名和本地服务对应起来。这一步是在 Cloudflare 控制台完成也可以直接用命令行cloudflared tunnel route dns my-home-os nas.example.com cloudflared tunnel route dns my-home-os dev.example.com这样会自动生成一条 CNAME 记录指向tunnel-id.cfargotunnel.com。你在 DNS 面板能看到这条记录一般不需要手动改只管保持它存在就行。之后流量就能从公网域名下钻到 Tunnel 客户端接下来要交给客户端做最终分发。2.5 配置 ingress 规则把流量导给不同端口cloudflared 的配置文件是config.yml这里的核心概念是 ingress 规则也就是定义“每个域名分别转到本地哪个端口”。在我的环境里配置大概是这样的tunnel: my-home-os credentials-file: /root/.cloudflared/tunnel-id.json ingress: - hostname: nas.example.com service: http://127.0.0.1:80 - hostname: dev.example.com service: http://127.0.0.1:8080 - hostname: files.example.com service: http://127.0.0.1:8096 - service: http_status:404规则从上往下匹配匹配到第一条就停止最后必须有一条 catch-all 规则否则服务启动会报错。http_status:404的作用是让拿到 Tunnel IP 但没匹配到合法主机名的请求直接返回 404避免端口扫描时暴露内网服务。这个细节我强烈建议保留它相当于一个免费的访问屏障。配置完成后用命令验证cloudflared tunnel ingress validate它会提示你配置文件是否符合规范。确认无误后直接运行cloudflared tunnel run my-home-os如果看到Registered tunnel connection的日志说明连接已经建立了。这时从外网访问对应域名只要 DNS 生效请求就能穿透进来。为了让服务在重启后自动拉起建议安装为系统服务cloudflared service install systemctl enable cloudflared systemctl start cloudflared之后即使机器重启Tunnel 也会自动恢复真正做到无人值守。3. 实操过程中的关键环节和参数选择理论上把配置写好就大功告成但实际操作中网络链路、服务类型、客户端模式这些变量会让同样一份配置在不同机器上产生完全不同的表现。我按实操顺序把几个关键节点重新捋一遍顺便讲清楚每个选择背后的理由和参数逻辑。3.1 网络侧准备本地服务和 DNS 的一致性Tunnel 建立后Cloudflare 会把公网请求转发到你的客户端再由客户端转发给本地地址。这个本地地址可以是127.0.0.1也可以是局域网内的其他 IP。我的建议是尽量用回环地址因为本机服务的端口只监听回环接口这样可以避免局域网内其他机器直接访问到你的服务减少暴露面。举个例子如果 nas.example.com 对应飞牛 os 的管理面板默认端口是 8000那你可以在飞牛系统的服务设置里把监听地址改成127.0.0.1:8000然后 Tunnel 的 ingress 规则就指向这个地址。这样从公网访问是通的但在内网用其他设备直接访问 IP 反而访问不了等于天然加了一道访问限制。有一种情况例外如果你希望内网其他设备也能直接通过局域网 IP 访问那就必须监听0.0.0.0。这时你的网络里所有设备都能直接看到服务利弊自己权衡。对我而言管理面板只要能访问就行访问途径越少越安全。3.2 证书处理边缘完整加密链路Cloudflare 默认使用的是它自己的边缘证书也就是说公网到 Cloudflare 这一段是 HTTPS但从 Cloudflare 转发到本机服务的这一段默认是 HTTP 明文。很多人第一次接触会担心这段链路不安全其实在 Tunnel 场景中流量只会在你自己机器和 Cloudflare 机房之间的加密隧道里传输中间不经过其他网络所以安全级别非常高不需要额外搞自签证书。如果你有强迫症想实现边缘到本机也是加密的可以把 ingress 规则里的service改为https://127.0.0.1:8443并在本机服务上配置证书。这个做法收益很小还会增加证书配置的复杂度我个人不建议在家庭实验室场景里折腾。除非你有合规需求比如金融医疗类项目否则边缘加密已经够用。TLS 版本和加密套件也可以直接在 Cloudflare 控制面板调默认的 TLS 1.2/1.3 配置足以满足绝大多数场景。唯一要提醒的是如果你给某个域名开了“Full (strict)”模式而本机证书是无效的那么访问会直接报 526 错误这是需要留意的不要过早开启。3.3 多个服务共用 443 端口本地端口冲突的处理Tunnel 模式下公网所有流量都走 443 端口进入边缘边缘侧按 SNI 和 Host 头分发到不同 Tunnel 和不同本地端口。这意味着本机不需要监听任何公网端口本机内部各服务可以用任意端口根本不用关心端口冲突的问题。比如 dev.example.com 和 files.example.com 都在同一台机器上一个服务监听 8080一个监听 8096它们互不干扰。如果你之前是用端口映射的方式比如 8080 映射 http、8096 映射 https那需要维护一长串端口规则现在这些全部消失了。端口管理成本大幅下降这是在操作系统层面能明显感知到的变化。3.4 缓存与源站配置对系统性能的影响Cloudflare 作为 CDN默认会缓存一部分静态资源。对博客、文档站这类页面缓存能显著加速访问但对动态接口、管理面板缓存反而会造成数据不刷新。我在配置时为不同域名设置了不同 Cache Level静态资源站Cache Level 设为 Standard缓存静态文件。管理后台Cache Level 设为 Bypass全部请求回源。下载站大文件Cache Level 设为 Standard同时开启 Brotli 压缩。这些设置都在 Cloudflare 控制台的 Caching 区域操作不需要动服务器代码。这么做的本质是让边缘层为源站减负源站系统只需要处理真正的动态请求CPU 和 IO 压力都小很多。3.5 安全参数防火墙只出站不接入站Tunnel 模式下的典型安全配置是本机完全不开放入站端口防火墙默认 DROP 所有入站流量。这种模式下即使有人扫到了你家的公网 IP也什么都扫不到因为根本没有入站监听端口。具体操作用 UFW 为例sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp comment ssh management sudo ufw enable22 端口留一个口子是为了自己远程登录方便如果你用密钥登录且不怕麻烦也可以连 22 都不开等于把所有入站全封死。这是 Tunnel 方案对比传统端口映射最大的安全优势——攻击面肉眼可见地缩小了。3.6 访问控制在边缘增加一层身份验证Cloudflare 的 Zero Trust Access 可以和 Tunnel 无缝配合给任何域名增加身份验证门槛。我只用了最简单的配置允许指定邮箱后缀的账号访问管理后台其他人一律拦截。这可以有效避免公开域名被随机扫描到后台登录页。开启方式是在 Cloudflare Zero Trust 控制台创建一个 Access Application选择域名和应用类型再配置 Access Policy。整个过程不需要改本机任何代码边缘侧就能拦截未认证的请求。对家庭实验室来说这个功能用好了可以让你放心地把服务暴露在公网不用整天提心吊胆担心弱口令爆破。4. 常见问题与排查技巧实录纸上谈兵容易真正跑起来你一定绕不开几个高频问题。这里我把项目过程中踩过的坑按出现频率排序整理成一份速查表能帮你快速定位到问题点。现象可能原因解决思路访问提示 502 / 530Tunnel 断开或本机服务没起来检查 cloudflared 进程和系统服务提示拒绝访问 (os error 5)文件权限或服务运行用户权限不足检查日志文件、配置目录属主和权限yum repomd.xml errno -1系统包管理器无法获取仓库元数据检查网络连接和 DNS换源overlay2 文件占用大Docker 容器和镜像残留日志凝聚清理悬空镜像、重建日志策略访问延迟高边缘节点距离远或源站响应慢开启缓存、选对地区、优化后端接口4.1 报错拒绝访问 (os error 5)权限问题排查实录项目前期我遇到最多也最恼人的错误就是error: 拒绝访问。 (os error 5)。这个错误日志出现过两种不同场景。第一种是在运行cloudflared tunnel login时提示无法写入配置文件到家目录第二种是在运行后台服务器相关命令时提示需要重新运行但一直失败。os error 5 本质上就是 Linux 的 EACCES也就是权限不足。意思是进程想操作某个文件或目录但系统认为它没有权限。排查思路非常直接先看正在执行命令的用户是谁再看目标路径的用户是谁。我有一台机器是用 root 跑的 cloudflared但凭证文件是另一个用户创建的启动服务时读取不到错误自然不断。解决办法是统一权限归属。最简单的方式是让服务账号与凭证文件属主一致chown -R cloudflared:cloudflared /etc/cloudflared /var/lib/cloudflared chmod 600 /var/lib/cloudflared/*.json如果你在别的系统上看到类似 os error 5也可以举一反三往/etc写配置、往/var/log写日志、往/run写 pid 文件都会触发同类错误。总结成一句话看到 errno 5先不要改代码先查 ownership 和 mode。4.2 CentOS 系系统 yum 仓库报错 errno -1除了 Tunnel 本身的权限问题系统包管理器也可能出幺蛾子。项目里一台 CentOS 7 机器的 yum 一直报类似这样的错误http://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml: [Errno -1] ...errno -1 通常是 HTTP 连接失败可能是超时、被断开或网络不通。我在排查时先确认了外网连通性发现ping通但curl这个地址失败断定是 DNS 解析到的是一个访问不通的镜像节点或者镜像源做了变更。解决方案也很传统把/etc/yum.repos.d/下的源地址切换为可用镜像或者直接用sed替换方案。我也把这个经验延伸到所有发行版上操作系统的基础源是维护流程的第一步它挂了后面什么都装不了。建议在项目初期就检查好源地址可用性不要等到报错才处理。4.3 Docker overlay2 目录占用磁盘空间过大飞牛 os 带 Docker 场景下经常会遇到/var/lib/docker/overlay2目录越滚越大磁盘紧张的情况。这个目录是 Docker 的存储层每层镜像以叠加方式存放。日常运营造成的空间上涨主要来源有两个历史镜像残留和容器日志垃圾。清理日志最有效的方式是限制日志文件大小在 Docker daemon 配置中加入{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }然后重启 Docker再清理无用镜像docker system prune -a --volumes第一次清理可能直接释放几十 GB 空间效果立竿见影。如果你跑了很多服务还可以用docker stats看每个容器资源占用把常年不用的容器停掉。这个清理动作建议每个月做一次把它当成给操作系统做例行保洁。4.4 HP 主机安装飞牛 OS 后网络唤醒配置还有一个比较偏门的坑HP 主机安装飞牛 os 之后网络唤醒功能不生效。这个问题严格来说不是 Cloudflare 层面的但它影响了我的远程管理体验。如果你也希望在外网通过 Cloudflare 访问内网机器、需要远程唤醒设备可以参考我的排查顺序。先确认 BIOS 里是否开启 Wake on LAN这一步是前提。然后在操作系统里用ethtool查看网卡功能状态ethtool enp2s0 | grep Wake-on如果输出是d代表禁用用命令临时开启ethtool -s enp2s0 wol gHP 主机还有个特殊之处部分型号在完全断电后网卡会断电网络唤醒就无法生效。需要确保机器通电状态是 S5 待机而不是 S5 断电这在 BIOS 里需要找到类似“After Power Loss”的选项设置为 Always On。飞牛 os 本身没有图形化的网络唤醒配置选项必须在系统层级配合网卡驱动去做。如果你用其他系统思路同理先硬件、再固件、再驱动、再软件逐层排查。4.5 关于 OpenHarmony OS 和其他系统兼容的补充热搜词里经常有人问 OpenHarmony OS 是用什么语言编写的这类问题的答案其实也适用于理解系统兼容性OpenHarmony 底层主要是 C/C上层应用开发支持 ArkTS、JS 等语言。这跟 cloudflared 客户端无关但涉及到一个共通原则操作系统层面的工具链是否兼容直接决定了一个生态能否顺利落地。Cloudflare Tunnel 官方客户端目前并不支持在 OpenHarmony OS 上跑原因就在于系统 ABI 和文件结构差异太大。同理很多人想把云原生工具装到各种“魔改 OS”上结果发现服务起不来。我的建议是不要为了跑一个工具去魔改系统而是选择官方明确支持的发行版要么直接用自己的 Ubuntu/Debian 环境要么用官方容器镜像跑这样能省去大量时间。5. 一些真正值得做的扩展与实践体会项目跑稳定以后我开始逐步往里面叠加新能力。Cloudflare 这套底座的价值不在于“把域名解析到内网”这一刻而在于后续每个能力都可以平滑地叠加不用推翻重来。这里分享几个我认为性价比最高的扩展方向以及我个人的一些体会。5.1 从 NAS 到开发机的全链路统一目前我的主力 NAS 和开发机都接了 Tunnel飞牛 os 上的文件服务、相册服务、下载服务全部通过独立子域名访问。Cachy OS 上的开发服务则通过另一个子域名暴露供团队在公网环境下调试接口。这样做的好处是团队成员只需要记住一个顶级域名前缀就能按子域名找到对应服务不用再维护一长串 IP端口表格。如果你也有多台机器建议先明确每台机器的角色再配置 Tunnel。不要一开始就把所有服务堆在同一台机器上否则后续故障影响范围会很大。每个服务尽量做端口隔离系统账号尽量独立避免一个漏洞导致全盘沦陷。5.2 结合网络唤醒的远程协同体验前面提到网络唤醒我把它和 Tunnel 方案组合起来之后形成了一套完整的远程开机到访问链路。在外网访问时先通过 Cloudflare Access 进入一个简单的唤醒页面点击按钮发送 Wake-on-LAN 魔术包给局域网内的目标机器机器启动后自动拉起 cloudflared 服务Tunnel 建立连接我就能继续访问它的各类服务。整个过程不需要任何人在现场操作体验上和云服务器没有区别。这个组合是典型的“操作系统层”玩法你管理的不是一台机器而是整批机器的生命周期。对家里有多台 Linux 设备的朋友来说这种体验会带来很强的掌控感。5.3 监控与告警别等挂了才想起修Tunnel 本身自带流量和服务状态监控面板在 Cloudflare Zero Trust 的 Tunnel 页面能看到每条 Tunnel 的连接状态和最近流量。但我在实际操作中发现这个监控只有在你主动登录后台时才能看到不具备主动告警能力。所以我额外搭了一个简单的健康检查脚本每五分钟对本地的几个关键端口做一次curl探测失败就推送通知到 Telegram Bot 或邮件。这种脚本成本非常低但价值极高。家庭实验室环境不稳定因素多路由器重启、光猫断电、系统升级卡住都可能让 Tunnel 静默掉线。如果你只有一两个服务还能忍服务多了以后没有告警基本等于裸奔。我强烈建议把这个健康检查纳入标配。5.4 我最想提醒新手的三个习惯第一个习惯所有配置文件都用 git 管理。cloudflared 的 config.yml、系统初始化脚本、docker compose 文件都放到同一个仓库里改了什么、为什么改都有历史记录。出问题时回滚非常快。第二个习惯不要忽视防火墙默认策略。很多人装了 UFW 以后只想着允许某些端口没有把入站默认策略设为 Deny结果服务暴露范围比预想大得多。第三个习惯日志是排查问题的第一优先级。任何报错出现第一反应应该是看对应服务的日志而不是盲目重启服务否则会错过最关键的现场信息。这三个习惯让我在项目过程中少走了非常多的弯路分享出来也算是一种有价值的回馈。最后再说一句关于这套架构的真实体会。Cloudflare 生态加自建系统某种程度上让我重新理解了“稳定”这个词稳定不是指某一台机器永远不出故障而是当一部分故障发生时其余系统还能不受影响地继续工作。Tunnel 的接入方式天然弱化了对公网 IP 和单点端口的依赖操作系统本身被当作可替换的组件这反而让系统变得更有韧性。如果你也正在为设备的对外访问发愁不妨先把 Tunnel 跑起来把域名解析全部归到 Cloudflare你会发现后续很多事情都顺了。
阅读完成 · 觉得有帮助？
的研发阶段实践)
