类似于跨物理网段实现子网互通？无 tailscale 的设备想接入虚拟局域网，需要靠网内的 tailscale 客户端做 subnet 转发，不动上级路由做路由转发的话，基本搞不了

外部节点也要打开 tailscale 的接受子网通告

用过 winserver ，黑白群晖、unraid 和 PVE ，目前是白群晖 DS920+负责存储和 PVE all in boom 搭配使用

winserver：老生常谈了，作为商业性质的服务器系统而且是 windows ，硬件兼容性肯定相当不错，但我用的是 nuc8 ，对应的显卡驱动安装不上，所以最后装回 win10 扔家里当客厅桌面电脑用了。得益于 windows“生态”，一定程度上的“开箱即用”，像 Docker ，虚拟机之类的需求，官方有 Docker Desktop for windows(目前可以选择基于 Hyper-V 虚拟机运行或者 WSL 运行），找“免费”的 Vmware 跑虚拟机，各类功能需要都能大胆地去找.exe 实现。缺点是“软件兼容”，这个我描述不出来就举个例子，去 nginx 官网找 windows 版本运行，在涉及到路径时斜杠/和反斜杠\这一类情况时会出现无法预期的问题，在本地 NTFS 文件系统和 SMB 网络共享权限之间来回改设置摸索折腾，去搜索相关的模板都会大概率行不通，windows 的官方和第三方社区活跃度都很低，作为商业用途的 winserver 更甚，所以最终导致使用过程中整个系统在“自定义”方面，每天都在“大海捞针”，甚至“无功而返”

群晖：开箱即用，网页 UI 能搞定大部分功能设置，各种常用功能都是一键开启，SMB, FTP, Webdav, AFP, NFS 等等，权限管控设置起来比较详细，单纯作为主要存储手段，偶尔跑一些服务，非常够用；缺点主要是网络部分不够“自由”，包括并不限于各类套件仅监听固定端口且反代或 web server 不能自定义参数，SSL 证书没有界面可以设置实现类似 acme 的自动更新部署，系统魔改自 Linux 但内核模块会落后于新版本导致一些问题的通用方法没法套用等等

unraid：系统功能丰富，绝大部分需求都能通过社区维护，官方支持的软件市场获得，同样的有 Docker 和 VM ，就算设置完成后也能找到办法轻松扩展阵列；缺点是会有一些硬件兼容性问题无法简单解决，还有一些坑需要费时间摸索。硬件上最核心的问题，就是整个系统是从捆绑正版 key 的 U 盘内读取并运行在内存里，后期个人无法接受这一点，此外 unraid 似乎“不善于”处理会产生大量 log 的应用，之前有一段时间我跑 PCDN 忘记关传输 log ，导致隔一段时间后台管理界面就失联，但是各个 Docker 容器和 VM 是在正常工作的。所以最终个人建议不要用，去试试 truenas ，逛过很多国内外 NAS 社区评价都算不错。个人有博文一篇： https://blog.zakikun.com/archives/21.html

PVE：基于 Debian 的虚拟机管理平台，理论上 Debian 能干的事，它都能实现。硬件兼容性会好不少，Linux 、Windows 都能随便起一个虚拟机来跑，也能直接上 LXC 容器，相当“灵活”，最重要的是开源+免费。缺点是所有东西都得自己搞定，但由于它基于 Debian ，所以出现的问题大部分时候都能找到通用解法。个人也有博文一篇： https://blog.zakikun.com/archives/84.html

@sworld233 更正一下，刚才 pull 了 npm 的 v2.11.1 ，certbot 缺少 zope 的问题依然没解决，要用的话记得在里边安装一下 zope

去年 5 月份官方就有 PR 简单修复，但是一直没 merge
[官方 PR#2756]( https://github.com/NginxProxyManager/nginx-proxy-manager/pull/2756)

@Xingchen366 lucky 的 webui 比起 npm 配置反代更加“死板”，勉强够用

在 docker 容器里，涉及 web 服务有很大概率会在内部内置一个反代的 web server ，通常会默认做好服务监听和服务端口的转发，比如 elasticsearch 之类的容器镜像。

反代没有很复杂的点，无非就是正确地将请求转发给容器内部并确保容器能正确返回结果给客户端，但由于上述的一层反代会让情况变麻烦

如果想节省功夫开箱即用，最好是用二级域名区分服务，这样就不用研究容器内部是怎么处理网络请求的，缺点是需要记忆维护域名
如果想要用子路径反代容器服务，就得先了解熟悉容器内部的反代逻辑，然后正确配置 NGINX 的反代路径，在涉及到端口转发时会变得尤为麻烦，因为你还要研究容器内部是如何处理请求的。优点当然是域名通用，缺点也很明显，配置麻烦

ipv6only 官方文档说是一次性配置 This parameter is turned on by default. It can only be set once on start.
https://nginx.org/en/docs/http/ngx_http_core_module.html

最后说一下 NPM ，这个的确提供了一个比较方便的 webui ，内置 certbot 而且能设置成 dns challenge 轻松获得免费的通配域名证书，方便上 SSL 和自动更新，应对一般反代需求十分够用。
但配置上不够灵活，更新修复也不够及时(隔了快 5 个月才修复 certbot 依赖缺失问题)；它只提供了固定的一些反代配置，有些自定义内容会与模板冲突，想添加 stream 也只能在指定路径添加内容(data/custom/stream.conf)

https://kb.synology.com/zh-tw/DSM/help/CloudSync/cloudsync?version=7

官方套件说明好像也没详细介绍区别，只强调了一句：
複本衝突時的預設動作：
若本機 Synology NAS 及遠端公有雲帳號上的同一檔案或目錄同時被修改，Cloud Sync 會盡可能保留本地端的變更，並將遠端的變更另存為一修改版本 (若該雲端服務支援版本管理)。

重建链接的场景是你和公有云连接短暂断开，但本地文件有变动时会采取的操作，这个我猜测应该是还原文件操作历史，而不是对比检测同步文件状态；
同步方向的场景是你和公有云保持连接时，本地文件和公有云之间的文件同步策略

最简单的办法，建一个空白文件夹测试一下就完事了

@nrtEBH 组件其实都在，可以通过一些手段强制开启，不过说实话还是直接换成专业版系统更舒服

要在公网上提供服务就避免不了 IP 暴露，互联网工作原理摆在那。要么做个反代跳板隐去真实服务 IP ，要么用 VPN 、wireguard 之类套一层加密回去访问

草，我能吐槽一下 microsoft remote desktop 环大陆上架么

来了来了，感谢 OP 赠送，不管我有没有领到

@xqk111 哈哈哈，厨子刀法就这样，18G 上 36G 要加 3000 呢

11C 太膈应了，上了 12C 的丐版

@qoras 不太清楚 MacOS 的内存机制和需要，18G 应付不了日常 office 三件套和轻量的小型程序开发吗？

我是打算，毕竟性能、移动设备、续航时长，M 系的 Macbook 基本全占了，实在忍不住入坑从 windows 阵营转到 MacOS 试试

当时看着 M3 那恶心的配置和模具组合，只能在 M3 Pro 和 M3 Max 里选了，充分考虑到钱包和需求之后，最后还是选择了 M3 Pro 6P6E+16G RAM

没办法，M3 Max 升档加钱太狠了，我就一个臭办公人员，100%肯定不需要那么多性能和 RAM ，当然也没那么多钱。和 Max 拉开的性能差距，在使用中未必会变成短板，比如楼主说的内存带宽缩水、多核性能差距小