Newshot
Account

新手用树莓派自托管网站，如何不依赖第三方服务保障安全

Source: Lobsters Published: Developers English
AI summary

一位自托管新手在论坛求助：他手上有树莓派，想用来托管自己的静态网站，未来可能加更多服务。有人建议用 Cloudflare Tunnels 做安全防护，但他觉得依赖这类服务商违背了自托管的初衷，因此想了解能否只用开源工具实现，以及会遇到哪些坑。

Translation(model translation, not the source's own text)
This piece is long: the translation covers roughly the first 55156 characters. Use the language link above for the other version.
  • 108 究竟怎样才能安全地自托管？☶ 提问 devops 作者 pralkarz 2026-11-11 06:01:19 | 59 条评论

究竟怎样才能安全地自托管？

我明白这个标题相当含糊，但我在自托管方面完全是个新手，所以我想，鉴于我有时在评论区看到的讨论，这里会是一个寻求指点的不错地方。我先试着通过 DDG 和 Google 做了些研究，但（我承认这可能是能力问题）我找到的大多数内容要么是 SEO 垃圾，要么是在试图推销/营销某种服务。

再补充一些背景，并给出一个具体例子说明我感兴趣的方向：我搞到了一块 Raspberry Pi，想用它开始捣鼓自托管。我的主要目标是在上面托管我（静态的）网站，未来可能还会添加更多东西。

我问过的一些人推荐了 Cloudflare Tunnels 之类的方案来保证安全，但使用这样的提供商几乎感觉违背了自托管的初衷，所以我很好奇用开源工具来做是否可行、可能会遇到哪些坑，以及你对此话题的总体看法。

（另外，欢迎推荐 devops 以外的标签，我觉得 security 不太适用，因为这是一个问题，而不是关于安全的文章/资源。）

  • 34 mw 2026-11-11 06:56:24 太对了。我很喜欢这个问题。听起来你想要的可能是“除了我没人能读我的数据包！”如果是这样，我会去看整条链路。你需要把流量路由到 pi。用 DNS 把主机名解析到静态 IP，然后还需要某种方式在内部网络上从静态 IP 路由到你的 pi。你需要一个有效的密钥和证书，这样你提供的流量才会被其他浏览器认定为安全（密钥和证书）。你需要 TLS，并且要刻意在你能控制的某个地方终止 TLS。这三件事高度交织，“自托管”就是选择你想自己拥有其中哪些环节。我个人最喜欢的方案：从任意服务商租一台 $5/月的机器（什么都行——vultr、linode、digital ocean、hetzner），用你的 pi 通过 ssh 连到租来的机器，把 443 端口转发到你的 pi。在终止 TLS 的那一端（最终是你的 pi）上运行 acme.sh。我喜欢这个方案有几个原因。它提供了一个可以指向 DNS 记录的静态 IP 地址。它也不会暴露你住在哪里。你可能在意也可能不在意这一点。但它还意味着你会花更多时间学习互联网，而不是跟家庭网络上的端口转发较劲。只要你的 pi 能碰到互联网，它就能找到你的机器。这意味着你可以把 pi 用胶带绑到一台 mint mobile 热点和一块太阳能板上，在任何有阳光的地方提供你的静态站点。我总想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我不知道为什么，这让我微笑。因为你用的是 ssh，所以存在 TLS over TLS。但这其实无所谓。重点是，在你和用户之间，除了你的 pi 之外没有人能看到任何东西。当你最终从 ssh 端口转发迁移到更稳定的方案时，其他一切都不变。当你最初搭建和调试时，你在 pi 上做的任何事都可以在租来的 $5 机器上做。它稍微更稳定，也更接近将来真有人付钱让你做的事。你最终可能会在某处用 nginx 或 haproxy 来对齐端口。但你也可以用 iptables。随你选。Tailscale 和 Cloudflare tunnels 真的很酷。它们省掉了一些头疼，但你说得对，它们放弃了一点安全性（以及学习机会！）。我真为你兴奋 :) 告诉我进展如何！16 johnklos 2026-11-11 11:50:41 我刚带着我的备份 MX 开车横穿美国。我的手机提供热点，一台 GL.inet 做 tethering 并提供互联网，我的备份 MX 运行一个 tinc 隧道来给自己一个公网 IP。因为我的备份 MX 靠 5 伏（USB 供电）运行并且有电池备份，我用点烟器 USB 电源适配器给它供电，但它也完全可以由我的太阳能板供电（我把太阳能板穿过掀背车窗 :) ~ quindarius 2026-11-11 12:45:06 太酷了兄弟 8 dsschnau 2026-11-11 07:59:06 我总想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我得承认我也笑了。~ dzwdz 2026-11-11 10:22:28 我不确定 acme.sh 是不是最好的选择。另外，对很多自托管场景（家里有服务器，想从其他设备访问上面的服务），我认为 Tailscale 是杀鸡用牛刀。纯 WireGuard 配置起来简单得令人愉快。当然，它有一些好处——它有 NAT 穿透，足够聪明能找出比你在最简单的纯 wg 配置里大概率会得到的星型拓扑更高效的路由，它还有花哨的多用户支持——但你真的需要这些吗？5 gecko 2026-11-11 10:40:11 我使用 Tailscale 而不是 WireGuard 的原因（唯一的原因！）是 Tailscale 到处都有原生应用（关键包括 Apple TV 和 Google 当红的流媒体设备），而 WireGuard 没有。[1]。考虑到我用 Tailscale 不用花任何钱，至少对这个特定用例来说，这让我觉得值得。[1]：嗯，有

一个 Apple TV 上的付费订阅应用，我可以越狱那个 Google 设备，但为了让我能访问 Jellyfin 文件而投入的精力是有限的。~ altano 2026-11-11 11:59:35 WireGuard 在 tvOS 上可用。纯正的、免费的、开源的 WireGuard。~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。2024 年或 25 年时这还完全不成立 ~ altano 2026-11-11 12:13:46 呃，我那么确定，然而……我想我是幻觉了。似乎并不可用。~ weberc2 2026-11-11 11:19:09 我认为 Tailscale 是大材小用。纯 WireGuard 配置起来令人愉快地简单。我一直听到这种说法，但我还没见过有人解释如何让它顺利工作，而我对 wg 的所有尝试都是令人沮丧的练习（并不是说 Tailscale 就毫无痛苦）。让隧道启动并运行没问题，但弄清楚如何防止隧道崩溃或静默不转发流量要困难得多。另外，我不太确定在没有 Tailscale 的情况下如何让 wireguard 在我的 Apple TV 上工作。~ weberc2 2026-11-11 11:12:12 用你的 pi 通过 ssh 连接到租用的盒子，将 443 端口转发到你的 pi 当我尝试这个时，SSH 隧道总是崩溃并需要重新创建。似乎至少需要一个控制循环来监视它，但即便如此，有时故障不是“SSH 进程消失了”，而是它活着但静默不工作，我无法弄清楚如何从运行在 pi 上的控制循环检测这种情况，所以我不得不每月手动踢它一两次。~ twm 2026-11-11 13:05:06 根据我的经验，通过设置 ServerAliveInterval 使始终有少量流量，可以让 autossh 获得不错的可靠性。你也可以设置 TCPKeepAlive，但由于它在 TCP 层操作，会受到中间盒的影响，我猜这在移动网络上是一个特别的风险。但我确实同意 SSH 不是这里的正确工具。30 marginalia 编辑于 2026-11-11 10:15:26 作为一个长期把东西公开放在网上的人，我会说做到以下几点就能达到 95%：定期更新系统 在 SSH 上禁用密码登录 在非标准端口上运行 SSH（低成本的自动化路过入侵尝试，现实地说，是这类东西的主要威胁向量，所以减少你的目标轮廓确实有帮助，即使你奶奶都能运行 nmap 找到你隐藏的端口）设置 UFW（或类似工具）并阻止所有不应可访问的端口 如果你没有 docker 网络方面的博士学位，不要使用 docker，因为它很容易帮你防火墙上打洞 对于任何你只想自己访问的东西，把它放在 caddy 或 nginx 后面并添加 basic_auth。永远不要信任 Web 应用的登录界面来保护你的安全。你可以用 fail2ban 进一步改进这一点。客户端证书是进一步提升水平的一种方式，但设置起来有点麻烦。仅 basic_auth 就能走很远。~ quindarius 2026-11-11 12:46:53 这里有好东西 20 tuxes 编辑于 2026-11-11 06:27:56 从非公开面向的服务开始更安全，例如在你的手机、笔记本电脑和 Raspberry Pi 上安装 Tailscale，然后开始设置你为自己想要的服务。我问过这个问题的一些人推荐 Cloudflare Tunnels 之类的解决方案来使其安全，但使用这样的提供商几乎感觉违背了自托管的初衷 我喜欢自己端到端地做，但有时我就是懒得弄，所以使用 Cloudflare Tunnels 让它工作，这对我来说比完全放弃是更好的结果。8 pralkarz 2026-11-11 07:10:52 我多次听说过 Tailscale，但说实话，他们的网站对我来说读起来和企业邮件一样，也就是说我无法从中消化任何实质内容（我知道，可能是另一个技能问题）。你介意分享一些具体的用例吗（例如你用它做什么的例子）？那可能让我更容易理解 c

概念。 18 brn 2026-11-11 07:15:40 我觉得最简单的解释是：Tailscale 让你所有的设备表现得就像它们处在同一个家庭网络上，无论它们实际位于何处。 ~ tuxes 2026-11-11 07:18:12 他们 2020 年的网站说得更清楚一些：https://web.archive.org/web/20201129111934/https://tailscale.com/ 但基本上，它让你的各种设备彼此连接，无论它们在哪里，都无需处理端口转发、防火墙、动态 DNS……这样你的手机或笔记本电脑就能访问树莓派上自托管的服务（照片、Jellyfin、RSS、文件……）。它在做到这一点的同时，把这一切对随机路人和攻击者隐藏起来。我不用 Tailscale，而是只用普通的 Wireguard/mTLS，但 Tailscale 最容易搭建，似乎也是那些想在外出时访问自己树莓派的人最流行的选择。 ~ ceph 2026-11-11 10:21:48 我主要把它用作个人的“私有内网”；我在家里的 homelab 机器上托管 Grafana 和 Forgejo 之类的服务，然后把它们接入 Tailscale，这样我就能通过 tailnet 远程访问它们，而无需把它们放到公网上。额外的好处是它还提供“funnel”，一个公共反向代理，其工作方式与向 tailnet 提供服务相同，从而避免了为提供这些服务而需要公网 IP。与传统 VPN 不同，Tailscale 本身并不通过其基础设施来隧道传输流量——控制平面服务器负责管理访问和路由，但流量是通过建立点对点的 WireGuard 隧道来传输的，Tailscale 运营着中继，在需要时（例如 NAT 穿透）在机器之间转发加密数据包。话虽如此，你确实放弃了一定程度的自托管——你可以租一台便宜的 VPS 并搭建例如 Headscale 来获得相当一部分功能（不过我个人还没亲自试过）。 ~ alethkit 2026-11-11 10:25:01 在我看来，关于 Tailscale 为何诞生，最好的高层概述是 https://tailscale.com/blog/two-internets-both-flakey ~ cyberia 2026-11-11 12:29:48 Tailscale 不错，但如果你想学点东西，我建议手动搭建 WireGuard 隧道。我的设置是一台云 VPS（在 OVH 上）运行 TLS 终止，将流量转发到我的 homelab 服务器，后者通过 WireGuard 连接到 VPS。这样，我的家庭 IP 不会公开可见，它变不变也无所谓——我的 homelab 服务器只需重新连接隧道，云 VPS 就通过其 WireGuard IP 来寻址它。 ~ frontsideair 2026-11-12 01:18:39 在这里无耻地自我推销一下，因为我那篇讲解如何用 Tailscale 进行自托管的博客广受好评，所以可能有用（我当时甚至用的就是树莓派！）https://blog.6nok.org/tailscale-is-pretty-useful/ ~ hafiz 2026-11-11 07:55:04 具体例子：假设你想要一台任务服务器，你可以通过一个稳定的标识符访问其仪表盘，它运行在一台隔离的机器上，且不暴露在公网上。那么 Tailscale 就是个很好的解决方案。其他例子：隧道进入不应暴露在互联网上的其他 VPC；在网络内的成员之间共享本地演示；当你当前所在的网络不可信时，用某台特定机器作为出口节点；通过稳定 ID 访问你的设备（例如我有一组 IP 是动态的 Mac，但我可以通过屏幕共享用稳定 ID 登录） ceph 2026-11-11 10:21:49 [评论已被作者删除] ~ creesch 2026-11-11 10:24:49 它就是一种为你的家庭网络搭建 VPN 的方式。它吸引人的地方在于，你不需要为家里准备一个静态 IP 来连接，因为他们通过自己的服务器进行路由，而且搭建极其简单。但这也意味着你在信任他们。就我个人而言，我家里确实有静态 IP，我的路由器也支持 WireGuard，所以我用的是那个。一回事。 14 simonw 编辑于 2026-11-11 08:25:45 这段对话里已经提到 Tailscale 十次了，我要让它变成十一次。它确实解决了家庭实验室

安全问题上做得如此出色。把它运行在你的设备上——它在所有设备上都能用（我甚至在 Apple TV 上也装了），安装和配置都极其简单。现在你的手机或笔记本电脑，无论身处世界何处，都能通过 100. IP（或通过 Tailscale DNS）安全地与其他设备通信——而其他任何东西都无法访问它们。而且这类个人用途是免费的！在 Tailscale 之前，我甚至不敢尝试搭建任何形式的家庭实验室。现在我的网络里有好几台设备，而且我每周都会（从手机上）远程使用它们好几次。有时我会故意把笔记本电脑留在家里，因为在外出时用手机控制它，比从包里把它掏出来更高效。（Tailscale 基本上只是 Wireguard 的一层封装，所以如果你想自己动手搭建也可以——但我对自己的技能远没有足够的信心，不敢在如此关乎安全的事情上亲自尝试。）~ catwell 2026-11-11 08:47:44 作为 Tailscale 的替代方案，我用 ZeroTier 做同样的事，我认为它的出现比 Tailscale 更早（实际上我最初是用一家已倒闭的初创公司 Lima 的内部技术来做这件事的……）11 johnklos 2026-11-11 09:28:56 以下是一些宽泛的概括，或许对你有帮助。首先，是的，你用搜索引擎找到的大部分内容质量都很差，是反复翻炒的营销材料。当然，你可以从这些结果中学到好东西，但同时也会学到糟糕的做法。例如，大多数营销性质的操作指南会告诉你去下载二进制程序或 Docker 镜像，这对学习来说也许没问题，但随着时间推移会变成安全问题。一个好做法是学会如何从源码安装软件，或者至少使用更新频繁的包管理器。Docker 镜像是在创建者心血来潮时才构建的，而且往往内置了古老的依赖，可能存在漏洞。一个更新频繁的正规打包系统会为你所有的软件使用相同的依赖，并定期更新，尤其是当其中任何依赖存在可被利用的漏洞时。了解并熟悉 Unix 权限模型。它其实相当不错，而某些营销人士告诉你的说法是错的：如果你为托管的每个服务使用单独的非特权用户，而其中一个用户被攻破，并且这可能导致提权到 root，那么问题在于你的系统更新不够，未能阻止 root 提权。想要你治标不治本的人多得是，他们往往鼓吹 Docker 或别的什么东西，是因为它流行，而不是因为它真的合理。不要让功能蔓延得逞。我为朋友和小企业托管了几十个 Wordpress 站点，每次 PHP 更新，总有人 的站点会挂掉，因为他们在搭建站点时一时兴起装了十几个插件，其中大多数并不必要，但又没有更新，导致他们的站点无法在最新版 PHP 上运行。我已经很擅长在不登录 WP 的情况下禁用插件了。最好只安装和使用你真正想用的东西。与此相关，我建议先安装、折腾、让一切正常运行、做笔记，然后用这些笔记从头重新安装一遍，这样你就知道哪些步骤是多余的。你的第一次安装可能有二十个步骤，但一旦你弄懂了，第二次可能只有六个。干净是好事。尽可能避免使用密码。使用 ssh 密钥，尽可能只允许特定 IP 或 IP 段访问 https 登录页面，如果可以的话把这些链接做成自定义的，等等。一个人们（和机器人）不知道的 OpenCloud 登录页面，比一个会被机器人不断撞击的公开页面要好得多。对于任何确实需要密码的地方，不要重复使用，不要使用简单或基础的密码，也不要让任何人觉得自己的弱密码"足够好"，或者认为没人会找到这个服务

想尝试登录的人不会太费力。假设一切都会被测试，包括每一次泄露中出现的每一个用户名、邮箱地址和密码。不要相信那些告诉你你做不到、你不该做某些事情的守门人。我教过非技术背景的人自托管邮件。如果非技术人员都能做到，那么那些自称技术娴熟却坚称邮件无法合理自托管的守门人，凭什么被相信？如果你发现自己身处对你居高临下的社区，或者有人试图告诉你树莓派不是正经服务器，那就换个社区。这个社区就很好 :) 哦——给你的派配一块好用耐用的存储，然后玩得开心！

8 gspr 编辑于 2026-11-11 13:21:38

一条非常不具体的建议是简单。自托管时，安全由你自己负责（废话）。而维护会成为一项爱好。所以要相应调整规模：选择不会在你脚下改变的软件，因为那会让你拖延维护（这就是我们一些人喜欢用“稳定”一词所表达的意思）。选择容易重新上手、无需每天深陷其中就能理解的软件。选择至少会以明显方式出故障的软件。选择需要很多环节同时出错才会坏掉的软件。选择无聊的。

8 vincent-uden 2026-11-11 06:39:21

你需要多在意安全，完全取决于你托管什么。例如，如果我自托管一个面向公众的文件存储或邮件服务器，我会在安全上投入很大。而如你所述，如果我只是在树莓派上托管一个静态网站，我一般会关心少得多。风险就是没那么大。它不会让你损失很多钱，因为那是你自己的硬件。最坏的情况是陌生人完全控制了你的树莓派。他们可能会探测你的本地网络（但如果你把树莓派放在子网里就不会），在你的网站上显示其他信息，或者让你的树莓派为他们干活（例如作为僵尸网络的一部分或挖矿）。我个人不会把任何这些可能性视为重大风险。作为额外收获，设置日志来检测是否发生这些情况，可以是一个有趣的副项目。

7 icefox 编辑于 2026-11-11 08:48:22

只为一个静态网站？只允许 SSH 私钥，不要密码。运行稳定发行版的稳定版本，出坏事时随时打补丁。用 nginx。关掉所有你不需要的东西，并用防火墙双重检查。真的就这些。使用 VPN 连接到别处的服务器很有用，但主要是为了避免不得不说服住宅 ISP 允许你提供网站等服务。我更喜欢 Nebula 而不是 Tailscale，它设置起来有点笨重，但一旦起来就神奇地好用。试过 Wireguard，它似乎在打洞方面有真正的问题。

~ jaredkrinke 2026-11-11 18:59:33

关于如何判断坏事发生，有什么建议吗？订阅发行版安全邮件列表？一些易于设置的性能监控？我托管公共服务器最大的犹豫是，即使出了坏事我也不会知道。倒不是说这阻止了我……

5 msangi 2026-11-11 07:29:13

我避免将服务暴露到公共互联网，因为我是唯一的用户。它们只能通过 WireGuard 访问。我使用 plan WireGuard，但如果你需要其他东西来处理配置，Tailscale 或 NetBird 之类的方案也可以。除此之外，我仍然到处使用 HTTPS（使用 ACME DNS-01 挑战，这样我能从 Let's Encrypt 获得正规证书，而不在公共互联网上暴露任何东西）。身份验证主要基于 passkeys（我用 PocketID 做单点登录），并且我只使用 SSH 密钥（尽可能由安全飞地支持）。我在 NixOS 中运行我的服务。对于我的威胁模型来说，在同一台机器上运行所有东西是可以的，但为了获得更多工作负载隔离

你可以把各项服务分散到多台 VM/micro-VM 上。~ bahlo 2026-11-11 08:33:36 我在这里描述过我的 NAS 配置：https://arne.me/blog/buildlog-nas#security，简而言之就是使用 Tailscale 并自托管控制服务器，不向互联网暴露任何内容，启用 HTTPS，磁盘加密。我认为从家里自托管一个网站，与自托管存储/rss/照片等其他东西，应当被视为不同的问题，采用不同的方法。理想情况下，它们甚至不应该运行在同一套系统上。~ hoistbypetard 2026-11-11 08:45:22 几年前，我一步步写下了我的做法。我大体上仍在用同样的方法，尽管这些年有些步骤变了。最大的区别是，现在新东西我用 tailscale，并让我的反向代理通过 tailnet 连接后端。Tailscale 本质上是在自动化我在那篇文章里描述的 wireguard 配置，同时围绕它增加了一些不错的功能。我喜欢拥有自己的反向代理 VPS。从任意服务商购买最便宜的 Linux VPS 就足够用了。对于新的 VPS，netcup 是我目前的最爱。（我在一些项目里也用 Hetzner、DigitalOcean 和 Linode。它们比 netcup 更容易上手一些，而且这 3 家都支持比一个月更短的时间单位。不过对于要在线一整月或更久的东西，netcup 的价格很难被超越。我为了一台在美国东海岸骑车都能路过的服务器而支付欧元，这确实让我觉得好笑。）但如果你只为自己和你在网络上信任的人托管东西，你可以跳过反向代理 VPS，直接用你的 wireguard 网络/tailnet。~ creesch 2026-11-11 10:20:54 我自托管的大多数东西本来就是私人使用的。所以我的家庭服务器只获得网络访问权限，我用 WireGuard 远程访问这些东西。这当然不适用于面向公众的静态网站。说实话我绝不会从家庭网络托管这些，因为那也会给访问者提供太多我不愿意透露的地理信息。所以对于这种情况，我会租一台 VPS，并尽可能保持简单。要么用 nginx 加 lets encrypt certbot，要么用 caddy，后者内置证书，也支持静态网站。确保安全更新自动应用，只允许 ssh 密钥登录，就静态托管而言，你大部分基础工作就已经覆盖了。~ blip 2026-11-11 10:32:28 由于你无法控制即将出现的漏洞利用，你应当：减少能接触到潜在 zero-day 漏洞利用的人数；降低利用 zero-day 漏洞造成的影响。我提到 zero day，是因为我假设你的系统会保持更新。=> 自动化你的更新（包括软件包和容器镜像）。减少访问：有些人只允许访问这些端口：22 用于 SSH（如果你把它留在标准端口，你会看到有些人建议改掉），80（通常从不使用，除非是为了通过 Let's encrypt 简化 SSL 设置），以及 443（仅用于需要公开的服务）。对于不面向公众的服务，人们会使用 VPN 或 Tailscale，这意味着只有你允许加入网络的人才能访问这些服务（这意味着如果你想让家人和朋友访问这些服务，你很可能需要帮他们设置 Twingate，而且他们无法从任意笔记本电脑访问你的服务）。有些人觉得上述做法还是太开放，会进一步收紧。所有东西都在 tailscale 后面（甚至 SSH），公开服务则利用 Tailscale Funnel。你的机器上不开放任何端口，但你的机器与 tailscale 基础设施之间存在一条隧道，在那里暴露你的网站。降低影响：公开网站仍然可能受到 zero day 的影响（无论是否来自 tailscale funnel），所以思路是控制损害。把服务运行在容器里是一种简单的方法，可以在出问题时把影响限制在该服务上（而不是整台服务器）。如果你想更进一步，我发现这篇博客包含

好的通用建议：https://dataswamp.org/~solene/tag-selfhosting.html 显然你还能做更多：为家庭服务器划分 VLAN，以及同一思路的许多变体：用 wireguard 代替 tailscale，用 iroh 代替 tailscale，用 VM 代替容器，用不同的服务用户代替容器，等等。 ~ bramh 编辑于 2026-11-11 12:58:05 我运行两个反向代理：一个可公开访问，另一个只能通过 WireGuard 访问。公开的反向代理只能与公开服务（例如网站）通信，私有的反向代理只能与私有服务（例如 Immich）通信。这些服务只能与反向代理通信，不以任何其他方式暴露。这一切都通过基本的 Docker 网络实现。关于 Tailscale 的文章已经很多了，但我更喜欢 WireGuard。它设置起来很简单，而且没有什么魔法。Tailscale 的一些严重失误，比如这次事件，以及对整体“恶化”（enshittification）的担忧，让我不想使用它。我写了一个简单的脚本来管理和分发我的 WireGuard 配置，并处理我的设置中遇到的各种边缘情况，但你也可以手动把配置复制到你的设备上。这真的没有一些人说的那么麻烦。 ~ amiantos 2026-11-11 16:55:46 这不算是对你问题的回答，但我认为通过家庭互联网托管可公开访问的网站以供更广泛访问是个坏主意，因为如果真有流量流向它，你很可能违反了 ISP 的政策，未来可能陷入不利境地。家庭互联网是我的工作方式，所以如果我失去了它，我会很受伤。你还会让自己面临家庭互联网被 DDOS 的风险，这也会造成相当大的伤害，并让你的 ISP 不高兴。如果你的网站是静态的，你可以完全免费地使用 Cloudflare R2 托管静态网站，并通过 wrangler 轻松发布。静态网站完全不需要以任何方式暴露你的家庭网络，这对我来说似乎有些过度。我理解这是为了学习和折腾等等，但托管静态网站时你要做的学习和折腾基本上为零。个人认为，弄清楚如何生成静态网站并通过 wrangler 自动发布，更有学习价值。这也是运行 Wordpress 网站的好方法，因为你可以在家庭网络上安全地使用 Wordpress，使用静态网站插件生成网站，用 wrangler 发布，并避免所有因拥有 Wordpress 网站而招来的“黑客”尝试。就我个人而言，我把所有 homelab 服务都运行在容器中，并通过 Cloudflared 暴露它们，我知道你已经否定了这个方案，但我不太确定为什么，因为 Cloudflared 唯一做的事情就是终止 TLS 并消除住宅动态 IP 的问题。如今处理这个问题的其他方案也同样自动化（caddy、nginx+certbot 等），差别不大，也没什么可学的。 ~ kwas 编辑于 2026-11-11 08:48:22 除了 cloudflare tunnel，你还可以弄一个 vps，并设置一个带 NAT 的 wireguard 隧道。我为我的 torrent 和 DirectConnect 客户端这样做，这样它们就能在没有 UPnP/NAT-PMP 的情况下获得公网 IP。我正在考虑对 Jellyfin 也这样做，以便它能在 tailscale 之外访问。但我可能仍然需要一些额外的层，不确定。 ~ bwbuhse 2026-11-11 08:48:58 我很懒，也不是一个好榜样，所以也许不要照我做，但是：我在我的 OPNsense 盒子上设置了 WireGuard，这样我出门时就能 VPN 进入我的家庭网络。我想要在公共互联网上的服务就开在 443 端口，主要是静态网站，但也有几个像 Jellyfin 这样的东西。我不想公开的服务在我的 Nginx 配置中默认全部拒绝，并为我的 LAN 和 Wireguard 子网设置白名单。我把东西容器化，我不知道，我想如果某个容器逃逸漏洞被发现，反正我大概也不是最大的目标，希望我在 rsync.net 有（加密的）备份，以防万一出问题。这基本上就是要点。我

我想我在服务器上也把 nftables 锁得比较严，并且用 Crowdsec 来封禁已知的恶意 IP，还能检测端口扫描之类的情况并一并封禁，再加上 OPNsense 上基于 IP 地理位置的封禁，彻底阻断来自例如中国和俄罗斯的连接，~ alexwennerberg 编辑于 2026-11-11 10:51:11 很多人建议使用某种面向公网的隧道 / 代理服务器，但这不就违背了自托管的初衷吗：如果你在跑一个 VPS 代理，为什么不干脆把东西托管在那个代理上？如果你用的是某种 VPN 服务，为什么不直接用 AWS 之类的？自托管就失去了它的独立性。~ ggpsv 2026-11-11 14:15:27 一个 VPS 代理可以只是进入你网络的网关，而 WireGuard 并不需要多少资源。一台每年 $5-12 的小 VPS 就足够了。你家里的机器很可能有更多资源来托管应用。~ blip 2026-11-11 12:07:09 嗯，概念上是的，实践中这是安全与便利之间的权衡。如果你把流量隧道到云服务，你仍然拥有数据和大部分基础设施，只是把数据传递委托给外部服务（不过我并不会为此租一整台 VPS，而是直接利用 Tailscale 或 Cloudfare 这类现成方案）不用这些外部服务你也能做同样的事（自托管 Headscale 或 Wireguard，和/或为少数面向公网的网站加一个代理），这完全取决于你想管理什么。~ sy 2026-11-11 12:54:41 grsecurity + PaX + RBAC 规则，可能用 learn 特性来逐步构建规则集 配置 grsec 内核时，确保设置好 socket 限制组，即无法打开 socket 的 GID（或者反过来，要求必须属于某个组才能打开 socket，“nosocks vs allowsocks”）审计系统中的 setuid 可执行文件，并创建类似的组，把对它们的访问限制给特定用户。如果用户无法访问一个有漏洞的 SUID 可执行文件，他们就无法利用它。确保设置合理的 limits.conf 以避免 fork 炸弹。用 UID 把东西圈起来——一个用户，一个服务。这样被攻破的服务只能泄露它自己的东西，不会有更多。不要依赖容器、沙箱或神奇方案。真正的安全是无聊的。无聊通常有效。Docker、firejail、Podman、cgroups 等都是在已经运行的访问控制和权限之上又加了一层代码，而在现代，更多代码意味着更多 bug。像 SEL4 这样的东西在经验证的硬件上会完全安全，但这并不能说明你构建在其上的应用如何。~ kwas 2026-11-11 17:20:53 我，呃，很惊讶居然有人为自托管的东西跑 grsec。我可没有那个预算。~ chriswarbo 2026-11-11 13:59:03 这里有很多针对“标准”Web 服务器配置的好建议。我想提一下，还有一些不那么标准的做法，比如 P2P 和覆盖网络，它们可以绕开隧道、DNS 和 HTTPS 之类的问题。例如，TOR 有一个叫“onion services”的特性，任何联网的机器都可以通过一个 .onion 地址让某个端口可访问（我二十年前就用这个在宿舍里跑一个 Wiki；尽管我对网络几乎一无所知！）静态网站托管也非常适合像 IPFS、dat、freenet 等的内容寻址存储。这些做法的缺点是，它们与标准的 OS + DNS + Web 浏览器配置并不完全兼容。最好的情况下，可以通过 Tor2web 或 IPFS 网关这类网关来规避；但最坏的情况下，可能需要在客户端安装特定软件才能访问。对于你只想把自己控制的机器连接起来的应用来说，这可能没什么问题。~ unixdigest 2026-11-11 19:13:21 我不推荐 Cloudflare Tunnels、Cloudflare 整体，或任何半自托管/基于云的方案，因为正如你也提到的，那违背了全部意义。就个人而言，我也不推荐托管任何东西，除非你在互联网和你的机器之间运行一个路由器/防火墙。我强烈推荐 OpenBSD，因为基础系统中有很多部分是 buil

专门为此设计，文档非常完善，安全性很高，而且易于设置。我运行的配置几乎与我教程 OpenBSD Router Guide 中描述的一致，我把所有托管的东西都放在它后面。它也处理了 DNS 和我需要的其他一切。如果你不需要从互联网访问路由器，只允许从本地网络访问。否则，你可以禁用基于密码的 SSH 登录，在非标准端口上运行 SSH，使用 fail2ban，自动封锁恶意 IP 等，以提高安全性。作为起点，你可以在路由器本身上运行一切，比如你的静态网站，你甚至可以直接用 Raspberry Pi 作为路由器（外加一个 USB 以太网适配器），但我个人更喜欢把东西稍微分开一些。所以我在防火墙后面还有几台其他机器运行 Web 相关内容和其他东西。如果你愿意，你也可以自己托管电子邮件，我过去用 OpenSMTPD 做过，非常成功——实际上是在 Raspberry Pi 上。你可以在我的网站上找到一些教程，了解我在 Arch Linux 上是怎么做的，不过它们现在已经过时了，但它很长一段时间都运行得很好——直到一块硬盘坏了。我当时用 Arch Linux 是为了好玩，也是为了看看维护起来有多难，因为 Arch 是前沿的。在我使用的那段时间里，它运行得非常好。通常我总是更喜欢 OpenBSD 和 FreeBSD。除此之外，我建议使用接近裸金属的方式，不要额外的层，因为这会让你更好地理解你正在使用的技术，也会减少问题的数量。使用 Docker 之类的东西或其他“花招”可能会让入门更容易，但从长远来看往往最终会导致不必要的问题。不要害怕自托管！整个“云”基本上就是自托管，只是别人在替你做了 ;) ~ atmosx 2026-11-11 07:25:14 你好 @pralkarz，我假设你的互联网连接有足够的带宽来维持一个小到中等规模的网站。由于安全影响，自托管一个面向公众的服务比自托管私人服务（如照片管理应用或媒体服务器）危险一个数量级。好的一面是，与 LAMP 栈相比，静态页面可以用相对较少的努力安全地托管。(a) 应用网络分段是一个好的开始。通过路由器/防火墙配置，RPi 不应该能够与其他设备通信。也许只允许基于 IP 或 MAC 地址的一台设备从 LAN 访问 RPi。(b) 然后设置 DNS 记录。我假设你拥有一个 FQDN。使用现成的或自定义的脚本来更新 DNS 记录。我使用 dnscontrol 配合 envsubst 来执行更改，但还有更简单的解决方案。(c) 一旦 DNS 正常工作并正确更新，使用一个应用程序来签发 SSL 证书。我最喜欢的是 acme.sh，但还有不少完善的替代品，例如 certbot、lego 等。(d) 现在你准备好设置反向代理了。注意，像 Caddy 这样的现代反向代理可以自己管理 (c)。我不使用它们，我熟悉 nginx，所以我用那个。(e) 创建一个具有最低权限的部署用户，并使用该用户通过 sftp 或其他安全协议上传数据。如果你想通过 git 设置部署流水线，也可以通过 webhooks 实现。(f) 保护系统。我很确定你可以直接封禁大型云 CIDR。这将使你免于愚蠢的扫描器滥用你的网站。由于很少有真人使用这些地址进行出站连接，我认为直接封锁它们是一个好策略。你可以设置一个 cron 脚本下载 CIDR 并更新你的防火墙“block”表。f.1 确保你设置了某种监控，以便你可以快速测量资源和传入请求等指标（例如响应延迟、传入请求数量等）。由于你要自托管，你将拥有日志访问权限，这意味着完整的访客信息。f.2 你可

想要探索设置 “chroot” 的可能性。f.3 告警：pushover 是一个不错的 “主机 -> 手机” 替代方案，另一个办法是配置 SMTPd，让系统能向你个人邮箱发送状态报告等邮件。(g) 将所有内容备份到本地（例如另一台 NAS）或远程（backblaze 相当便宜），或者两者都做。我想这就是我要说的全部内容了 :-) 祝自托管愉快！~ pgn 2026-11-11 10:55:51 呼应本帖目前为止的其他评论，我同样使用了 Tailscale/Cloudflare Tunnel 的组合。Tailscale 用于 “个人” 服务（Syncthing、远程唤醒等），而 Cloudflare tunnel 用于任何公开可用的服务（例如一个图书馆网站）。是的，与尝试完全自建基础设施相比，学习成本肯定更低，但它免费且相当省心，同时在托管服务的方式上给了我更多灵活性。~ romforth 2026-11-11 11:22:23 Anders Pitman 收集了大量相关资源：https://github.com/anderspitman/awesome-tunneling 闭源和开源方案都有列出。从刚才查看的情况看，它似乎仍在积极维护。~ maurycy 2026-11-11 11:24:33 像 cloudflare tunnels 这样的服务与安全关系不大。它们解决的问题是在没有公网 IP 地址的情况下将传入的互联网流量送达服务器。这是非常不同的问题。关于路由：有些 ISP 会分配固定的公网 IPv4 地址。如果是这种情况，设置端口转发即可。否则，你需要一个反向代理服务。Cloudflare tunnels 是一个选项，但在租用的服务器上运行自己的反向代理也很容易。（这也可以用于非 HTTP 服务）无论如何，基于代理的系统都会引入对另一台服务器的依赖。如果你不喜欢这样，那就去向你 ISP 抱怨吧。关于安全：最重要的是：更新和适当的服务隔离。使用强 SSH 密码或禁用密码（仅密钥）。防火墙限制出站流量。尽量减少对外暴露的服务（也就是说，如果你的服务器在家里，SSH 不必暴露在互联网上）。~ gerardnico 2026-11-11 11:54:31 如果你家里的路由器能够转发端口，就把 HTTP 端口转发到你的树莓派，获取你的公网 IP 并填入 DNS。不确定你说的安全是什么意思，但对于静态网站来说，HTTP 上的漏洞利用面相当小。如果你想要更多安全性，把网站放进 docker 中，使用非 root 用户运行。乐趣很多，要学的也很多。~ spc476 2026-11-11 13:14:04 这里没有提到的一点是——如果你托管一个网站，一旦公开可用，你的 ISP 连接就会被机器人活动淹没。有多种方法可以缓解这个问题，但都有不同的取舍；Cloudflare 设置简单，但你依赖的是一家大型企业，而它正是网络整合问题的一部分。另一个解决方案是调整你的 Web 服务器/防火墙以限制并发连接/阻止流量，但这需要你这边做更多工作。就我个人而言，我确实在自托管，但那是一台我自己管理的 VM 服务器。工作量不算大，但我会持续关注它，并且不得不在调优 Apache（我已经用了 25 年以上）上花费比我希望更多的时间，以防它崩溃（甚至到了自己编译并加入自定义模块来限制 IP 连接的程度）。~ vakradrz 2026-11-11 14:03:54 你可以从小规模且（相对）安全的方式开始，使用 CloudFlare 为你提供免费 DNS、TLS 证书、一个 Tunnel，让你绕过缺少静态 IP 的问题（如果你没有的话），并将你置于他们的基础设施之后。然后，随着信心增强，你可以逐步自己运行其中的各个部分。使用 Let's Encrypt 制作自己的 TLS 证书相当容易，而且只要你走完它的设置流程，就有大量工具可以自动为你运行。运行自己的 DNS 也可以很简单，而且有大量材料可读。如果这是一个你不介意偶尔从网上掉线的网站，如果（当）你在等待 D

在搞错一条记录后等待 NS 传播，尽管去做，然后享受吧！~ apropos 2026-11-11 17:17:38 我认为 ~mw 和 ~marginalia 已经涵盖了我大部分会给出的建议。我唯一要补充的是，对于托管大量服务而言，NixOS 是我唯一会使用的操作系统。它的软件包（nixpkgs）有良好的默认设置——大多数服务已经为你配置了广泛的沙箱隔离——并且它提供了一个地方，可以找到所有与漏洞相关的开关（即开放端口、奇怪的用户权限等）。它还迫使你对安全性非常明确。如果有任何服务/依赖项存在严重 CVE，它会拒绝构建，直到你将其名称和版本逐字写入配置文件。这既是不要运行易受攻击软件的良好动力，也能在你错过漏洞报告时提醒你。不过对于托管少量软件而言，其实什么都行。我在我的 VPS 上运行 Alpine Linux 加 HAProxy。只要确保你理解这个系统，并频繁更新它。~ wink 2026-11-11 17:17:51 理论上我同意大多数人写的内容，但我恰恰不太想将局域网上的任何机器暴露到互联网，甚至不想仅仅通过端口转发 https 来暴露。也许有一天我会做一个与局域网没有连通性的本地虚拟机，这样潜在攻击者需要先突破那个虚拟机。再加上 DNS 以及从局域网和从外部寻址主机的问题，但也许是我没有完全正确地阅读 tailscale 文档。~ jpmonette 2026-11-11 18:10:07 以前为了方便访问，我把应用暴露在互联网上，但在经历了一连串 AI 黑客攻击后，我用了 Tailscale，结果发现设置和使用都非常简单。还有一个名为 Headscale 的开源版本可以自托管。我的应用运行在我桌子下面的一个 Pi 上，以及一个免费的 Oracle VM 上。~ erock 2026-11-11 21:06:44 https://tuns.sh 是一种以安全可靠的方式将本地服务暴露到互联网的好方法。它类似于 cloudflare tunnels，但使用 ssh 端口转发，只提供对你的服务的访问。~ katdork 编辑于 2026-11-12 01:58:18 嗨 pralkarz，我从别处听说过你（clonk）！如果你在意不必盯着用量或可能有高用量，我喜欢通过 wireguard 隧道将本地服务运行到带宽不计量的便宜 VPS 上。以前我会推荐 buyvm。这对于在家处理较重负载很合适，但用 Pi 的话，你可能会问自己为什么要为一个盒子付费。如果你不想为一个盒子付费，你就得考虑动态 DNS，并且必须真正关心通过端口转发对网络的外部访问。无论如何，如果你拥有一个域名，你就能使用 ACME 挑战 / certbot 来获取 TLS 证书，无论是使用 HTTP-01 还是 DNS-01 挑战。我认为 HTTP-01 对入门来说最简单，因为它只要求获取证书的程序把一些文件放到你的 web 根目录下。如果你使用的是提供子域名的动态 DNS 提供商，一旦你在那里设置了 nginx 之类的东西，你大概可以对其使用 HTTP-01 挑战。正确设置 NGINX 相对简单。其中很多在 NixOS 领域尤其简单。一个静态网站只是设置一个带有 virtualHost 的服务器，其根指向包含你站点的目录（通常是 /var/www 的子路径）。我所有的东西都运行在 NixOS 上，我最终打算把它迁移到 Guix，但这无关紧要。NixOS 对初学者来说是一个很好的入口，就 services.<thing>.enable、选项搜索和 NixOS 手册而言，它让设置服务变得容易导航。不过 guix 的手册更好 :(

  • 34 mw 2026-11-11 06:56:24 太对了。我很喜欢这个问题。听起来你想要的可能是“除了我没人能读我的数据包！”如果是这样，我会去看整条链路。你需要把流量路由到 pi。用 DNS 把主机名解析到静态 IP，然后还需要某种方式在内部网络上从静态 IP 路由到你的 pi。你需要有效的密钥和证书，这样你提供的流量才会被其他浏览器认定为安全（密钥和证书）。你需要 TLS，并且要刻意在你能控制的某个地方终止 TLS。这三件事高度交织，“自托管”就是选择你想自己拥有其中哪些。我个人最喜欢的方案：从任意提供商租一台每月 $5 的机器（什么都行——vultr、linode、digital ocean、hetzner），用你的 pi 通过 ssh 连到租来的机器，把 443 端口转发到你的 pi。在终止 TLS 的那一端（最终是你的 pi）运行 acme.sh。我喜欢这个方案有几个原因。它提供了一个可以指向 DNS 记录的静态 IP 地址。它也不会暴露你住在哪里。你可能在意也可能不在意这一点。但它也意味着你会花更多时间学习互联网，而不是和家庭网络上的端口转发较劲。只要你的 pi 能接触到互联网，它就能找到你的机器。这意味着你可以把 pi 用胶带绑到一台 mint mobile 热点和一块太阳能板上，在任何有阳光的地方提供你的静态站点。我总是想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我不知道为什么，这让我微笑。因为你用的是 ssh，所以存在 TLS over TLS。但这真的不重要。重点是，在你和用户之间，除了你的 pi 之外没有人能看到任何东西。当你最终从 ssh 端口转发迁移到更稳定的方案时，其他一切都不变。当你最初搭建和调试时，你在 pi 上做的任何事都可以在租来的 $5 机器上做。它稍微更稳定，也更接近将来真有人付钱让你做的事。你最终可能会在某处使用 nginx 或 haproxy 来让端口对齐。但你也可以用 iptables。随你选。Tailscale 和 Cloudflare tunnels 真的很酷。它们省去了一些头疼，但你说得对，它们放弃了那一点安全性（以及学习机会！）。我为你感到兴奋 :) 告诉我进展如何！16 johnklos 2026-11-11 11:50:41 我刚带着我的备用 MX 开车横穿美国。我的手机提供热点，一台 GL.inet 做 tethering 并提供互联网，我的备用 MX 运行 tinc 隧道给自己一个公网 IP。因为我的备用 MX 靠 5 伏（USB 供电）运行并且有电池备份，我用点烟器 USB 电源适配器给它供电，但它也完全可以靠我的太阳能板供电（我把太阳能板穿过掀背车窗 :) ~ quindarius 2026-11-11 12:45:06 太酷了兄弟 8 dsschnau 2026-11-11 07:59:06 我总是想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我得承认我也笑了。~ dzwdz 2026-11-11 10:22:28 我不确定 acme.sh 是不是最好的选择。另外，对很多自托管场景（家里有服务器，想从其他设备访问上面的服务），我认为 Tailscale 是杀鸡用牛刀。纯 WireGuard 配置起来简单得令人愉快。当然，它有一些好处——它有 NAT 穿透，足够聪明能找出比最简单的纯 wg 方案里你大概率会得到的星型拓扑更高效的路由，它还有花哨的多用户支持——但你真的需要这些吗？5 gecko 2026-11-11 10:40:11 我使用 Tailscale 而不是 WireGuard 的原因（唯一原因！）是 Tailscale 到处都有原生应用（包括关键的 Apple TV 和 Google 当下的流媒体设备），而 WireGuard 没有。[1]。考虑到使用 Tailscale 不用花任何钱，至少对这个特定用例来说，这让我觉得值得。[1]：嗯，有

一个 Apple TV 上的付费订阅应用，我可以越狱那个 Google 设备，但为了让我能访问 Jellyfin 文件而投入的精力是有限的。~ altano 2026-11-11 11:59:35 WireGuard 在 tvOS 上可用。纯正的、免费的、开源的 WireGuard。~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。2024 年或 25 年的时候这还完全不成立 ~ altano 2026-11-11 12:13:46 呃，我那么确定，然而……我觉得是我幻觉了。似乎并不可用。~ weberc2 2026-11-11 11:19:09 我认为 Tailscale 是大材小用。纯 WireGuard 配置起来相当简单。我一直听到这种说法，但我没见过有人解释如何让它顺利工作，而我对 wg 的所有尝试都是令人沮丧的练习（并不是说 Tailscale 就毫无痛苦）。把隧道建立起来运行正常没问题，但弄清楚如何让隧道不崩溃或静默地不转发流量要困难得多。另外，我不太确定在没有 Tailscale 的情况下如何让 wireguard 在我的 Apple TV 上工作。~ weberc2 2026-11-11 11:12:12 用你的 pi 通过 ssh 连接到租用的盒子，将 443 端口转发到你的 pi 当我尝试这个时，SSH 隧道总是崩溃并需要重新创建。似乎至少需要一个控制循环来监视它，但即便如此，有时故障不是“SSH 进程消失了”，而是它活着但静默地不工作，我无法弄清楚如何从运行在 pi 上的控制循环中检测这种情况，所以我不得不每月手动踢它一两次。~ twm 2026-11-11 13:05:06 根据我的经验，通过设置 ServerAliveInterval 使始终有少量流量，可以让 autossh 获得不错的可靠性。你也可以设置 TCPKeepAlive，但由于它在 TCP 层操作，会受到中间盒的影响，我猜这在移动网络上是一个特别的风险。但我确实同意 SSH 在这里不是正确的工具。

当然。我喜欢这个问题。

听起来你想要的可能是“除了我，没人能读取我的数据包！”如果是这样，我会顺着这条链路来看。

  • 你需要把流量路由到 pi。DNS 负责把主机名解析为静态 IP，然后还需要某种方式在内部网络中把流量从静态 IP 路由到你的 pi。
  • 你需要有效的密钥和证书，这样你提供的流量才会被其他浏览器识别为安全（密钥和证书）。
  • 你需要 TLS，并且要有意在你控制的某个地方终止 TLS。

这三者紧密交织在一起，“自托管”就是选择你想自己拥有其中哪些部分。

我个人最喜欢的方案：

  • 从任意提供商租一台每月 5 美元的机器（什么都行——vultr、linode、digital ocean、hetzner）。
  • 用你的 pi 通过 ssh 连接到租来的机器，把 443 端口转发到你的 pi。
  • 在终止 TLS 的地方（最终是你的 pi）运行 acme.sh。

我喜欢这个方案有几个原因。

  • 它提供了一个可以指向 DNS 记录的静态 IP 地址。它也不会暴露你住在哪里。你可能在意，也可能不在意。但它也意味着你会花更多时间学习互联网，而不是和家庭网络上的端口转发较劲。
  • 只要你的 pi 能接触互联网，它就能找到你的机器。这意味着你可以把 pi 用胶带绑到 mint mobile 热点和太阳能板上，在任何有阳光的地方提供你的静态站点。我总想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我不知道为什么，这让我微笑。
  • 因为你用的是 ssh，所以存在 TLS over TLS。但这其实不重要。重点是，你和用户之间的任何东西，除了你的 pi 之外没人能看见。当你最终从 ssh 端口转发迁移到更稳定的方案时，其他一切都不变。
  • 当你最初搭建和调试时，你在 pi 上做的任何事都可以在租来的 5 美元机器上做。它稍微更稳定，也更接近将来有人真正付钱让你做的事。

你最终可能会在某处使用 nginx 或 haproxy 来对齐端口。但你也可以使用 iptables。随你选。

Tailscale 和 Cloudflare tunnels 真的很酷。它们省去了一些麻烦，但你说得对，它们放弃了一点安全性（以及学习机会！）。

我为你感到兴奋 :) 告诉我进展如何！

  • 16 johnklos 2026-11-11 11:50:41 我刚带着我的备用 MX 开车横穿美国。我的手机提供热点，一台 GL.inet 做网络共享并提供互联网，我的备用 MX 运行 tinc 隧道给自己一个公网 IP。由于我的备用 MX 靠 5 伏（USB 供电）运行并有电池备份，我用点烟器 USB 电源适配器给它供电，但它也完全可以由我的太阳能板供电（我把太阳能板穿过掀背车窗 :) ~ quindarius 2026-11-11 12:45:06 太酷了兄弟

我刚带着我的备用 MX 开车横穿美国。我的手机提供热点，一台 GL.inet 做网络共享并提供互联网，我的备用 MX 运行 tinc 隧道给自己一个公网 IP。

由于我的备用 MX 靠 5 伏（USB 供电）运行并有电池备份，我用点烟器 USB 电源适配器给它供电，但它也完全可以由我的太阳能板供电（我把太阳能板穿过掀背车窗 :)

  • ~ quindarius 2026-11-11 12:45:06 太酷了兄弟

太酷了兄弟

  • 8 dsschnau 2026-11-11 07:59:06 我总想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。我得承认我也为此笑了。
我总想象它在一辆 1996 年 Toyota Camry 开裂的后备箱盖板上，在高速公路上飞驰时被太阳烤着。

我得承认我也为此笑了。

  • ~ dzwdz 2026-11-11 10:22:28 我不确定 acme.sh 是不是最好的选择。另外，对于很多自托管场景（家里有一台服务器，想从其他设备访问上面的服务），我认为 Tailscale 属于杀鸡用牛刀。原生 WireGuard 配置起来简单得令人愉快。当然，它有一些便利之处——它支持 NAT 穿透，足够聪明，能找出比最简单的原生 wg 配置中大概率会形成的星型拓扑更高效的路由，还支持花哨的多用户功能——但你真的需要这些吗？

5 gecko 2026-11-11 10:40:11 我使用 Tailscale 而不是 WireGuard 的原因（唯一的原因！）是 Tailscale 在各处都有原生应用（其中关键的是 Apple TV 和 Google 当红的流媒体设备），而 WireGuard 没有。[1]。考虑到使用 Tailscale 不需要花任何钱，至少对这个特定用例来说，这让我觉得值得。

[1]：嗯，Apple TV 上有一个付费订阅应用，我也可以越狱 Google 那个设备，但为了让我能访问 Jellyfin 文件而投入的精力是有限的。

~ altano 2026-11-11 11:59:35 WireGuard 在 tvOS 上可用。原生的、免费的、开源的 WireGuard。

~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。在 2024 或 25 年这绝对不是真的

~ altano 2026-11-11 12:13:46 呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

~ weberc2 2026-11-11 11:19:09 我认为 Tailscale 属于杀鸡用牛刀。原生 WireGuard 配置起来简单得令人愉快。我不断听到这种说法，但我还没见过有人解释如何让它顺利运作，而我对 wg 的每一次尝试都是挫折的练习（倒不是说 Tailscale 就毫无痛苦）。把隧道建立并运行起来没问题，但弄清楚如何防止隧道断开或静默地不转发流量，则要困难得多。另外，我不太确定在没有 Tailscale 的情况下，我该如何让 wireguard 在我的 Apple TV 上工作。

我不确定 acme.sh 是不是最好的选择。

另外，对于很多自托管场景（家里有一台服务器，想从其他设备访问上面的服务），我认为 Tailscale 属于杀鸡用牛刀。原生 WireGuard 配置起来简单得令人愉快。

当然，它有一些便利之处——它支持 NAT 穿透，足够聪明，能找出比最简单的原生 wg 配置中大概率会形成的星型拓扑更高效的路由，还支持花哨的多用户功能——但你真的需要这些吗？

  • 5 gecko 2026-11-11 10:40:11 我使用 Tailscale 而不是 WireGuard 的原因（唯一的原因！）是 Tailscale 在各处都有原生应用（其中关键的是 Apple TV 和 Google 当红的流媒体设备），而 WireGuard 没有。[1]。考虑到使用 Tailscale 不需要花任何钱，至少对这个特定用例来说，这让我觉得值得。

[1]：嗯，Apple TV 上有一个付费订阅应用，我也可以越狱 Google 那个设备，但为了让我能访问 Jellyfin 文件而投入的精力是有限的。

~ altano 2026-11-11 11:59:35 WireGuard 在 tvOS 上可用。原生的、免费的、开源的 WireGuard。

~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。在 2024 或 25 年这绝对不是真的

~ altano 2026-11-11 12:13:46 呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

我使用 Tailscale 而不是 WireGuard 的原因（唯一的原因！）是 Tailscale 在各处都有原生应用（其中关键的是 Apple TV 和 Google 当红的流媒体设备），而 WireGuard 没有。[1]。考虑到使用 Tailscale 不需要花任何钱，至少对这个特定用例来说，这让我觉得值得。

文章标题：怎样才能真正安全地自托管？

正文： [1]：嗯，Apple TV 上有一个付费订阅应用，我也可以越狱那个 Google 的东西，但为了让我能访问自己的 Jellyfin 文件，我愿意投入的精力是有限的。

  • ~ altano 2026-11-11 11:59:35 WireGuard 在 tvOS 上可用。普通的、免费的、开源的 WireGuard。 ~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。2024 年或 2025 年的时候这还完全不成立 ~ altano 2026-11-11 12:13:46 呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

WireGuard 在 tvOS 上可用。普通的、免费的、开源的 WireGuard。

  • ~ gecko 2026-11-11 12:05:28 哦太棒了！我得再看看。2024 年或 2025 年的时候这还完全不成立 ~ altano 2026-11-11 12:13:46 呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

哦太棒了！我得再看看。2024 年或 2025 年的时候这还完全不成立

  • ~ altano 2026-11-11 12:13:46 呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

呃，我本来那么确定，然而……我觉得是我幻觉了。似乎并不可用。

  • ~ weberc2 2026-11-11 11:19:09 我认为 Tailscale 是大材小用。普通的 Wireguard 配置起来相当简单。我一直听到这种说法，但我没见过有人解释如何让它顺利工作，而我对 wg 的每一次尝试都是一次挫败的练习（倒不是说 Tailscale 就毫无痛苦）。把隧道建立并运行起来没问题，但搞清楚如何让隧道不崩溃或不会静默地不转发流量，则要困难得多。另外，我不太确定在没有 Tailscale 的情况下，我该如何让 wireguard 在我的 Apple TV 上工作。
我认为 Tailscale 是大材小用。普通的 Wireguard 配置起来相当简单。

我一直听到这种说法，但我没见过有人解释如何让它顺利工作，而我对 wg 的每一次尝试都是一次挫败的练习（倒不是说 Tailscale 就毫无痛苦）。把隧道建立并运行起来没问题，但搞清楚如何让隧道不崩溃或不会静默地不转发流量，则要困难得多。

另外，我不太确定在没有 Tailscale 的情况下，我该如何让 wireguard 在我的 Apple TV 上工作。

  • ~ weberc2 2026-11-11 11:12:12 用你的 pi 通过 ssh 连接到租用的机器，把 443 端口转发到你的 pi 我尝试这个的时候，SSH 隧道总是崩溃，需要重新建立。看起来至少需要一个控制循环来监视它，但即便如此，有时故障并不是“SSH 进程消失了”，而是它还活着但静默地不工作，我无法弄清楚如何从运行在 pi 上的控制循环中检测到这种情况，所以我每个月得手动踢它一两次。 ~ twm 2026-11-11 13:05:06 根据我的经验，通过设置 ServerAliveInterval 让流量始终保持涓涓细流，可以让 autossh 获得不错的可靠性。你也可以设置 TCPKeepAlive，但由于它工作在 TCP 层面，会受到中间盒的影响，我猜这在移动网络上是一个特别的风险。但我确实同意 SSH 在这里不是正确的工具。
用你的 pi 通过 ssh 连接到租用的机器，把 443 端口转发到你的 pi

我尝试这个的时候，SSH 隧道总是崩溃，需要重新建立。看起来至少需要一个控制循环来监视它，但即便如此，有时故障并不是“SSH 进程消失了”，而是它还活着但静默地不工作，我无法弄清楚如何从运行在 pi 上的控制循环中检测到这种情况，所以我每个月得手动踢它一两次。

  • ~ twm 2026-11-11 13:05:06 以我的经验，通过设置 ServerAliveInterval 让流量始终保持涓流，autossh 可以获得相当不错的可靠性。你也可以设置 TCPKeepAlive，但由于它工作在 TCP 层，会受到中间盒的影响，我猜这在移动网络上是一个特别的风险。但我确实同意 SSH 在这里不是合适的工具。

以我的经验，通过设置 ServerAliveInterval 让流量始终保持涓流，autossh 可以获得相当不错的可靠性。你也可以设置 TCPKeepAlive，但由于它工作在 TCP 层，会受到中间盒的影响，我猜这在移动网络上是一个特别的风险。

但我确实同意 SSH 在这里不是合适的工具。

  • 30 marginalia edited 2026-11-11 10:15:26 作为一个长期把东西公开暴露在网上的人，我想说做到以下几点就能完成 95%：
  • 定期更新系统
  • 禁用 SSH 密码登录
  • 让 SSH 运行在非标准端口上（现实地说，低成本的自动化顺手入侵尝试是这类事情的主要威胁途径，所以缩小你的目标特征确实有帮助，哪怕你奶奶都能跑 nmap 找到你隐藏的端口）
  • 设置 UFW（或类似工具），封锁所有不应可访问的端口
  • 如果你没有 docker 网络方面的博士学位，就不要用 docker，因为它很容易“好心”地在你的防火墙上戳出洞来
  • 对于任何你只想自己访问的东西，把它放在 caddy 或 nginx 后面并加上 basic_auth。永远不要相信 Web 应用的登录界面能保你安全。你可以用 fail2ban 进一步改进这一点。客户端证书是更进一步升级的办法，但设置起来有点麻烦。仅 basic_auth 就已经很管用了。
  • ~ quindarius 2026-11-11 12:46:53 好东西

好东西

  • 20 tuxes 编辑于 2026-11-11 06:27:56 从非公开面向的服务开始会更安全，例如在你的手机、笔记本电脑和 Raspberry Pi 上安装 Tailscale，然后再开始搭建你自己想要的服务。我问过这个问题的一些人推荐了 Cloudflare Tunnels 之类的解决方案来保证安全，但使用这样的提供商几乎感觉违背了自托管的初衷。我喜欢自己完成端到端的工作，但有时我实在懒得弄，于是就用 Cloudflare Tunnels 让它跑起来，这对我来说比完全放弃要好。 8 pralkarz 2026-11-11 07:10:52 我多次听说过 Tailscale，但说实话，他们的网站对我来说读起来和企业邮件一样，也就是说我无法从中消化出任何实质内容（我知道，这可能又是我的技能问题）。你介意分享一些具体的用例吗（例如你用它来做什么的例子）？这可能会让我更容易理解这个概念。 18 brn 2026-11-11 07:15:40 我认为最简单的解释方式是：Tailscale 让你所有的设备表现得就像它们都在同一个家庭网络上，无论它们实际在哪里。 ~ tuxes 2026-11-11 07:18:12 他们 2020 年的网站更清楚一些：https://web.archive.org/web/20201129111934/https://tailscale.com/ 但基本上，它让你的各种设备彼此连接，无论它们在哪里，都不必处理端口转发、防火墙、动态 DNS……所以你的手机或笔记本电脑可以访问 Raspberry Pi 上的自托管服务（照片、Jellyfin、RSS、文件……）。它在做到这一点的同时，对随机路人和攻击者保持隐藏。我不用 Tailscale，而是只用普通的 Wireguard/mTLS，但 Tailscale 最容易设置，似乎是想在外出时访问自己 Raspberry Pi 的人中最受欢迎的选择。 ~ ceph 2026-11-11 10:21:48 我主要把它用于个人的“私有内网”；我在家里的 homelab 机器上托管 Grafana 和 Forgejo 之类的服务，然后把它们连接到 Tailscale，这样我就可以通过 tailnet 远程访问它们，而不需要把它们放到公网上。额外的好处是它还提供“funnel”，一个公共反向代理，其工作方式与向 tailnet 提供服务相同，避免了为提供这些服务而需要公网 IP。与传统 VPN 不同，Tailscale 本身并不通过其基础设施隧道传输流量——控制平面服务器管理访问和路由，但流量通过建立点对点 WireGuard 隧道传输，Tailscale 运营中继，在需要时（例如 NAT 穿透）在机器之间转发加密数据包。也就是说，你确实放弃了一定程度的自托管——你可以租一个便宜的 VPS 并设置例如 Headscale 来获得相当一部分功能（不过我个人没有亲自尝试过）。 ~ alethkit 2026-11-11 10:25:01 在我看来，关于 Tailscale 为何出现的最佳高层概述是 https://tailscale.com/blog/two-internets-both-flakey ~ cyberia 2026-11-11 12:29:48 Tailscale 不错，但如果你想学点东西，我建议手动设置 WireGuard 隧道。我的设置是一台云 VPS（在 OVH 上）运行 TLS 终止，将流量转发到我的 homelab 服务器，该服务器通过 WireGuard 连接到 VPS。这样，我的家庭 IP 不会公开可见，它变化或怎样都无所谓——我的 homelab 服务器只需重新连接隧道，云 VPS 通过其 WireGuard IP 来寻址它。 ~ frontsideair 2026-11-12 01:18:39 在这里无耻地自我推销一下，因为我解释 Tailscale 用于自托管的博客广受好评，所以可能有用（我甚至当时还在用 Raspberry Pi！）https://blog.6nok.org/tailscale-is-pretty-useful/ ~ hafiz 2026-11-11 07:55:04 具体例子：假设你想要一个任务服务器，你可以通过一个稳定的标识符访问其仪表板，它运行在一台隔离的机器上，并且不暴露在公网上。那么 Tailscale 就是一个很好的解决方案。其他例子：隧道进入

其他不应暴露在互联网上的 VPC；在网络内部共享本地演示；当你对当前所在网络不信任时，将某台特定机器用作出口节点；通过稳定 ID 访问你的设备（例如我有一组 IP 动态变化的 Mac，但我可以通过屏幕共享用稳定 ID 登录） ceph 2026-11-11 10:21:49 [评论已被作者删除] ~ creesch 2026-11-11 10:24:49 这不过是一种为家庭网络搭建 VPN 的方式。它吸引人的地方在于，你不需要为家庭网络准备静态 IP 就能连接，因为他们会通过他们那边进行路由，而且设置极其简单。但这也意味着你在信任他们。就我个人而言，我家里确实有静态 IP，我的路由器也支持 WireGuard，所以我用的是那个。是一回事。

更安全的做法是从不面向公众的服务开始，例如在手机、笔记本电脑和 Raspberry Pi 上安装 Tailscale，然后再开始搭建你自己想要的服务。

我问过这个问题的一些人推荐了 Cloudflare Tunnels 之类的方案来保证安全，但使用这类提供商几乎让人觉得违背了自托管的初衷

我喜欢自己端到端地做，但有时我实在懒得弄，就用 Cloudflare Tunnels 让它跑起来，这对我来说比彻底放弃要好。

  • 8 pralkarz 2026-11-11 07:10:52 我多次听说过 Tailscale，但说实话，他们的网站对我来说读起来就像公司邮件一样，也就是说我从中吸收不到任何实质内容（我知道，这可能又是我的能力问题）。你介意分享一些具体的用例吗（例如你用它来做什么）？这可能会让我更容易理解这个概念。 18 brn 2026-11-11 07:15:40 我认为最简单的解释是：Tailscale 让你所有的设备表现得就像在同一个家庭网络上，无论它们实际在哪里。 ~ tuxes 2026-11-11 07:18:12 他们 2020 年的网站稍微清楚一些：https://web.archive.org/web/20201129111934/https://tailscale.com/ 但基本上，它让你的各种设备能够互相连接，无论它们在哪里，而无需处理端口转发、防火墙、动态 DNS……所以你的手机或笔记本电脑可以访问 Raspberry Pi 上的自托管服务（照片、Jellyfin、RSS、文件……）。它在做到这一点的同时，对随机的人/攻击者保持隐藏。我不使用 Tailscale，而是只用普通的 Wireguard/mTLS，但 Tailscale 最容易设置，似乎是那些想在外出时访问 Raspberry Pi 的人最受欢迎的选择。 ~ ceph 2026-11-11 10:21:48 我主要用它作为个人的“私有内网”；我在家里的 homelab 机器上托管 Grafana 和 Forgejo 等服务，然后将它们连接到 Tailscale，这样我就可以通过 tailnet 远程访问它们，而无需将它们放到公共互联网上。作为额外好处，它还提供“funnel”，一个公共反向代理，其工作方式与向 tailnet 提供服务相同，避免了为提供这些服务而需要公共 IP。与传统 VPN 不同，Tailscale 本身并不通过其基础设施隧道传输流量——控制平面服务器管理访问和路由，但流量通过建立点对点 WireGuard 隧道传输，Tailscale 运营中继，在需要时（例如 NAT 穿透）在机器之间转发加密数据包。也就是说，你确实放弃了一些自托管——你可以租一个便宜的 VPS 并设置例如 Headscale 来获得相当一部分功能（不过我个人还没有尝试过）。 ~ alethkit 2026-11-11 10:25:01 我认为关于 Tailscale 为何出现的最佳高层概述是 https://tailscale.com/blog/two-internets-both-flakey ~ cyberia 2026-11-11 12:29:48 Tailscale 不错，但如果你想学习一些东西，我建议手动设置 WireGuard 隧道。我的设置是一个云 VPS（在 OVH 上）运行 TLS 终止，将流量转发到我的 homelab 服务器，该服务器通过 WireGuard 连接到 VPS。这样，我的家庭 IP 不会公开可见，它是否变化或其他什么也无所谓——我的 homelab 服务器只需重新连接隧道，云 VPS 通过其 WireGuard IP 来寻址它。 ~ frontsideair 2026-11-12 01:18:39 在这里无耻地自我推销一下，因为我解释 Tailscale 用于自托管的博客受到了好评，所以可能有用（我甚至用的是 Raspberry Pi！）https://blog.6nok.org/tailscale-is-pretty-useful/ ~ hafiz 2026-11-11 07:55:04 具体例子：假设你想要一个作业服务器，你可以通过稳定的标识符访问其仪表板，它运行在隔离的机器上，并且不暴露在公共互联网上。那么 Tailscale 是一个很好的解决方案。其他例子：隧道进入其他不应暴露在互联网上的 VPC；在网络内的人之间共享本地演示；当你当前所在的网络不可信时，使用特定机器作为出口节点；通过稳定 ID 访问你的设备（例如我有一组 Mac，它们的 IP 是动态的，但我可以通过屏幕共享使用稳定 ID 登录） ceph 2026-11-11 10:21:49 [评论已被作者删除] ~ creesch 2026-11-11 10:24:49 它只是一种设置到你家网络的 VPN 的方式。它吸引人的地方在于，你不需要为你的家设置静态 IP 来连接

因为流量经由它们路由，而且配置极其简单。但这也意味着你在信任它们。就我个人而言，我家里确实有静态 IP，我的路由器也支持 WireGuard，所以我用的是它。道理是一样的。

我多次听说过 Tailscale，但说实话，他们的网站读起来就像公司邮件一样，我从中读不出任何实质内容（我知道，这可能又是我的能力问题）。你能否分享一些具体的用例（例如你用它来做什么的例子）？这可能会让我更容易理解这个概念。

  • 18 brn 2026-11-11 07:15:40 我觉得最简单的解释是：Tailscale 让你所有的设备表现得就像在同一个家庭网络上，无论它们实际位于何处。

我觉得最简单的解释是：Tailscale 让你所有的设备表现得就像在同一个家庭网络上，无论它们实际位于何处。

  • ~ tuxes 2026-11-11 07:18:12 他们 2020 年的网站稍微清楚一些：https://web.archive.org/web/20201129111934/https://tailscale.com/ 但基本上，它让你的各种设备无论身在何处都能相互连接，而无需处理端口转发、防火墙、动态 DNS……因此你的手机或笔记本电脑可以访问 Raspberry Pi 上的自托管服务（照片、Jellyfin、RSS、文件……）。它在做到这一点的同时，对随机路人/攻击者完全隐藏。我不使用 Tailscale，而是只用普通的 Wireguard/mTLS，但 Tailscale 最容易设置，似乎是想在外出时访问自己 Raspberry Pi 的人最受欢迎的选择。

他们 2020 年的网站稍微清楚一些：https://web.archive.org/web/20201129111934/https://tailscale.com/

但基本上，它让你的各种设备无论身在何处都能相互连接，而无需处理端口转发、防火墙、动态 DNS……因此你的手机或笔记本电脑可以访问 Raspberry Pi 上的自托管服务（照片、Jellyfin、RSS、文件……）。它在做到这一点的同时，对随机路人/攻击者完全隐藏。

我不使用 Tailscale，而是只用普通的 Wireguard/mTLS，但 Tailscale 最容易设置，似乎是想在外出时访问自己 Raspberry Pi 的人最受欢迎的选择。

  • ~ ceph 2026-11-11 10:21:48 我主要把它用于个人的“私有内网”；我在家里的 homelab 机器上托管 Grafana 和 Forgejo 之类的服务，然后把它们连接到 Tailscale，这样我就可以通过 tailnet 远程访问它们，而无需将它们暴露在公网上。额外的好处是它还提供“funnel”，一个公共反向代理，其工作方式与向 tailnet 提供服务相同，从而避免了为提供这些服务而需要公网 IP。与传统 VPN 不同，Tailscale 本身并不通过其基础设施隧道传输流量——控制平面服务器管理访问和路由，但流量通过建立点对点 WireGuard 隧道传输，Tailscale 运营中继，在需要时（例如 NAT 穿透）在机器之间转发加密数据包。也就是说，你确实放弃了一定程度的自托管——你可以租一个便宜的 VPS 并设置例如 Headscale 来获得相当一部分功能（不过我个人还没有尝试过）。

我主要把它用于个人的“私有内网”；我在家里的 homelab 机器上托管 Grafana 和 Forgejo 之类的服务，然后把它们连接到 Tailscale，这样我就可以通过 tailnet 远程访问它们，而无需将它们暴露在公网上。额外的好处是它还提供“funnel”，一个公共反向代理，其工作方式与向 tailnet 提供服务相同，从而避免了为提供这些服务而需要公网 IP。

与传统 VPN 不同，Tailscale 本身并不通过其基础设施来隧道传输流量——控制平面服务器负责管理访问和路由，但流量是通过建立点对点的 WireGuard 隧道来传输的，Tailscale 运营着中继服务器，在需要时（例如 NAT 穿透）在机器之间转发加密数据包。话虽如此，你确实放弃了一定程度的自托管——你可以租一台便宜的 VPS 并搭建例如 Headscale，从而获得相当一部分功能（不过我个人还没有尝试过）。

  • ~ alethkit 2026-11-11 10:25:01 在我看来，关于 Tailscale 为何诞生，最好的高层概览是 https://tailscale.com/blog/two-internets-both-flakey

在我看来，关于 Tailscale 为何诞生，最好的高层概览是 https://tailscale.com/blog/two-internets-both-flakey

  • ~ cyberia 2026-11-11 12:29:48 Tailscale 不错，但如果你想学点东西，我建议手动搭建 WireGuard 隧道。我的方案是一台云 VPS（在 OVH 上）运行 TLS 终止，将流量转发到我的家庭实验室服务器，该服务器通过 WireGuard 连接到 VPS。这样，我的家庭 IP 不会公开可见，而且它是否变化或怎样都无所谓——我的家庭实验室服务器只需重新连接隧道，云 VPS 通过其 WireGuard IP 来寻址它。

Tailscale 不错，但如果你想学点东西，我建议手动搭建 WireGuard 隧道。

我的方案是一台云 VPS（在 OVH 上）运行 TLS 终止，将流量转发到我的家庭实验室服务器，该服务器通过 WireGuard 连接到 VPS。这样，我的家庭 IP 不会公开可见，而且它是否变化或怎样都无所谓——我的家庭实验室服务器只需重新连接隧道，云 VPS 通过其 WireGuard IP 来寻址它。

  • ~ frontsideair 2026-11-12 01:18:39 这里无耻地自我推销一下，因为我那篇讲解如何用 Tailscale 进行自托管的博客反响不错，所以可能有用（我当时甚至用的是 Raspberry Pi！）https://blog.6nok.org/tailscale-is-pretty-useful/

这里无耻地自我推销一下，因为我那篇讲解如何用 Tailscale 进行自托管的博客反响不错，所以可能有用（我当时甚至用的是 Raspberry Pi！）

https://blog.6nok.org/tailscale-is-pretty-useful/

  • ~ hafiz 2026-11-11 07:55:04 具体例子：假设你有一个 job server，你希望通过一个稳定的标识符访问其仪表盘，它运行在一台隔离的机器上，且不暴露在公网上。那么 Tailscale 就是一个很好的解决方案。其他例子：隧道连接到不应暴露在互联网上的其他 VPC；在网络内的成员之间共享本地演示；当你当前所在的网络不可信时，使用某台特定机器作为出口节点；通过稳定 ID 访问你的设备（例如我有一组 IP 是动态的 Mac，但我可以通过屏幕共享用稳定 ID 登录）

具体例子：假设你有一个 job server，你希望通过一个稳定的标识符访问其仪表盘，它运行在一台隔离的机器上，且不暴露在公网上。那么 Tailscale 就是一个很好的解决方案。其他例子：隧道连接到不应暴露在互联网上的其他 VPC；在网络内的成员之间共享本地演示；当你当前所在的网络不可信时，使用某台特定机器作为出口节点；通过稳定 ID 访问你的设备（例如我有一组 IP 是动态的 Mac，但我可以通过屏幕共享用稳定 ID 登录）

  • ceph 2026-11-11 10:21:49 [评论已被作者删除]

[评论已被作者删除]

  • ~ creesch 2026-11-11 10:24:49 它就是一种搭建到你家网络的 VPN 的方式。它吸引人的地方在于，你不需要为你的家庭网络准备一个静态 IP 来连接，因为它们会通过它们进行路由，而且设置极其简单。但这也意味着你在信任它们。就我个人而言，我家里确实有静态 IP，而且我的路由器也支持 WireGuard，所以我用的是那个。一回事。

这其实就是一种为家庭网络搭建 VPN 的方式。它之所以有吸引力，是因为你不需要为家里申请静态 IP 就能连接，流量会经由他们的服务器进行路由，而且配置极其简单。

但这也意味着你在信任他们。就我个人而言，我家里确实有静态 IP，我的路由器也支持 WireGuard，所以我用的是它。道理是一样的。

  • 14 simonw 编辑于 2026-11-11 08:25:45 这段对话里已经提到 Tailscale 十次了，我要把它凑成十一次。它确实很好地解决了家庭实验室的安全问题。在你的设备上运行它——它几乎在所有设备上都能用（我甚至在 Apple TV 上装了它），而且安装和配置都极其简单。现在你的手机或笔记本电脑，无论身处世界何处，都能通过它们的 100. IP（或通过 Tailscale DNS）安全地与其他设备通信——而其他任何东西都无法访问它们。而且这种个人用途是免费的！在 Tailscale 之前，我连尝试运行任何形式的家庭实验室都不敢。现在我的家庭实验室里有好几台设备，我每周都会实际远程使用它们（从手机上）好几次。有时我会故意把笔记本电脑留在家里，因为出门在外时用手机控制它，比把它从包里拿出来更高效。（Tailscale 基本上只是 WireGuard 的一层封装，所以如果你想自己动手搭建也可以——但对我自己这种安全至关重要的东西，我对自己的技能远没有足够的信心去尝试。）~ catwell 2026-11-11 08:47:44 作为 Tailscale 的替代方案，我用 ZeroTier 做同样的事，我认为它的出现比 Tailscale 更早（实际上我最初是用一家名为 Lima 的已倒闭创业公司内部自研的技术来做这件事的……）

这段对话里已经提到 Tailscale 十次了，我要把它凑成十一次。

它确实很好地解决了家庭实验室的安全问题。

在你的设备上运行它——它几乎在所有设备上都能用（我甚至在 Apple TV 上装了它），而且安装和配置都极其简单。

现在你的手机或笔记本电脑，无论身处世界何处，都能通过它们的 100. IP（或通过 Tailscale DNS）安全地与其他设备通信——而其他任何东西都无法访问它们。

而且这种个人用途是免费的！

在 Tailscale 之前，我连尝试运行任何形式的家庭实验室都不敢。现在我的家庭实验室里有好几台设备，我每周都会实际远程使用它们（从手机上）好几次。

有时我会故意把笔记本电脑留在家里，因为出门在外时用手机控制它，比把它从包里拿出来更高效。

（Tailscale 基本上只是 WireGuard 的一层封装，所以如果你想自己动手搭建也可以——但对我自己这种安全至关重要的东西，我对自己的技能远没有足够的信心去尝试。）

  • ~ catwell 2026-11-11 08:47:44 作为 Tailscale 的替代方案，我用 ZeroTier 做同样的事，我认为它的出现比 Tailscale 更早（实际上我最初是用一家名为 Lima 的已倒闭创业公司内部自研的技术来做这件事的……）

作为 Tailscale 的替代方案，我用 ZeroTier 做同样的事，我认为它的出现比 Tailscale 更早（实际上我最初是用一家名为 Lima 的已倒闭创业公司内部自研的技术来做这件事的……）

  • 11 johnklos 2026-11-11 09:28:56 以下是一些宽泛的概括，或许对你有帮助。首先，是的，你用搜索引擎找到的大部分内容质量都很差，是反复翻炒的营销材料。当然，你可以从这些结果中学到好东西，但同时也会学到糟糕的做法。例如，大多数营销式教程会告诉你下载二进制程序或 Docker 镜像，这对学习来说也许没问题，但随着时间推移会变成安全问题。一个好做法是学会通过源码安装软件，或者至少使用经常更新的包管理器。Docker 镜像是在创建者心血来潮时构建的，而且往往内置了古老的依赖，可能存在漏洞。一个经常更新的正规打包系统会让你的所有软件使用相同的依赖，并定期更新，尤其是当其中任何依赖存在可被利用的漏洞时。了解并熟悉 Unix 权限模型。它其实相当不错，而某些营销人士告诉你的说法是错的：如果你为托管的每个服务使用单独的非特权用户，而其中一个用户被攻破，并且这可能导致提权到 root，那么问题在于你的系统更新不够，未能阻止提权到 root。想要你治标不治本的人数不胜数，他们往往鼓吹 Docker 或其他什么东西，是因为它流行，而不是因为它真的合理。不要让功能蔓延得逞。我为朋友和小企业托管了几十个 Wordpress 站点，每次 PHP 更新，总有人 的站点挂掉，因为他们建站时一兴奋就装了十几个插件，大多数并不必要，而且没有更新，导致站点无法与最新的 PHP 配合工作。我已经很擅长在不登录 WP 的情况下禁用插件了。最好只安装和使用你真正想用的东西。与此相关，我建议先安装、试用、让一切正常运行、做笔记，然后用这些笔记从零重新安装，这样你就知道哪些步骤是多余的。你第一次安装可能有二十个步骤，但一旦你弄懂了，第二次可能只有六个。干净是好事。尽可能避免使用密码。使用 ssh 密钥，尽可能只允许特定 IP 或 IP 段访问 https 登录页面，如果可以的话把这些链接做成自定义的，等等。一个人们（和机器人）不知道的 OpenCloud 登录页面，比一个会被机器人不断撞击的公开页面要好得多。对于任何确实需要密码的地方，不要重复使用，不要使用简单或基础的密码，也不要让任何人以为自己的弱密码“足够好”，或者以为没人会找到该服务并费力尝试登录。假设一切都会被测试，包括每一次泄露中的每一个用户名、电子邮件地址和密码，永远如此。不要相信那些告诉你你不行、你不该做某些事的守门人。我教过非技术人员自托管电子邮件。如果非技术人员都能做到，那么那些自称技术娴熟却坚称电子邮件无法合理自托管的人，凭什么被相信？如果你发现自己身处对你不屑一顾的社区，或者有人试图告诉你，比如说，Raspberry Pi 不是一台正经服务器，那就换个社区。这个社区就很好 :) 哦——给你的 Pi 配一块好的、耐用的存储，玩得开心！

以下是一些宽泛的概括，或许对你有帮助。

首先，是的，你用搜索引擎找到的大部分内容质量都很差，是反复翻炒的营销材料。当然，你可以从那些结果里学到一些好东西，但同时也会学到糟糕的做法。例如，大多数营销式教程会告诉你下载二进制程序或 Docker 镜像，这对学习来说也许没问题，但随着时间推移会变成安全问题。

一个好做法是学会通过源码安装软件，或者至少使用经常更新的包管理器。Docker 镜像是在创建者想更新时才更新的，而且往往内置了非常古老的依赖，可能存在漏洞。一个经常更新的正规打包系统会让你的所有软件使用同一套依赖，并定期更新，尤其是当其中任何依赖存在可被利用的漏洞时。

了解并熟悉 Unix 权限模型。它其实相当不错，而某些营销人士告诉你的说法是错的：如果你为托管的每个服务使用单独的非特权用户，而其中一个用户被攻破，并且这可能导致提权到 root，那么问题在于你的系统更新不够，以至于无法阻止提权到 root。想让你治标不治本的人非常多，他们往往鼓吹 Docker 或其他什么东西，是因为它流行，而不是因为它真的合理。

不要让功能蔓延得逞。我为朋友和小企业托管了几十个 Wordpress 站点，每次 PHP 更新，总有些人的站点会挂掉，因为他们建站时一兴奋装了十几个插件，大多数并不必要，但又没有更新，导致站点无法在最新 PHP 下运行。我已经很擅长在不登录 WP 的情况下禁用插件了。最好只安装和使用你真正想用的东西。

与此相关，我建议先安装、试用、让一切正常运行、做笔记，然后用这些笔记从零重新安装，这样你就知道哪些步骤是多余的。你第一次安装可能有二十个步骤，但一旦你弄懂了，第二次可能只有六个。干净是好事。

尽可能避免使用密码。使用 ssh 密钥，尽可能只允许特定 IP 或 IP 段访问 https 登录页面，如果可以的话把这些链接做成自定义的，等等。一个人们（和机器人）不知道的 OpenCloud 登录页面，比一个机器人会不断撞上的公开页面要好得多。

对于任何确实需要密码的地方，不要重复使用，不要使用简单或基础的密码，也不要让任何人觉得自己的弱密码“足够好”，或者认为没人会找到这个服务并费力尝试登录。假设一切都会被测试，包括每一次泄露中出现的每一个用户名、电子邮件地址和密码。

不要相信那些告诉你你不行、你不该做某些事的守门人。我教过非技术人员自托管电子邮件。如果非技术人员都能做到，那么那些自称技术娴熟的守门人坚称电子邮件无法合理自托管时，凭什么要相信他们？

如果你发现自己身处对你居高临下的社区，或者有人试图告诉你，比如说，Raspberry Pi 不是一台正经服务器，那就换个社区。这个社区就很好 :)

哦——给你的 Pi 配上好的、耐用的存储，然后玩得开心！

  • 8 gspr 编辑于 2026-11-11 13:21:38 一条非常不具体的建议是：简单。自托管时，安全得由你自己负责（这不是废话嘛）。而维护会成为一种爱好。所以要量力而行：选择那些不会在你脚下悄悄改变的软件，因为那会让你拖延维护（这就是我们有些人喜欢用“稳定”一词所表达的意思）。选择那些容易重新上手、无需每天深陷细节就能理解的软件。选择那些至少会以明显方式出故障的软件。选择那些需要很多环节同时出错才会坏掉的软件。选择无聊的。

一条非常不具体的建议是：简单。

自托管时，安全得由你自己负责（这不是废话嘛）。而维护会成为一种爱好。所以要量力而行：选择那些不会在你脚下悄悄改变的软件，因为那会让你拖延维护（这就是我们有些人喜欢用“稳定”一词所表达的意思）。选择那些容易重新上手、无需每天深陷细节就能理解的软件。选择那些至少会以明显方式出故障的软件。选择那些需要很多环节同时出错才会坏掉的软件。

选择无聊的。

  • 8 vincent-uden 2026-11-11 06:39:21 你需要多在意安全，完全取决于你托管的是什么。举例来说，如果我自托管一个面向公众的文件存储或一个邮件服务器，我会在安全上投入很大。而一般来说，如果像你描述的那样，我只是在 Raspberry Pi 上托管一个静态网站，我会在意得少得多。风险就是没那么大。它不会让你损失很多钱，因为那是你自己的硬件。最坏的情况是陌生人获得了对你 Raspberry Pi 的完全控制。他们可能会探测你的本地网络（但如果你把 Raspberry Pi 放在子网里就不会），在你的网站上显示其他信息，或者让你的 Raspberry Pi 为他们的事情干活（例如作为僵尸网络的一部分或挖矿）。我个人不会把其中任何一种可能性视为很大的风险。而且作为额外收获，设置日志来检测是否发生了这些情况，可能是个有趣的副项目。

你需要多在意安全，完全取决于你托管的是什么。举例来说，如果我自托管一个面向公众的文件存储或一个邮件服务器，我会在安全上投入很大。

而一般来说，如果像你描述的那样，我只是在 Raspberry Pi 上托管一个静态网站，我会在意得少得多。风险就是没那么大。它不会让你损失很多钱，因为那是你自己的硬件。最坏的情况是陌生人获得了对你 Raspberry Pi 的完全控制。他们可能会探测你的本地网络（但如果你把 Raspberry Pi 放在子网里就不会），在你的网站上显示其他信息，或者让你的 Raspberry Pi 为他们的事情干活（例如作为僵尸网络的一部分或挖矿）。

我个人不会把其中任何一种可能性视为很大的风险。而且作为额外收获，设置日志来检测是否发生了这些情况，可能是个有趣的副项目。

  • 7 icefox 编辑于 2026-11-11 08:48:22 只托管一个静态网站？只允许 SSH 私钥登录，禁用密码。运行稳定发行版的稳定版本，一旦出了坏事就及时打补丁。使用 nginx。关掉一切你不需要的东西，再用防火墙复核一遍。真的就这些。用 VPN 连到别处的服务器很有用，但主要用途是省得去说服住宅 ISP 允许你提供网站之类的服务。相比 Tailscale，我更喜欢 Nebula，它配置起来有点笨重，但一旦跑起来就神奇地好用。试过 Wireguard，它在 NAT 穿透方面似乎确实有问题。~ jaredkrinke 2026-11-11 18:59:33 有什么建议能知道什么时候出了坏事吗？订阅发行版的安全邮件列表？有没有容易搭建的性能监控？我托管公网服务器最大的顾虑就是，即使出了坏事我也不会知道。不过这并没有阻止我……

只托管一个静态网站？只允许 SSH 私钥登录，禁用密码。运行稳定发行版的稳定版本，一旦出了坏事就及时打补丁。使用 nginx。关掉一切你不需要的东西，再用防火墙复核一遍。

真的就这些。

用 VPN 连到别处的服务器很有用，但主要用途是省得去说服住宅 ISP 允许你提供网站之类的服务。相比 Tailscale，我更喜欢 Nebula，它配置起来有点笨重，但一旦跑起来就神奇地好用。试过 Wireguard，它在 NAT 穿透方面似乎确实有问题。

  • ~ jaredkrinke 2026-11-11 18:59:33 有什么建议能知道什么时候出了坏事吗？订阅发行版的安全邮件列表？有没有容易搭建的性能监控？我托管公网服务器最大的顾虑就是，即使出了坏事我也不会知道。不过这并没有阻止我……

有什么建议能知道什么时候出了坏事吗？订阅发行版的安全邮件列表？有没有容易搭建的性能监控？

我托管公网服务器最大的顾虑就是，即使出了坏事我也不会知道。不过这并没有阻止我……

  • 5 msangi 2026-11-11 07:29:13 因为我是唯一的用户，我避免把服务暴露到公网。它们只能通过 WireGuard 访问。我用的是 plain WireGuard，但如果你需要别的方案来替你处理配置，Tailscale 或 NetBird 之类的方案也不错。除此之外，我仍然在所有地方启用 HTTPS（使用 ACME DNS-01 挑战，这样就能从 Let's Encrypt 拿到正规证书，而无需在公网上暴露任何东西）。认证主要基于 passkey（我用 PocketID 做单点登录），而且我只用 SSH 密钥（尽可能由安全飞地 backing）。我在 NixOS 里运行我的服务。就我的威胁模型而言，把所有东西跑在同一台机器上没问题，但要想更好地隔离工作负载，你可以把各项服务分散到多个 VM/micro-VM 上。

因为我是唯一的用户，我避免把服务暴露到公网。它们只能通过 WireGuard 访问。我用的是 plain WireGuard，但如果你需要别的方案来替你处理配置，Tailscale 或 NetBird 之类的方案也不错。

除此之外，我仍然在所有地方启用 HTTPS（使用 ACME DNS-01 挑战，这样就能从 Let's Encrypt 拿到正规证书，而无需在公网上暴露任何东西）。

认证主要基于 passkey（我用 PocketID 做单点登录），而且我只用 SSH 密钥（尽可能由安全飞地 backing）。

我在 NixOS 里运行我的服务。就我的威胁模型而言，把所有东西跑在同一台机器上没问题，但要想更好地隔离工作负载，你可以把各项服务分散到多个 VM/micro-VM 上。

  • ~ bahlo 2026-11-11 08:33:36 我在这里描述了我的 NAS 配置：https://arne.me/blog/buildlog-nas#security，简而言之就是使用自托管控制服务器的 Tailscale、不向互联网暴露任何内容、HTTPS、加密磁盘。我认为从家里自托管一个网站，与自托管存储/rss/照片等其他东西，应该被视为不同的问题，采用不同的方法。理想情况下，它们甚至不应该运行在同一套系统上。

我在这里描述了我的 NAS 配置：https://arne.me/blog/buildlog-nas#security，简而言之就是使用自托管控制服务器的 Tailscale、不向互联网暴露任何内容、HTTPS、加密磁盘。

我认为从家里自托管一个网站，与自托管存储/rss/照片等其他东西，应该被视为不同的问题，采用不同的方法。理想情况下，它们甚至不应该运行在同一套系统上。

  • ~ hoistbypetard 2026-11-11 08:45:22 几年前，我一步步写下了我的做法。我大体上仍在用同样的方法，尽管这些年来有些步骤变了。最大的不同是，现在我对新东西使用 tailscale，并让我的反向代理通过 tailnet 连接后端。Tailscale 本质上是在自动化我在那篇文章里描述的 wireguard 配置，同时围绕它增加了一些不错的功能。我喜欢拥有自己的反向代理 VPS。从任意服务商那里买最便宜的 Linux VPS 就够用了。对于新的 VPS，netcup 是我目前的最爱。（我也在一些项目中使用 Hetzner、DigitalOcean 和 Linode。它们比 netcup 稍微容易上手一些，而且这 3 家都支持比一个月更短的时间单位。不过，对于要在线运行整整一个月或更久的东西，netcup 的价格很难被超越。我为了一台在美国东海岸骑车就能经过的服务器而支付欧元，这确实让我觉得好笑。）但如果你只为自己和网络上你信任的人托管东西，你可以跳过反向代理 VPS，直接使用你的 wireguard 网络/tailnet。

几年前，我一步步写下了我的做法。我大体上仍在用同样的方法，尽管这些年来有些步骤变了。最大的不同是，现在我对新东西使用 tailscale，并让我的反向代理通过 tailnet 连接后端。Tailscale 本质上是在自动化我在那篇文章里描述的 wireguard 配置，同时围绕它增加了一些不错的功能。

我喜欢拥有自己的反向代理 VPS。从任意服务商那里买最便宜的 Linux VPS 就够用了。对于新的 VPS，netcup 是我目前的最爱。（我也在一些项目中使用 Hetzner、DigitalOcean 和 Linode。它们比 netcup 稍微容易上手一些，而且这 3 家都支持比一个月更短的时间单位。不过，对于要在线运行整整一个月或更久的东西，netcup 的价格很难被超越。我为了一台在美国东海岸骑车就能经过的服务器而支付欧元，这确实让我觉得好笑。）

但如果你只为自己和网络上你信任的人托管东西，你可以跳过反向代理 VPS，直接使用你的 wireguard 网络/tailnet。

  • ~ creesch 2026-11-11 10:20:54 我自托管的大多数东西本来就是私人使用的。所以我的家庭服务器只获得网络访问权限，我使用 WireGuard 远程访问这些东西。这当然不适用于面向公众的静态网站。说实话，我绝不会从家庭网络托管这些网站，因为那也会给访问它的人提供过多我不希望暴露的地理信息。所以对于这种情况，我会租一台 VPS，并尽可能保持简单。要么用 nginx 搭配 lets encrypt certbot，要么用 caddy，后者内置证书，也支持静态网站。确保自动应用安全更新，只允许 SSH 密钥登录，就静态托管而言，你大部分的基础工作就已经做好了。

我自托管的大多数东西本来就是私人使用的。所以我的家庭服务器只接入网络，我通过 WireGuard 远程访问这些服务。

这当然不适用于面向公众的静态网站。说实话，我绝不会从家庭网络托管这类网站，因为那也会让访问者获得过多我不愿透露的地理信息。所以对于这种情况，我会租一台 VPS，并尽量保持简单。要么用 nginx 搭配 lets encrypt certbot，要么用 caddy——后者内置证书，也支持静态网站。

确保安全更新自动应用，只允许 SSH 密钥登录，就静态托管而言，你基本上已经覆盖了大部分要点。

  • ~ blip 2026-11-11 10:32:28 由于你无法控制未来的漏洞利用，你希望做到：减少能接触到潜在零日漏洞利用的人数；降低零日漏洞被利用后的影响。我提到零日，是因为我假设你的系统会保持更新。=> 自动化你的更新（包括软件包和容器镜像）。减少暴露面：有些人只允许访问这些端口：22 用于 SSH（如果你保留在标准端口上，你会看到有些人建议改掉它）、80（通常从不使用，除非为了通过 Let's encrypt 简化 SSL 设置）、以及 443（仅用于需要公开的服务）。对于不面向公众的服务，人们会使用 VPN 或 Tailscale，这意味着只有你允许进入网络的人才能访问这些服务（这意味着如果你想让家人和朋友访问这些服务，你很可能需要帮他们设置 Twingate，而且他们无法从任何笔记本电脑访问你的服务）。有些人觉得上述做法还是太开放，会进一步收紧。所有东西都在 tailscale 后面（甚至 SSH），公共服务则利用 Tailscale Funnel。你的机器上不开放任何端口，但你的机器与 tailscale 基础设施之间存在一条隧道，在那里暴露你的网站。降低影响：公共网站仍然可能受到零日漏洞的影响（无论是否来自 tailscale funnel），所以思路是控制损害。将服务运行在容器中是限制影响的一种简单方法，出问题时只影响该服务（而不是整台服务器）。如果你想更进一步，我发现这个博客总体上包含很好的建议：https://dataswamp.org/~solene/tag-selfhosting.html 显然你还可以做更多：为家庭服务器使用 VLAN，以及同一思路的许多变体：用 wireguard 代替 tailscale、用 iroh 代替 tailscale、用 VM 代替容器、用不同的服务用户代替容器，等等。

由于你无法控制未来的漏洞利用，你希望做到：

  • 减少能接触到潜在零日漏洞利用的人数
  • 降低零日漏洞被利用后的影响。我提到零日，是因为我假设你的系统会保持更新。=> 自动化你的更新（包括软件包和容器镜像）

减少访问面：有些人只允许访问以下端口：22 用于 SSH（如果你把它留在标准端口上，你会看到有些人建议改掉它），80（通常从不使用，除非是为了通过 Let's encrypt 简化 SSL 设置），以及 443（仅用于需要公开的服务）。对于不面向公众的服务，人们会使用 VPN 或 Tailscale，这意味着只有你允许加入网络的人才能访问这些服务（这意味着如果你想让家人和朋友访问这些服务，你很可能需要帮助他们设置 Twingate，而且他们无法从任何笔记本电脑访问你的服务）。有些人觉得上述做法还是过于开放，会进一步缩减。所有东西都在 tailscale 后面（甚至 SSH），公开服务则利用 Tailscale Funnel。你的机器上没有开放任何端口，但你的机器与 tailscale 基础设施之间存在一条隧道，在那里暴露你的网站。减少影响：公开网站仍然可能受到零日漏洞的影响（无论是否来自 tailscale funnel），所以思路是控制损害。在容器中运行你的服务是一种简单的方法，可以在出问题时将影响限制在该服务上（而不是整个服务器）。

如果你想更进一步，我发现这个博客总体上包含不错的建议：

  • https://dataswamp.org/~solene/tag-selfhosting.html

显然你还能做更多：为你的家庭服务器使用 VLAN，以及同一思路的许多变体：用 wireguard 代替 tailscale，用 iroh 代替 tailscale，用 VM 代替容器，用不同的服务用户代替容器，等等。

  • ~ bramh 编辑于 2026-11-11 12:58:05 我运行两个反向代理：一个可公开访问，另一个只能通过 WireGuard 访问。公开的反向代理只能与公开服务（例如网站）通信，私有的反向代理只能与私有服务（例如 Immich）通信。这些服务只能与反向代理通信，不以任何其他方式暴露。这一切都通过基本的 Docker 网络实现。关于 Tailscale 的文章已经有很多了，但我更喜欢 WireGuard。它设置起来很简单，而且没有什么魔法。Tailscale 的一些严重失误，比如这次事件，以及对整体 enshittification 的担忧，让我不想使用它。我写了一个简单的脚本来管理和分发我的 WireGuard 配置，并处理我的设置所遇到的各种边缘情况，但你也可以直接把配置手动复制到你的设备上。这真的不像有些人说的那么麻烦。

我运行两个反向代理：一个可公开访问，另一个只能通过 WireGuard 访问。公开的反向代理只能与公开服务（例如网站）通信，私有的反向代理只能与私有服务（例如 Immich）通信。这些服务只能与反向代理通信，不以任何其他方式暴露。这一切都通过基本的 Docker 网络实现。

关于 Tailscale 的文章已经有很多了，但我更喜欢 WireGuard。它设置起来很简单，而且没有什么魔法。Tailscale 的一些严重失误，比如这次事件，以及对整体 enshittification 的担忧，让我不想使用它。

我写了一个简单的脚本来管理和分发我的 WireGuard 配置，并处理我的设置所遇到的各种边缘情况，但你也可以直接把配置手动复制到你的设备上。这真的不像有些人说的那么麻烦。

  • ~ amiantos 2026-11-11 16:55:46 这算不上对你问题的回答，但我认为通过家庭网络托管可公开访问的站点以供更广泛访问是个坏主意，因为如果真有流量涌入，你很可能违反了 ISP 的政策，未来可能陷入不利境地。家庭网络是我工作的依靠，一旦断网我会很受影响。你还让自己暴露在家庭网络被 DDOS 的风险之下，这也会相当麻烦，还会惹恼你的 ISP。如果你的站点是静态的，你可以用 Cloudflare R2 完全免费地托管静态站点，并通过 wrangler 轻松发布。静态站点完全没必要以任何方式暴露家庭网络，在我看来那是杀鸡用牛刀。我理解这关乎学习和折腾等等，但托管静态站点时你能学到的和折腾的东西基本为零。我个人认为，弄清楚如何生成静态站点并通过 wrangler 自动发布，更值得学习。这也是运行 Wordpress 站点的好方法：你可以在家庭网络上安全地使用 Wordpress，用静态站点插件生成站点，用 wrangler 发布，并避开所有因拥有 Wordpress 站点而招来的“黑客”尝试。就我个人而言，我把所有 homelab 服务都跑在容器里，并通过 Cloudflared 暴露，我知道你已经否定了这个方案，但我不太确定为什么，因为 Cloudflared 唯一做的事就是终止 TLS 并消除住宅动态 IP 带来的问题。如今处理这件事的其他方案也同样自动化（caddy、nginx+certbot 等），差别不大，也没什么可学的。

这算不上对你问题的回答，但我认为通过家庭网络托管可公开访问的站点以供更广泛访问是个坏主意，因为如果真有流量涌入，你很可能违反了 ISP 的政策，未来可能陷入不利境地。家庭网络是我工作的依靠，一旦断网我会很受影响。你还让自己暴露在家庭网络被 DDOS 的风险之下，这也会相当麻烦，还会惹恼你的 ISP。

如果你的站点是静态的，你可以用 Cloudflare R2 完全免费地托管静态站点，并通过 wrangler 轻松发布。静态站点完全没必要以任何方式暴露家庭网络，在我看来那是杀鸡用牛刀。我理解这关乎学习和折腾等等，但托管静态站点时你能学到的和折腾的东西基本为零。我个人认为，弄清楚如何生成静态站点并通过 wrangler 自动发布，更值得学习。这也是运行 Wordpress 站点的好方法：你可以在家庭网络上安全地使用 Wordpress，用静态站点插件生成站点，用 wrangler 发布，并避开所有因拥有 Wordpress 站点而招来的“黑客”尝试。

就我个人而言，我把所有 homelab 服务都跑在容器里，并通过 Cloudflared 暴露，我知道你已经否定了这个方案，但我不太确定为什么，因为 Cloudflared 唯一做的事就是终止 TLS 并消除住宅动态 IP 带来的问题。如今处理这件事的其他方案也同样自动化（caddy、nginx+certbot 等），差别不大，也没什么可学的。

  • ~ kwas 编辑于 2026-11-11 08:48:22 与其用 cloudflare tunnel，你可以弄一台 vps，并设置带 NAT 的 wireguard tunnel。我为我的 torrent 和 DirectConnect 客户端这样做，让它们无需 UPnP/NAT-PMP 就能获得公网 IP。我正在考虑对 Jellyfin 也这样做，好让它在 tailscale 之外也能访问。但我可能仍需要一些额外的层，不确定。

你可以不用 Cloudflare tunnel，而是弄一台 VPS，用 NAT 搭建一条 WireGuard 隧道。我就是这么为我的 torrent 和 DirectConnect 客户端做的，这样它们就能获得公网 IP，而不必依赖 UPnP/NAT-PMP。我正在考虑对 Jellyfin 也如法炮制，让它能在 tailscale 之外访问。不过我可能还是需要额外加一层，还不确定。

  • ~ bwbuhse 2026-11-11 08:48:58 我比较懒，也不是什么好榜样，所以也许别照我做的来，但：我在 OPNsense 上配了 WireGuard，这样出门时就能 VPN 进家里的网络。我想放到公网上的服务就直接开在 443 端口，大多是静态站点，但也有几个像 Jellyfin 这样的东西。我不想公开的服务在 Nginx 配置里默认全部拒绝，只对我的 LAN 和 Wireguard 子网设白名单。我把东西都容器化了，怎么说呢，我想万一哪天爆出什么容器逃逸漏洞，我大概也不是最大的目标，但愿如此；我在 rsync.net 上有（加密的）备份，以防出什么事。大致就是这样。我想我还把服务器上的 nftables 锁得比较严，并且用 Crowdsec 来封禁已知的恶意 IP，它还能检测端口扫描之类的东西并一并封掉，另外在 OPNsense 上做基于 IP 地理位置的封禁，彻底阻断来自比如中国和俄罗斯的连接，

我比较懒，也不是什么好榜样，所以也许别照我做的来，但：

我在 OPNsense 上配了 WireGuard，这样出门时就能 VPN 进家里的网络。我想放到公网上的服务就直接开在 443 端口，大多是静态站点，但也有几个像 Jellyfin 这样的东西。我不想公开的服务在 Nginx 配置里默认全部拒绝，只对我的 LAN 和 Wireguard 子网设白名单。我把东西都容器化了，怎么说呢，我想万一哪天爆出什么容器逃逸漏洞，我大概也不是最大的目标，但愿如此；我在 rsync.net 上有（加密的）备份，以防出什么事。

大致就是这样。我想我还把服务器上的 nftables 锁得比较严，并且用 Crowdsec 来封禁已知的恶意 IP，它还能检测端口扫描之类的东西并一并封掉，另外在 OPNsense 上做基于 IP 地理位置的封禁，彻底阻断来自比如中国和俄罗斯的连接，

  • ~ alexwennerberg 编辑于 2026-11-11 10:51:11 很多人建议弄一个面向公网的隧道／代理服务器，但这不就违背了自托管的初衷吗：如果你在跑一台 VPS 代理，为什么不干脆把东西托管在那台代理上？如果你用的是某种 VPN 服务，为什么不干脆用 AWS 之类的？自托管就失去了它的独立性。 ~ ggpsv 2026-11-11 14:15:27 VPS 代理可以只是进入你网络的一个网关，而 WireGuard 并不需要多少资源。一台每年 $5-12 的小 VPS 就足够了。你家里的机器很可能有更多资源来托管应用。 ~ blip 2026-11-11 12:07:09 嗯，理论上确实如此，实践中这是安全与便利之间的权衡。如果你把流量隧道到云服务，数据以及大部分基础设施仍然归你所有，只是把数据传输委托给外部服务（不过我不会为此租一整台 VPS，而是直接利用 Tailscale 或 Cloudfare 这类现成方案）。你也可以不用这些外部服务做同样的事（自托管 Headscale 或 Wireguard，和／或为少数面向公网的网站加一个代理），这全看你愿意管理什么，都是权衡。

很多人建议弄一个面向公网的隧道／代理服务器，但这不就违背了自托管的初衷吗：如果你在跑一台 VPS 代理，为什么不干脆把东西托管在那台代理上？如果你用的是某种 VPN 服务，为什么不干脆用 AWS 之类的？自托管就失去了它的独立性。

  • ~ ggpsv 2026-11-11 14:15:27 VPS 代理可以只是进入你网络的一个网关，而 WireGuard 并不需要多少资源。一台每年 $5-12 的小 VPS 就足够了。你家里的机器很可能有更多资源来托管应用。

一台 VPS 代理可以仅仅作为进入你网络的网关，而 WireGuard 并不需要多少资源。一台每年 5-12 美元的小型 VPS 就足够了。你家里的机器很可能有更多资源来托管应用。

  • ~ blip 2026-11-11 12:07:09 嗯，概念上确实如此，但实践中这是安全与便利之间的权衡。如果你把流量隧道到云服务，你仍然拥有数据和大部分基础设施，只是把数据传输委托给外部服务（不过我不会为此租一整台 VPS，而是直接利用 Tailscale 或 Cloudfare 这类现成方案）。你同样可以在不使用这些外部服务的情况下做到这一点（自托管 Headscale 或 Wireguard，和/或为少数面向公众的网站设置代理），这完全取决于你想管理什么。

嗯，概念上确实如此，但实践中这是安全与便利之间的权衡。如果你把流量隧道到云服务，你仍然拥有数据和大部分基础设施，只是把数据传输委托给外部服务（不过我不会为此租一整台 VPS，而是直接利用 Tailscale 或 Cloudfare 这类现成方案）。你同样可以在不使用这些外部服务的情况下做到这一点（自托管 Headscale 或 Wireguard，和/或为少数面向公众的网站设置代理），这完全取决于你想管理什么。

  • ~ sy 2026-11-11 12:54:41 grsecurity + PaX + RBAC 规则，可能使用 learn 功能来构建规则集。配置 grsec 内核时，确保设置好 socket 限制组，即无法打开 socket 的 GID（或者反过来，要求必须属于某个组才能打开 socket，“nosocks vs allowsocks”）。审计系统中的 setuid 可执行文件，并创建类似的组，将它们的访问权限限制为特定用户。如果用户无法访问有漏洞的 SUID 可执行文件，他们就无法利用它。确保设置合理的 limits.conf 以避免 fork 炸弹。用 UID 划定围栏——一个用户，一个服务。这样被入侵的服务只能泄露它自己的东西，不会更多。不要依赖容器、沙箱或神奇方案。真正的安全是无聊的。无聊通常有效。Docker、firejail、Podman、cgroups 等都在已有的访问控制和权限之上增加了代码，而在现代，更多代码意味着更多 bug。像 SEL4 这样的东西在经验证的硬件上会完全安全，但这并不能说明你在其上构建的应用程序如何。~ kwas 2026-11-11 17:20:53 我，呃，很惊讶居然有人为自托管的东西运行 grsec。我可没有那个预算。

grsecurity + PaX + RBAC 规则，可能使用 learn 功能来构建规则集

配置 grsec 内核时，确保设置好 socket 限制组，即无法打开 socket 的 GID（或者反过来，要求必须属于某个组才能打开 socket，“nosocks vs allowsocks”）

审计系统中的 setuid 可执行文件，并创建类似的组，将它们的访问权限限制为特定用户。如果用户无法访问有漏洞的 SUID 可执行文件，他们就无法利用它。

确保设置合理的 limits.conf 以避免 fork 炸弹。

用 UID 划定围栏——一个用户，一个服务。这样被入侵的服务只能泄露它自己的东西，不会更多。

不要依赖容器、沙箱或神奇方案。真正的安全是无聊的。无聊通常有效。Docker、firejail、Podman、cgroups 等都在已有的访问控制和权限之上增加了代码，而在现代，更多代码意味着更多 bug。

像 SEL4 这样的东西在经验证的硬件上会完全安全，但这并不能说明你在其上构建的应用程序如何。

  • ~ kwas 2026-11-11 17:20:53 我，呃，很惊讶居然有人为自托管的东西运行 grsec。我可没有那个预算。

我，呃，很惊讶居然有人为自托管的东西运行 grsec。我可没有那个预算。

  • ~ chriswarbo 2026-11-11 13:59:03 这里有很多关于“标准”Web 服务器配置的绝佳建议。我想提一下，还有一些不太标准的方法，比如 P2P 和覆盖网络，可以绕开隧道、DNS 和 HTTPS 之类的问题。例如，TOR 有一个叫“onion services”的功能，任何联网的机器都可以通过一个 .onion 地址开放某个端口（二十年前我就用过这个功能，在宿舍里跑一个 Wiki；尽管当时我对网络几乎一无所知！）静态网站托管也非常适合内容寻址存储，比如 IPFS、dat、freenet 等。这些方法的缺点在于，它们与标准的操作系统 + DNS + Web 浏览器配置并不完全兼容。最好的情况下，可以通过 Tor2web 或 IPFS 网关之类的网关来规避；但最坏的情况下，可能需要安装特定的客户端才能访问。对于只想把自己控制的机器连接起来的应用来说，这也许没什么问题。

这里有很多关于“标准”Web 服务器配置的绝佳建议。我想提一下，还有一些不太标准的方法，比如 P2P 和覆盖网络，可以绕开隧道、DNS 和 HTTPS 之类的问题。

例如，TOR 有一个叫“onion services”的功能，任何联网的机器都可以通过一个 .onion 地址开放某个端口（二十年前我就用过这个功能，在宿舍里跑一个 Wiki；尽管当时我对网络几乎一无所知！）

静态网站托管也非常适合内容寻址存储，比如 IPFS、dat、freenet 等。

这些方法的缺点在于，它们与标准的操作系统 + DNS + Web 浏览器配置并不完全兼容。最好的情况下，可以通过 Tor2web 或 IPFS 网关之类的网关来规避；但最坏的情况下，可能需要安装特定的客户端才能访问。对于只想把自己控制的机器连接起来的应用来说，这也许没什么问题。

  • ~ unixdigest 2026-11-11 19:13:21 我不推荐 Cloudflare Tunnels、Cloudflare 本身，也不推荐任何半自托管/基于云的方案，正如你也提到的，那会背离整件事的初衷。就个人而言，除非你在互联网和你的机器之间运行路由器/防火墙，否则我也不推荐托管任何东西。我强烈推荐 OpenBSD，因为基础系统的很大一部分就是专门为此构建的，文档非常完善，非常安全，而且易于设置。我运行的设置几乎就像我在教程 OpenBSD Router Guide 中描述的那样，我托管的所有东西都在它后面。这也处理了 DNS 和我需要的其他一切。如果你不需要从互联网访问你的路由器，只允许从本地网络访问。否则，你可以禁用基于密码的 SSH 登录，在非标准端口上运行 SSH，使用 fail2ban，自动阻止恶意 IP 等，以提高安全性。作为起步，你可以在路由器本身上运行所有东西，比如你的静态网站，你甚至可以直接用 Raspberry Pi 作为路由器（外加一个 USB 以太网适配器），但我个人更喜欢把东西稍微分开一些。所以我在防火墙后面还有几台其他机器，运行 Web 相关的东西以及一些其他东西。如果你愿意，你也可以托管自己的电子邮件，我过去用 OpenSMTPD 做过这件事，非常成功——实际上是在 Raspberry Pi 上。你可以在我的网站上找到一些教程，了解我如何在 Arch Linux 上做到这一点，不过它们现在已经过时了，但它很长一段时间内运行得很好——直到一块硬盘坏了。我当时使用 Arch Linux 是为了好玩，也是为了看看维护起来有多难，因为 Arch 是前沿的。在我使用的那段时间里，它运行得非常好。通常我总是更喜欢 OpenBSD 和 FreeBSD。除此之外，我推荐使用接近底层、没有额外层的方法，因为这会让你更好地理解你正在使用的技术，也会减少问题的数量。使用 Docker 或其他“花招”之类的东西可能会让起步更容易，但从长远来看，往往最终会导致不必要的问题。不要害怕自托管！整个“云”基本上就是自托管，只是别人在替你做了 ;)

我不推荐 Cloudflare Tunnels、Cloudflare 本身，也不推荐任何半自托管/基于云的方案，正如你也提到的，那会背离整件事的初衷。

就个人而言，除非你在互联网和你的机器之间运行路由器/防火墙，否则我也不推荐托管任何东西。我强烈推荐 OpenBSD，因为基础系统的很大一部分就是专门为此构建的，文档非常完善，非常安全，而且易于设置。

我运行的设置几乎就像我在教程 OpenBSD Router Guide 中描述的那样，我托管的所有东西都在它后面。这也处理了 DNS 和我需要的其他一切。

如果你不需要从互联网访问你的路由器，只允许从本地网络访问。否则，你可以禁用基于密码的 SSH 登录，在非标准端口上运行 SSH，使用 fail2ban，自动阻止恶意 IP 等，以提高安全性。

作为起步，你可以在路由器本身上运行所有东西，比如你的静态网站，你甚至可以直接用 Raspberry Pi 作为路由器（外加一个 USB 以太网适配器），但我个人更喜欢把东西稍微分开一些。所以我在防火墙后面还有几台其他机器，运行 Web 相关的东西以及一些其他东西。

如果你愿意，你也可以托管自己的电子邮件，我过去用 OpenSMTPD 做过这件事，非常成功——实际上是在 Raspberry Pi 上。你可以在我的网站上找到一些教程，了解我如何在 Arch Linux 上做到这一点，不过它们现在已经过时了，但它很长一段时间内运行得很好——直到一块硬盘坏了。我当时使用 Arch Linux 是为了好玩，也是为了看看维护起来有多难，因为 Arch 是前沿的。在我使用的那段时间里，它运行得非常好。通常我总是更喜欢 OpenBSD 和 FreeBSD。

除此之外，我建议采用贴近底层的方式，不额外增加层次，因为这样能让你更好地理解所使用的技术，也会减少问题的数量。使用 Docker 之类的工具或其他“花招”可能让上手更容易，但长期来看往往最终会造成不必要的问题。

不要害怕自托管！“云”基本上就是自托管，只不过是由别人替你做了而已 ;)

  • ~ atmosx 2026-11-11 07:25:14 你好 @pralkarz，我假设你的网络连接有足够带宽支撑一个小到中等规模的网站。由于涉及安全影响，自托管一个面向公网的服务比自托管私有服务（例如照片管理应用或媒体服务器）危险一个数量级。好的一面是，与 LAMP 栈相比，静态页面可以用相对较少的功夫安全地托管。(a) 应用网络分段是个好的开始。通过路由器/防火墙配置，RPi 不应能与其他设备通信。也许只允许基于 IP 或 MAC 地址的一台设备从局域网访问 RPi。(b) 然后设置 DNS 记录。我假设你拥有一个 FQDN。使用现成的或自定义脚本更新 DNS 记录。我使用 dnscontrol 配合 envsubst 来执行变更，但外面有更简单的方案。(c) 一旦 DNS 正常工作并正确更新，使用一个应用来签发 SSL 证书。我最喜欢的是 acme.sh，但也有不少打磨得不错的替代品，例如 certbot、lego 等。(d) 现在你可以设置反向代理了。注意像 Caddy 这样的现代反向代理可以自行管理 (c)。我不用它们，我熟悉 nginx，所以我用那个。(e) 创建一个权限最小的部署用户，并使用该用户通过 sftp 或其他安全协议上传数据。如果你想通过 git 设置部署流水线，通过 webhooks 也可以实现。(f) 加固系统。我很确定你可以直接封禁大型云厂商的 CIDR。这将使你免于愚蠢的扫描器滥用你的网站。由于很少有真人使用这些地址进行出站连接，我认为直接封锁它们是个好策略。你可以设置一个 cron 脚本下载 CIDR 并更新防火墙的“block”表。f.1 确保你设置了某种监控，以便能快速测量资源和传入请求等指标（例如响应延迟、传入请求数等）。由于你要自托管，你将拥有日志访问权限，这意味着完整的访客信息。f.2 你可能想探索设置“chroot”的可能性。f.3 告警：pushover 是一个不错的“主机 -> 手机”替代方案，另一个是设置 SMTPd，使系统能向你个人邮箱发送状态报告等邮件。(g) 在本地（例如另一台 NAS）或远程（backblaze 相当便宜）备份所有内容，或者两者都做。我想这就是我要说的全部 :-) 祝自托管愉快！

你好 @pralkarz，

我假设你的网络连接有足够带宽支撑一个小到中等规模的网站。由于涉及安全影响，自托管一个面向公网的服务比自托管私有服务（例如照片管理应用或媒体服务器）危险一个数量级。好的一面是，与 LAMP 栈相比，静态页面可以用相对较少的功夫安全地托管。

(a) 应用网络分段是个好的开始。通过路由器/防火墙配置，RPi 不应能与其他设备通信。也许只允许基于 IP 或 MAC 地址的一台设备从局域网访问 RPi。

(b) 然后设置 DNS 记录。我假设你拥有一个 FQDN。使用现成的或自定义脚本更新 DNS 记录。我使用 dnscontrol 配合 envsubst 来执行变更，但外面有更简单的方案。

(c) 一旦 DNS 正常工作并能正确更新，就使用某个应用来签发 SSL 证书。我最喜欢的是 acme.sh，但还有不少打磨得不错的替代品，例如 certbot、lego 等。

(d) 现在可以设置反向代理了。注意，像 Caddy 这样的现代反向代理可以自行管理 (c) 这一步。我没有用它们，我熟悉 nginx，所以就用 nginx。

(e) 创建一个权限最小的部署用户，用该用户通过 sftp 或其他安全协议上传数据。如果你想通过 git 建立部署流水线，也可以通过 webhooks 实现。

(f) 加固系统。我很确定你可以直接封禁大型云厂商的 CIDR 段。这能让你免遭那些愚蠢的扫描器滥用你的网站。由于很少有真人用这些地址发起出站连接，我认为直接封掉它们是个好策略。你可以设置一个 cron 脚本，下载 CIDR 并更新防火墙的“block”表。

f.1 确保你设置了某种监控，以便能快速测量资源乃至入站请求等指标（例如响应延迟、入站请求数等）。既然是自托管，你就能拿到日志访问权限，也就意味着完整的访客信息。

f.2 你可能想探索设置 “chroot” 的可能性

f.3 告警：pushover 是一个不错的“主机 -> 手机”方案，另一个是把 SMTPd 配置成系统能给你个人邮箱发送状态报告等邮件的方式。

(g) 把所有内容备份到本地（例如另一台 NAS）或远程（backblaze 相当便宜），或者两者都做。

我想我要说的就这些 :-)

祝自托管愉快！

  • ~ pgn 2026-11-11 10:55:51 呼应本帖目前为止的其他评论，我同样使用了 Tailscale/Cloudflare Tunnel 的组合。Tailscale 用于“个人”服务（Syncthing、远程唤醒等），而 Cloudflare tunnel 用于任何公开可用的服务（例如一个图书馆网站）。是的，相比尝试完全自建整套基础设施，学习成本肯定更低，但它免费且相当省心，同时在托管服务的方式上给了我更多灵活性。

呼应本帖目前为止的其他评论，我同样使用了 Tailscale/Cloudflare Tunnel 的组合。Tailscale 用于“个人”服务（Syncthing、远程唤醒等），而 Cloudflare tunnel 用于任何公开可用的服务（例如一个图书馆网站）。是的，相比尝试完全自建整套基础设施，学习成本肯定更低，但它免费且相当省心，同时在托管服务的方式上给了我更多灵活性。

  • ~ romforth 2026-11-11 11:22:23 Anders Pitman 收集了大量关于此的资源：https://github.com/anderspitman/awesome-tunneling 闭源和开源方案都有列出。从刚才查看的情况看，它似乎仍在积极维护中

Anders Pitman 收集了大量关于此的资源：

https://github.com/anderspitman/awesome-tunneling

闭源和开源方案都有列出。

从刚才查看的情况看，它似乎仍在积极维护中

The translation is machine-generated and individual terms may be off. Nothing is rewritten or cut; the original is authoritative.

Published by Lobsters
This site only summarises and aggregates; copyright stays with the original author. Headlines and summaries follow the source — where they differ, the original wins.
Read the original ↗