我们的部分后端服务正在经历容器化的改造， 由于历史包袱，现网的网关等设施无法一次性迁移到 k8s 集群中， 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
　　但是在使用时，我们发现一段时间后 Nginx 出现了 504 的错误，检查后端服务均是正常的，而单独访问 ALB 也是正常响应的，因此便有了此文。

作为一个拥有全端加密且能进行端到端连接的服务。Tailscale 现在的免费账户已经支持连接 100 台设备，这对于个人用户来说绰绰有余。我的内网设备几乎都在使用 Tailscale 连接。在前段时间发布的 用 VS Code 管理服务器，我有独特的服务器管理方式 中表明我很喜欢用 Remote SSH，我经常借住 Tailscale 组成的内网使用 Remote SSH 进行远程开发。

然而，Tailscale 在中国大陆的网络环境中存在一个问题，就是经常出现高延迟或者连接不上的情况。好在官方允许用户自建 DERP 服务，以充当中继，解决这个问题。再也不用担心写代码写一半就突然断了，而且优秀的网络体验也能提高 VS Code 的 Port Forward 的体验，方便远程预览开发。

由于我本身就有一台低配置的云服务器，过去曾经使用 Caddy 作为反向代理服务器来运行我的 Alist 项目。所以这次也考虑在同一台服务器上使用 Caddy 作为反向代理来部署 DERP 项目。

采用 Caddy 主要是他相比较于 Nginx 使用很简单的配置就能满足大部分需求，还有体验良好的自动 SSL 管理。能省很多事。

废话不多说，直接开始配置了。

配置 Docker

1
2
3
4
5
6
7
8
9
10
11

// docker-compose.ymlversion: '3'services:  derper:    image: fredliang/derper    restart: always    ports:      - 3478:3478/udp      - 23333:443    environment:      - DERP_DOMAIN=derp.example.com

然后启动

1

sudo docker compose up

配置 Caddy

1
2
3
4

// Caddyfilederp.example.com {    reverse_proxy localhost:23333}

重载 Caddy 的配置

1

sudo docker compose exec -w /etc/caddy caddy caddy reload

别忘了解析你的域名到你的 Caddy 服务器上。

配置 Tailscale

在 Access Controls 中配置

直达链接：https://login.tailscale.com/admin/acls/file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{  // ... 其他 ACL 配置  "derpMap": {    "OmitDefaultRegions": true, // 是否只连接自建 derper 节点    "Regions": {      "900": {        "RegionID": 900,        "RegionCode": "myderp",        "Nodes": [          {            "Name": "1",            "RegionID": 900,            "HostName": "derp.example.com", // 域名            "STUNPort": 3478,            "DERPPort": 443,          }        ]      }    }  }}

结束。

参考

1. GitHub - fredliang44/derper-docker: tailscale‘s selfhosted derp-server docker image
2. Custom DERP Servers
3. How NAT traversal works
4. Tailscale 基础教程：部署私有 DERP 中继服务器
5. 浅探 Tailscale DERP 中转服务

　　迫于无法忍受现成的 NAS 系统的限制，Alliot 正在着手将最常用的一些服务剥离出来，方便迁移与定制， WebDAV 首当其冲， Alliot 在许多场景下的同步与备份都依赖它。
　　WebDAV 作为一种基于HTTP/HTTPS协议的网络通信协议，预想是非常简单的，然而在具体动手的过程中还是遇到了挺多坑，Obsidian 的 Remotely-save 便是其中一个。
　　本文将基于 Nginx/Tengine 手把手构建一个 WebDAV 服务。

Nginx 阻止直接访问 IP 地址 443 端口的方法

　　出于安全考虑，通常我们会禁止直接通过 IP 地址访问服务器上的网站，Armstrong 就是这样做的。但这样做有个缺点，无论怎么做，都是要用一个网站做“牺牲者”，这真的是最优解吗？

　　我希望 Nginx 直接断开通过 IP 地址而非正确域名访问服务器的客户端，今天我在体验 1Panel 时，发现了他们的实现思路。简单说，1Panel 创建一个默认的 HTTPS 站点，并让 Nginx 拒绝与客户端进行 TLS 握手。下面是代码示例：

# Create an empty variable named viyf_443_empty
map "" $viyf_443_empty {
default "";
}

# Create a default 443 virtual host to block clients that access the server directly via IP address
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_ciphers aNULL;
ssl_certificate data:$viyf_443_empty;
ssl_certificate_key data:$viyf_443_empty;
ssl_reject_handshake on;
}

将如上代码加入到 nginx.conf 中第一个虚拟主机的上面，然后重新加载 Nginx 服务。

温馨提示：
1. 此方法仅能在 Nginx 1.19.4 及更新版本上使用
2. 如果定义了其他的默认站点（在 listen 中指定了 default_server 参数），请取消那些站点的 default_server