有没有可能打杂也可以是一种职业主线😂

我没看明白。。。公司 13：00 午休结束，你睡到 13：00 ，这不是很合规吗？怎么跟摸鱼扯上关系的？

信息差真可怕啊。。。你这想法我在 2020 年就已经有了，但在那个时候都感觉已经晚了一步，那时上岸分数已经卷得厉害了。你现在才这么想，都晚到外国去了。

你们是刚来国内生活吗？😂

@rulagiti tailscale 再不济还能走中继，专治各种恶劣网络环境。就我这网络环境是从来没打动成功过，全靠 tailscale 中继了。

@rulagiti ipv6 也没有哦。房东的子网来的，房东也不懂这些。

现在 AI 这类翻译水平怎么样了？

@yangzzzzzz 请问啥是实况照片？我也在用极空间，但没玩过这个功能。感觉极相册一直那个样子。

上闲鱼花钱找人帮忙解决。

@jswh #2 我也改成你这样了，但还是报一样的错。。不过很奇怪，一年前我用同一套代码部署的，一点问题都没有，今年新买了一台云服务器，部署就各种报错。

头大，现在 https 网页访问没问题了，但 tailscale 客户端用 https 的服务器地址就死活不跳转。。。

@ray1980 derp 我以前自建过。所以这里只讨论了 headscale 相关。

没整明白，这个回扣怎么吃？我也负责公司的云采购，都是我叫财务直接往公司的阿里云账号上打钱，完事我直接下单买（阿里云运营会联系给我打折改价）。。。财务打进去的钱又不能提现，折扣力度大只是少花点，余额能撑久一点而已。

@lexfoxrush 卧槽，老哥我解决了！！我放弃了 Caddy ，让 deepseek 帮我写了一个 nginx 的反代，直接一步成功，现在自签名证书走 https 稳稳的，太爽了😁。。还是老玩意儿比新东西成熟靠谱啊。

-----

在这做下笔记，给后人指个路：
- 自签名证书生成 (假设服务器 IP 以 192.168.1.1 为例)：
```
openssl req -x509 -newkey rsa:4096 -sha256 -keyout private.key -out cert.crt -days 3650 -subj "/CN=192.168.1.1" -addext "subjectAltName=IP:192.168.1.1" -nodes
```

- nginx 反代配置：
```
# Headscale-UI 的反向代理（ 3001 -> 3000 ）
server {
listen 3001 ssl;
server_name 192.168.1.1; # 替换为你的服务器 IP 或域名

# 自签名证书路径
ssl_certificate /home/admin/docker/cert/192.168.1.1.crt;
ssl_certificate_key /home/admin/docker/cert/192.168.1.1.key;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

location / {
proxy_pass http://localhost:3000; # 将请求转发到 Headscale-UI
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

# Headscale 的反向代理（ 8081 -> 8080 ）
server {
listen 8081 ssl;
server_name 192.168.1.1; # 替换为你的服务器 IP 或域名

# 自签名证书路径
ssl_certificate /home/admin/docker/cert/192.168.1.1.crt;
ssl_certificate_key /home/admin/docker/cert/192.168.1.1.key;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

location / {
proxy_pass http://localhost:8080; # 将请求转发到 Headscale
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
```
Nginx 启动！！😁

-END-

@lexfoxrush 我用的阿里云的 Ubuntu22.04 ，和我 WSL 的版本一致。

@lexfoxrush 老哥你确定国内的云用 IP+自签名可以成功走 https 吗？
我今天又试了下，在本地电脑的 WSL 上搭了同一套，用 IP+自签名一点毛病都没有，正常启用 https 访问；但阿里云上就死活调不通😣

@lexfoxrush openssl s_client -connect <服务器 ip>:3001 -showcerts
CONNECTED(00000003)
801B3E9AD17F0000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1584:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 293 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

你的限速是我的满速😂

@lexfoxrush 老哥救命。。。。我现在也在尝试纯 IP 加自签名。
现在的情况是：
- 自签名的证书导入电脑，局域网内电脑架个纯 IP 的 Web 页面，可以成功走 https ，感觉自签名方式没问题
- headscale-ui 走 http 就能正常访问页面
- 给服务器自签名（ Caddy 反代里面配置），用 https 访问 headscale-ui ，Chrome 始终报错：ERR_SSL_PROTOCOL_ERROR

(headscale 在 8080 ，headscale-ui 在 3000)

我感觉这是 Caddy 有问题？
Caddyfile:
```
{
auto_https disable_redirects
}

https://<服务器 IP>:8081 {
tls /home/admin/docker/cert/crt.crt /home/admin/docker/cert/private.key #全局签名

@cors header Origin http://<服务器 IP>:3000
@options method OPTIONS

handle @options {
header Access-Control-Allow-Origin "http://<服务器 IP>:3000"
header Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE"
header Access-Control-Allow-Headers "*"
header Access-Control-Allow-Credentials "true"
respond 204
}

handle @cors {
header Access-Control-Allow-Origin "http://<服务器 IP>:3000"
header Access-Control-Allow-Methods"POST, GET ，OPTIONS, DELETE"
header Access-Control-Allow-Headers "*"
header Access-Control-Allow-Credentials "true"
}

reverse_proxy 127.0.0.1:8080
}


https://<服务器 IP>:3001 {
tls /home/admin/docker/cert/crt.crt /home/admin/docker/cert/private.key

reverse_proxy 127.0.0.1:3000
}

```