反向代理与域名

域名解析的等待

配完 DDNS 之后有一个新手经常误判的环节：域名不是立刻生效。DNS 记录的传播需要时间，短则几分钟，长则一两个小时。调试时用本地命令直接查询解析结果，比反复刷新浏览器靠谱。确认解析已经指向家里 IP 后，再排查端口转发这一层。

端口转发配错的位置通常是协议或者端口没对齐。手机 App 走的是 HTTPS，路由器上对应转发的也是 HTTPS 端口；如果只转发了 HTTP 那一个，浏览器的重定向能成功但 App 就是连不上。逐层检查：域名解析、路由器转发、代理监听、容器端口，一层一层确认过去，问题在哪一环一清二楚。多做几次之后这套流程会变成肌肉记忆，家里再添别的服务你也会用同一套方法排查。另外提醒一点：有些运营商会在城域网层面拦截常用端口，换成非标准端口往往一改就通，这类问题排查时可以一并测试。

DDNS 客户端本身也值得多看一眼。路由器内置的 DDNS 偶尔会出现解析更新不及时的情况——IP 变了但域名没跟着变，表现为外网访问时好时坏。定位办法是在异常时直接查询域名解析结果对比当前公网 IP，对不上就是 DDNS 更新滞后。改用软路由上的 DDNS 客户端通常更稳定，这也是很多自建用户把 DDNS 从路由器挪到软路由的原因。两条路并存也行：软路由跑主解析，路由器内置那条作为兜底。

为什么需要反向代理

直接用 IP 加端口访问 Immich，内网用得好好的，但手机 App 要正常工作、外链要能分享给朋友，HTTPS 基本是硬性要求。反向代理就是挡在 Immich 前面那一层：它对外提供标准的 HTTPS 入口，对内把请求转发给容器端口。顺手还解决另一个问题——多个服务共享 80 和 443 端口时，由代理按域名分发到不同容器。

对家庭用户来说，反向代理 + 域名 + HTTPS 这套组合的收益具体是三件事：出门在外手机 App 能同步、分享链接别人打开不是警告页、家庭网内多服务统一入口。搞清楚这三点，配置代理时就知道每一项在解决什么。

域名与 DDNS

家庭宽带很少有固定公网 IP，动态域名解析（DDNS）就是为此而生的：一个客户端程序定时把当前 IP 报给域名服务商，域名永远指向你家。大多数路由器内置 DDNS 功能，软路由上跑客户端也很常见，这块的具体配法可以参考《软路由从入门到精通》 的 DDNS 章节。

域名解析生效后，把它填到 Immich 的外部地址配置里（上一章提过的那项），这样服务生成的分享链接才是正确的外网地址。

这条外部地址配置同时影响手机 App 和网页分享。填错之后的症状很典型：你自己访问一切正常，点分享生成的链接别人打开是无效页面或者跳到内网地址。出了这类问题先怀疑这里，而不是代理。

证书还有几个常见问题值得提前知道。第一是证书到期：自己申请的免费证书有效期只有三个月，忘了续期某天突然全站打不开，而且没有任何提前通知；用 Caddy 的话自动续期，用 Nginx 就要配一个自动续期任务或者日历提醒。第二是域名数量：一张证书覆盖主域名加子域名最方便，多服务共用时注意证书的域名列表要匹配。第三是纯内网场景：实在没有域名时也可以用自签证书，但手机 App 要单独处理，不如直接弄个域名省心。

Nginx 还是 Caddy

两个最常见的代理工具，选哪个都行，区别主要在配置哲学。Nginx 历史悠久、资料最多，配置文件长一点但每个细节都在你手里；Caddy 的卖点是自动 HTTPS——配好域名之后它自己申请证书、自动续期，第一次用的人会觉得难以置信的简单。

对自建新手我一般推荐 Caddy：配置项少一个数量级，证书这块完全不用操心。对已经熟悉 Nginx、或者服务器上还跑着别的服务统一管理的用户，继续用 Nginx 也很合理。两者对 Immich 而言只是入口，不影响任何功能。从零开始的家庭用户，Caddy 的学习曲线明显更平缓，第一次配代理当天就能跑通外网。

一个折中方案是 Caddy 打底、先解决有无，等服务变多再视情况迁移到 Nginx。两套工具的配置可以长期共存，迁移成本远小于想象——代理不是数据库，换一个只是改配置文件然后重启的事。

无论选哪个，配置的骨架都一样：监听 443、指明证书位置、把请求转发到 Immich 服务端口。证书申请现在的免费渠道很成熟，Let's Encrypt 依然是主流选择，配合 Caddy 甚至零配置。

代理上的细节坑

配好骨架之后，还有几个细节坑值得单独提，它们都会让代理看起来通了实际上不对。

第一是上传体积限制。默认的客户端上传上限对照片足够，但视频可能超过默认值，大文件传到一半断掉，报错信息还很迷惑。代理层要放开请求体上限。

第二是超时时间。人脸识别和缩略图生成虽然不直接经过代理，但网页端某些管理操作耗时较长，代理超时设得太短会出现间歇性中断。

第三是 WebSocket。网页端的部分实时功能依赖长连接，代理需要显式放行，否则界面会静默退化为轮询，体感变卡。排查这三类问题有一个统一的办法：浏览器的开发者工具切到网络标签，刷一下页面看哪些请求失败——红色的一目了然，比猜日志快得多。

外网访问的三种形态

代理配好之后，外网怎么进来还有几条路。有公网 IP 时，路由器做端口转发最直接；没有公网 IP 时，内网穿透是常见替代，穿透服务把家里某台机器映射到公网入口；对安全性要求高的，干脆只开 VPN，出门连回家再访问内网。三者的核心区别是把谁放到了公网上——直接暴露服务、暴露隧道、什么都不暴露。

无论选哪条路，都建议给管理后台加上访问控制，并遵循最小开放原则：只开必要端口、强密码、关闭注册。这部分在全书最后的隐私加固一章还会展开。

一个常被问到的疑问是：代理本身会不会成为瓶颈？对家庭相册的访问量而言完全不会，代理的并发能力远超实际需求，真正决定响应速度的还是服务端和上行带宽。家里的上行带宽通常只有下载带宽的几分之一，这是外网看照片时偶尔慢的根源，和代理无关。外网加载慢的时候先测上行，别急着改代理参数。缓存 header 之类的高级优化对相册场景收益很小，把上行带宽想清楚比调任何参数都有效。

一个常见误解是把整台服务器都暴露到公网。反向代理的意义恰恰是你只需要暴露一个入口，而不是把整个内网摊开。端口转发只开代理需要的那一个，其他服务的端口一律不暴露。这样即便代理本身被攻击，影响面也仅限于相册这一层。

最后说一个安全层面的基本动作：代理日志值得偶尔翻一翻。不需要逐行看，扫一眼有没有异常密集的请求路径就够了。家庭服务的访问量有稳定模式，突然出现的流量尖峰通常意味着有人在扫你的端口，看到了就加固一轮。

小结

反向代理是 Immich 从内网能用到随时随地能用的关键一步：域名解析解决找到你家的问题，代理统一 HTTPS 与分发，证书由 Caddy 自动托管最省心。骨架配好之后，上传上限、超时、长连接这三个细节决定它是通了还是好用了。

延伸阅读

• 上一章《数据库与备份》：升级与维护的安全底线。
• 《软路由从入门到精通》：DDNS 与端口转发的路由器侧配置。
• 《OpenWrt 基础教程》：软路由上的网络入口管理。