域名
- zrr.dev
- sixbone.dev
整体架构
公网服务(*.sixbone.dev)
公网可直接访问的服务,通常情况下这些服务自身具备认证功能, 或服务本身不涉及隐私信息。
- Vercel 部署
- Caddy 代理
- Caddy 代理 + Rathole 反向代理
TODO:
- 添加认证层
从逻辑上多个地点也只需要一个的服务称为逻辑公网服务, 但可能实际部署在内网服务器。 逻辑公网即所有公网服务。
如何确定一个服务是否应该是公网服务? 如果一个服务在多个位置可以同时存在(即使当前只存在一个位置), 且多个服务同时存在时在不考虑维护成本的情况下, 可以产生正向效益,则应该成为非公网服务。 也就是说,如果一个服务在多个位置不可以同时存在, 或同时存在时产生了冲突或没有意义, 则不应该成为公网服务。
如何确定一个服务是否应该是物理公网服务? 可以通过反向代理访问的应用,同时满足下列条件:
- 服务占用资源低
- 服务对稳定性要求高
物理公网
只有符合逻辑公网特点的才会成为物理公网, 物理公网服务直接部署在公网。
- blog.sixbone.dev
- slides.sixbone.dev
添加物理公网服务的 CheckList:
- DNS 解析(dns-manager的配置文件~/.config/dns-manager/sdns.json)
虚拟公网
实际部署在内网服务器, 但通过反向代理可以访问从公网访问。
短路跳转 如果局域网内可达,则跳过反向代理
添加物理虚拟服务的 CheckList:
- DNS 解析(dns-manager的配置文件~/.config/dns-manager/sdns.json)
LAN
home.sixbone.dev 目前只设置这一个
TODO:
- 添加认证层,但优先级较低
流量转发
需求:
- 转发 HTTP
- 根据域名转发到不同位置
方案:
- Caddy 不支持 TCP 层转发
- HAProxy 可以
- Nginx 可以,但是暂时不考虑