看懂 NAS、
网络与网站
程序和数据在家里。域名帮你找到入口，网络通道把请求送进去。
从域名到数据，连成一张图
先沿连线看整体，再点节点看职责。上面管名字，下面是请求真正到达 NAS 的路线。
左右滑动看完整框图；绿色框内是家中的 NAS。
网站和应用运行在 NAS，域名不负责保存内容。
实线按请求方向阅读，响应沿连接返回；虚线不表示网页内容流经注册商或 DNS。
家里的路由器、光猫与交换机在哪一层？
家庭光纤 → 光猫 → 路由器 → 交换机／Wi-Fi → NAS 与电脑。它们提供基础网络连接；Caddy 和各个应用运行在这套网络之上。NAS 替代云服务器后，供电、上行带宽和网络通道仍决定可用性。
同一台 NAS，可以有不同入口
切换场景。注意“请求经过谁”，以及“访问者需要什么条件”。
为什么 Tunnel 不需要家里拥有可直接入站的公网 IP？
NAS 上的 cloudflared 先主动连接 Cloudflare，并保持连接。Cloudflare 收到访客请求后，利用这条连接送到 NAS。访客连接 Cloudflare 所用的 IP 协议，不必与 NAS 使用的一致。
上图箭头表示网页请求的传递方向；Tunnel 最初的网络连接由 NAS 向外建立。
不用 IPv6，也可以访问家里的服务
IPv4、IPv6描述的是网络连接方式，账号密码负责登录。现在某个入口要求IPv6，是因为它目前只提供了IPv6直连路线；换成可用的Cloudflare转发入口后，同一个账号仍可登录。
| 路线 | 访问者这一段 | 回到NAS这一段 | 适用与条件 |
|---|---|---|---|
| IPv6直连 | 浏览器 → NAS公网IPv6 | Caddy → 应用 | 两端需要可用IPv6，入站和HTTPS已配置；照片、大文件可保留这条路线。 |
| Cloudflare橙云回源 | 浏览器用IPv4或IPv6 → Cloudflare | Cloudflare → NAS可入站的IPv6 → Caddy | 能桥接访问端IPv4与源站IPv6；前提是Cloudflare真正能连接源站，改云朵不保证成功。 |
| Cloudflare Tunnel | 浏览器用IPv4或IPv6 → Cloudflare | 现有隧道 → NAS上的cloudflared → 应用／Caddy | NAS主动连出，无需公开入站IP；适合登录网页、聊天与控制面板。仍要验证隧道、登录和应用兼容性。 |
上方路线按钮新增“橙云回源”；取消“访问者有可用IPv6”，可以看到直连不成立，而橙云和Tunnel仍具备协议条件。这是原理演示，不会配置任何服务。
我有IPv6时，会自动绕过Cloudflare走直连吗？
不会。域名如果启用了Cloudflare代理，IPv4和IPv6访问通常都先到Cloudflare。客户端自动选择IPv4或IPv6，只是在选择“怎样连接Cloudflare”，不等于选择“是否绕过Cloudflare”。
若想兼顾兼容性和直连性能，可以保留两个明确入口：日常入口经Cloudflare，另一个入口只做DNS解析、用于IPv6直连。它们连接同一个应用、账号和数据库，不需要复制数据，也不需要为每个入口新建一个应用容器。具体名称需在实施时确认。
直连是不是更快？Cloudflare能加速生成声音吗？
直连少一个转发环节，线路良好时往往延迟更低；经过Cloudflare可能绕路，也可能因线路更好而更稳。不能仅凭IPv6或IPv4的名字判断快慢，国内不同运营商、学校和移动网络需要分别实测。
酒馆回复的等待包含模型服务的生成时间；声音工作室还受NAS的CPU推理和任务队列影响。网络改快，只能改善网页、首段传输和下载，不能让同一个模型凭空算得更快。照片原图与视频的速度还取决于家庭上行带宽。
实施后比较：登录成功率、流式首字／首段、一次正常任务的等待、同一文件下载速度。没有这些实测前，只能给路线建议，不能承诺提速。
为什么不把所有服务直接改成橙云？
橙云回源需要Cloudflare能连到NAS。源站地址、路由、防火墙或TLS不匹配都可能导致失败；522定位的是Cloudflare到源站的一段超时。Tunnel可换一条回家路线，但隧道在线、路由正确也仍要分别验收。
经Cloudflare的HTTP上传仍受单次请求大小等限制。官方目前列出的Free、Pro上限为100MB；可以被区域设置调低。这不是总存储容量限制，能否分块上传要看应用。大视频和原图批量上传不能只根据首页能打开就认定可用，Tunnel也不自动消除这些限制。
聊天的流式响应、WebSocket、长时间语音任务及上传需单独验证。代理应保留应用原生认证和TLS校验，私人聊天、健康资料与认证接口不应被公共缓存。
依据：DNS-only与橙云、IPv6兼容、Tunnel、请求大小限制、WebSocket；核对日期2026-10-27。
网址就是一张有层次的地址条
点彩色部分，看它定位的是哪一层。
LOOPBACK_ADDRESS
Windows 用它找 Windows；NAS 用它找 NAS；普通容器里通常找容器自身。
NAS_ADDRESS
你家 NAS 的内网地址。在学校输入同样的地址，目标不会自动变成家里。
公网 IPv4／IPv6
用于互联网通信。是否能被访问，还要看路由、防火墙和服务是否监听。
DNS 的 A、AAAA、CNAME、NS 与 DDNS，各管什么？
A：名字对应 IPv4。
AAAA：名字对应 IPv6。
CNAME：名字指向另一个名字。
NS：指定这个域名由谁提供权威解析。
DDNS：地址变化时更新记录。
它们不会自动安装应用、开端口或打通线路。
子域名能有多少个？每个都要买？
www、photos、health 是 example.com 下面自行安排的名字，通常不必逐个购买。www 不是必须。example.net 则是另一个独立域名。
Cloudflare 当前免费区域通常受 200 条或 1,000 条 DNS 记录配额限制，取决于区域创建时间；一个名字可能使用多条记录。起名字的数量与 NAS 能运行多少应用分别计算。
LOOPBACK_ADDRESS:端口，让极空间连接 NAS 本机服务。把它复制进 Windows 浏览器，会指向 Windows 自己。域名在阿里云买，为什么编辑子域名却用Cloudflare API？
注册商和DNS托管商可以不同。域名注册、续费和NS委派由注册商管理；NS指向Cloudflare后，子域名的CNAME、A、AAAA等DNS记录由Cloudflare管理。调用哪家API，取决于这次修改的是哪一家的记录。
例如某域名在阿里云注册、DNS托管在Cloudflare：新增一个子域名的CNAME记录，应调用Cloudflare DNS API；这一步不需要调用阿里云API。若以后修改阿里云账户中的注册、续费或NS委派，则是另一项操作。
CNAME指向另一个域名，是网页会先跳过去吗？
不是。CNAME是“查找地址时使用的别名”，不是HTTP网页重定向，也不表示那里多了一台转发服务器。解析器沿别名找到最终IP后，浏览器按原来的服务域名连接服务器，Caddy再把请求交给对应应用。
多个业务域名引用同一个家庭入口别名，可以复用地址维护：家庭公网IP变化时，只要原DDNS及时更新那个别名对应的地址，各业务域名就能在DNS缓存更新后找到新IP。该别名本身不等于Cloudflare Tunnel，也不会自动让IPv4访问者连上仅IPv6的服务。
API负责修改DNS记录；DNS负责查地址；网页请求按已配置的直连、橙云或Tunnel线路传输。三件事分开看。
一个应用，可以由几个容器合作
容器名、内部端口、外部网址是不同层的名称，不必一一对应。
NAS_ADDRESS:APP_PORTAPP_PORT
APP_PORT
这是教学用的端口映射例子。映射到 NAS，不等于已经开放互联网访问。
镜像、容器与容器名字，怎样区分？
镜像是打包好的程序环境；容器是根据镜像创建的运行实例；Compose 项目把相关容器及网络、存储配置组织在一起。web_ 等前缀是维护名称，photos 是域名名称，二者不必相同。
数据库和 worker 通常没有供你日常使用的网页，也不需要每个都分配子域名。DockerCopilot 等工具管理容器生命周期，不会因此成为所有应用数据的统一后台。
极空间“不让用”的端口，限制的是哪一层？
某些极空间版本的清单针对极空间“远程访问”的 NAS 本机目标端口，并不表示容器内部不能使用同样的端口。示例中给相册增加 APP_PORT 入口，就是为了适配那条远程访问路线；原来的 2283 仍可用于已配置的家中访问。
都叫“代理”，工作却不同
先看箭头方向，就能分清 Cloudflare、Caddy 和 Clash。
橙色云朵与“只解析”：点开看差别
橙云也不等于 Tunnel。回到 NAS 的方式，仍要看是否配置了隧道或可入站的源站地址。
有了 NAS 代理，Windows 可以关机吗？全部流量都自动经过它吗？
NAS 上独立运行的 Mihomo 不依赖 Windows 的 Clash Verge。但应用出网、Docker 镜像下载和系统出网可能分别配置；安装容器不代表全部流量都接管。TUN 会涉及更广的网络路由，不能与普通应用代理混为一谈。
Caddy、Nginx 和 Cloudflare，分别站在哪一层？
这台家庭 NAS 建议继续用现有 Caddy。网页、多个域名转发和 HTTPS 都已有对应能力；目前没有发现必须换成 Nginx 才能满足的需求。两者的性能需要按实际负载测量，不能只凭软件名称判定谁更快。
每个应用可以分别采用不同路线；图中只演示所选的一种。切换只改变示意图，不修改 NAS。窄屏可在图内左右滑动；点方框查看职责。
根据访问的域名或路径，把请求交给正确应用，也能直接提供静态网页。Nginx 可以承担同一层职责；这里不需要把两者串起来。
同一层的选择：Caddy 或 Nginx。可以共同工作：Cloudflare ＋ Caddy，或 Cloudflare ＋ Nginx。仅把 DNS 放在 Cloudflare，不表示网页流量一定经过 Cloudflare。
| 比较项 | Caddy | Nginx |
|---|---|---|
| 主要职责 | 静态网页、反向代理、HTTPS；可在 NAS 的 Docker 中运行 | 同样能做网页、反向代理和 HTTPS，也可用 Docker 运行 |
| HTTPS 维护 | 默认整合证书申请、续期与 HTTP→HTTPS；仍须满足域名验证和存储条件 | 可配证书工具，也有官方 ACME 模块；需核对镜像是否包含模块并配置，不能说“只能手工续证书” |
| 常用配置 | Caddyfile 对普通多域名转发较简洁；另有 JSON 配置和管理 API | nginx.conf 通过 server/location 等配置，细项控制多；需要熟悉规则匹配和继承 |
| 特殊功能 | 现有反代、静态服务已覆盖当前用途；额外模块要按实际需求核对构建 | 有内置 proxy_cache 等细分控制；有明确模块或既有工程依赖时更值得考虑 |
| 对你的迁移成本 | 继续复用现有配置，维护域名入口和原生登录即可 | 改用它需迁移和复核证书、转发头、路径、上传和实时连接等规则；目前没有证明这能改善手机超时 |
| 性能判断 | 本轮没有进行两者的同负载对照压测，不给出谁更快、谁更省内存的结论。当前选择主要依据功能已满足和维护成本。 | |
公开使用指标：热度、下载与安装量分别看
查询日期：2026-10-27。Stars 是仓库关注度；Docker Hub pull 是镜像拉取次数，包含重复拉取、更新和 CI，不能当作独立安装人数。
| 对象 | GitHub stars | 公开下载指标 | 独立安装量 |
|---|---|---|---|
| Caddy | 78,461 | 官方镜像累计 752,347,062 次 pull | 本轮所查官方来源未公开统一口径 |
| Nginx | 31,978 | 官方镜像累计 13,516,597,041 次 pull | 本轮所查官方来源未公开统一口径 |
| Cloudflare 云服务 | 不适用：没有代表整个平台的单一软件仓库 | 不适用：云服务不是一个供下载的程序 | 不适用：云端客户数不能视为 NAS 软件安装量；cloudflared 连接器是另一统计对象 |
官方依据：Caddy 自动 HTTPS、Caddyfile、Nginx 配置与转发、Nginx 官方 ACME 模块、Nginx 代理与缓存、Cloudflare DNS 和代理、Tunnel 与 cloudflared。
本段沿用现有知识页设计；HTML workflow 负责独立成品及按影响验收，Source Search 负责官方来源和指标，diagram-design用于架构分层和正交连线，visual-explainer用于让图形与文字同步解释。第三方来源以本机技能包的来源记录为准。
统一首页，各自保存数据
结构化数据属于相应应用。SQLite 没有统管整台 NAS。
统一入口
首页卡片把服务聚到一起。普通导航首页就能做到。
统一登录
需要各应用支持并配置身份集成。同名账号仍可能彼此独立。
统一数据
需要数据模型和接口集成。共用域名不会自动合并数据库。
放在一个域名的不同路径里，可以吗？
支持子路径的应用可以使用 www.example.com/family/ 这样的入口。Immich 官方不支持 /immich/ 这样的子路径，需要位于一个域名或子域名的根路径，所以 photos.example.com 有实际兼容性用途。
Caddy 按域名或路径分发；多个域名可以共用外部 HTTPS HTTPS_PORT 端口。示例中的首页由 Caddy 提供静态 HTML，没有另装一个能编辑全部内容的统一 CMS 后台。
Agent、SSH、GitHub 分别怎样参与维护？
Agent 所在电脑 → SSH 登录 NAS → 按授权执行文件、Docker、Compose 或应用 API 操作。SSH 连接的是 NAS 操作系统，然后才能管理其 Docker。
GitHub 保存经过确认的说明、代码和配置参考，帮助换电脑接续；它不会自动提供到 NAS 的连接，也不应承接私人原件、凭据和活动数据库。关闭维护终端通常不影响已经独立运行的容器；依赖终端前台运行的任务要另看启动方式。
把问题放回对应的那一层
点一个疑问，看原因在哪段，以及它不能说明什么。
这是不同的验收层次。前一步成功，不能直接推出后一步已经通过。
连接检测、测速和登录，分别验证什么？
先确认测试设备是否启用了代理或 VPN。桌面代理可能返回虚拟 DNS 地址；即使用了“忽略 HTTP 代理”参数，系统级转发也可能仍在生效。本机能打开不能代替手机流量、另一家运营商或无代理网络的实测。
| 检查 | 可以证明 | 还不能证明 |
|---|---|---|
| DNS 与有效 HTTPS | 该次查询、地址选择与证书校验通过 | 另一台设备使用了同样的解析、协议或网络路径 |
| 小请求返回 204 | 浏览器经当前域名到 NAS 的诊断入口可达 | 业务应用健康、账号已登录或能保存数据 |
| 下载与上传采样 | 该设备、该域名、该时间的有效收发速度 | 运营商带宽、千兆极限、模型生成速度或长期稳定性 |
| 原生登录与只读业务 | 这次会话的登录、权限及所检业务通过 | 不同域名共享登录，或所有手机网络均已通过 |
已有 Caddy 时，轻量诊断可以复用它的文件服务、状态响应与受限请求缓冲。业务网页仍沿原路径转发，不必为添加测速按钮改写各应用 HTML，也不必新增容器。示例采样为下载 16 MiB、上传最多 1 MiB；手动开始、可停止，上传必须等完整样本被接收后才确认。
下载镜像的代理，会把外部网站访问也接管吗？
通常是不同方向：镜像代理处理 NAS／Docker 向外访问镜像仓库；网站入口接收访客向内访问。只有另行配置系统级路由、TUN、透明转发，或业务程序也使用了代理时，影响范围才可能扩大。判断时查实际配置与路径，不能只凭“装了代理容器”。
同一设备、同一网络有些域名能开、有些超时，应逐一比较 DNS、TLS、域名路由和浏览器状态；不能直接认定没有 IPv6，也不能直接认定 Docker 损坏。
为什么响应头的小改动也可能让登录报“已过期”？
反向代理附加的策略可能改变浏览器行为。例如，部分表单提交在 Referrer-Policy: no-referrer 下会发送 Origin: null，即使会话中的校验令牌正确，应用仍可能拒绝。应保留应用原有响应头并实际提交一次原生登录，不能通过关闭来源或 CSRF 检查来修复。
来源、配置边界与使用方法
本页使用虚构域名 example.com、example.net 和示例私网地址讲解原理。页面文字、图中标签与交互分支均已转换为教学示例；请勿把示例地址当作可访问服务。功能限制请以所链接的官方文档和实际版本为准。
制作与修订：HTML 方法（单文件与本地批注）、报告批注组件、frontend-design（沿用布局与比较表）、ponytail（局部改动）、Playwright CLI（页面验收）；容器与端口概念参考 Docker Docs。个人方法不含远程接口；工具来源见 Playwright CLI 与 Docker 文档。
这个完整 HTML 同时是编辑源，正文、样式、脚本和批注组件均在文件内；复制单个文件即可离线阅读。外部链接只用于扩展来源。批注保存于当前浏览器，需“复制反馈”或导出 JSON 后交给助手；不会自动发送。调整布局只是阅读偏好。