わたしの部屋

R2 CORS 跨域配置#

域名迁移后还需配置 CORS 策略，确保浏览器端对 R2 桶的跨域请求不被拦截。在 Cloudflare R2 控制台中为两个存储桶分别添加如下 CORS 规则：

1
{
2
  "AllowedOrigins": ["*"],
3
  "AllowedMethods": ["GET", "HEAD"],
4
  "AllowedHeaders": ["*"],
5
  "ExposeHeaders": [],
6
  "MaxAgeSeconds": 3600
7
}

音乐桶的原有自定义域名

原本绑定在音乐桶上的 music.dawn114514.site 自定义域名在迁移完成后即可删除 —— 因为此时所有引用地址已经改为 music.xxx.online，旧域名不再有任何流量。

截图预留：Cloudflare R2 自定义域名绑定成功截图

GitHub Secrets 配置清单#

双端部署需要的配置项总量并不多，关键是区分好国内和海外两套凭证：

为什么 DEPLOY_DIR 和 DEPLOY_PORT 不作为 Secret？

端口固定 22、部署目录固定 /www/wwwroot/MyBlog，这两项属于基础设施约定而非敏感信息。将它们硬编码在 Workflow 中有助于减少 Secret 数量，降低配置出错的概率。如果需要灵活性，可以在 Workflow 文件中以环境变量形式定义。

坑 1：国内机密钥带 Passphrase 导致部署失败与 CI 挂起#

我原来图省事，直接拷贝了国内阿里云服务器上现有的私钥文件（~/.ssh/id_ed25519）内容并填入 GitHub Secrets 的 DEPLOY_SSH_KEY_CN。然而，在 Actions 执行部署时，一直卡住并最终报错失败。（当时前 3 次全部红灯报错，连旁边放着的咖啡都急凉了 ☕）

后来在服务器本地自测该私钥才发现，原来这把密钥在初次生成时被设置了密码保护。在 GitHub Actions 这种非交互式的 CI 自动化环境下，SSH 握手因为需要输入密码而无法继续，最终导致部署直接被拒或挂死。

非交互式环境下的 SSH 陷阱

GitHub Actions Runner 是一个完全无头的自动执行环境。当 SSH 私钥设置了密码保护后，SSH 客户端会尝试弹出密码提示框或读取终端 /dev/tty。在 CI 中这完全行不通，最终会导致进程因为等待凭证输入而直接失败或无限挂起。因此，任何写入 GitHub Secrets 用于自动部署的 SSH 私钥，都必须是完全免密的。

解决办法：重新在本地生成一对免密的专属 Ed25519 秘钥对，把公钥追加到服务器的授权名单中：

1
# 本地生成免密 Ed25519 秘钥对（PowerShell）
2
ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\myblog-cn -C "github-actions-deploy-cn"
3
# 注意：提示输入 passphrase 时直接回车留空！

指纹审计核对：国内节点公网密钥的指纹为 SHA256…，部署前务必核对确认与服务器 authorized_keys 中写入的公钥指纹一致。指纹不匹配是 CI 连接失败的常见原因之一。

将私钥内容存入 GitHub Secrets 的 DEPLOY_SSH_KEY_CN，公钥追加至国内机的 ~/.ssh/authorized_keys，并锁死权限：

1
# 国内服务器上执行
2
mkdir -p ~/.ssh           # 如果目录已存在则无影响
3
chmod 700 ~/.ssh
4
cat ~/myblog-cn.pub >> ~/.ssh/authorized_keys
5
chmod 600 ~/.ssh/authorized_keys

NOTE

mkdir -p ~/.ssh 在目录已存在时不会报错，也不影响已有的 authorized_keys 文件，安全无害。

Secret 更新后记得触发重跑

这个坑导致我前 3 次部署全部失败，因为密钥替换后没有及时更新 GitHub Secret。务必在 GitHub 仓库的 Settings → Secrets and variables → Actions 中，删除旧 Secret 后重新创建（而不是编辑），确保存入的是完整的新密钥内容。更新后手动触发一次 Workflow 验证连通性。

坑 2：rsync 擦除宝塔锁文件 .user.ini 导致权限报错#

国内机用了宝塔面板，默认会在网站根目录下放一个防跨站的锁文件 .user.ini （宝塔面板：“我是为了你好！”；rsync：“你妨碍我全删全清了！”） （系统加了 chattr +i 只读属性防护）。Actions 里的 rsync -az --delete 机制在同步时发现本地没有这个文件，试图在远端将其强制抹除，结果直接权限报错导致发布管线崩溃。

解决办法：在 rsync 投递命令中加入 --exclude=".user.ini" --exclude=".well-known"，排除这些系统级只读文件以及 Let’s Encrypt 的验证目录。

坑 3：PowerShell 变量展开破坏 Nginx 配置#

在通过 SSH 远程写入 Nginx 配置文件时，如果使用双引号字符串或未加引号的 here-document，PowerShell 会把 $uri、$uri/、$host 等 Nginx 内置变量当作 PowerShell 变量展开，导致写入服务器的配置文件变成乱码。

跨平台字符串传递的隐形地雷

Windows 端的 PowerShell 会展开 $ 开头的 token，而 Nginx 配置中大量使用这些变量。一旦被展开，try_files $uri $uri/ /index.html 可能变成 try_files / /index.html（空值替换），导致 Nginx 语法检查失败。

解决办法：使用单引号 here-string（@'...'@）或 SSH 的 bash -s 模式传递配置内容：

1
# PowerShell 中正确传递含 $ 变量的配置
2
ssh user@host "bash -s" << 'EOF'
3
cat > /tmp/nginx.conf << 'NEOF'
4
location / {
5
    try_files $uri $uri/ /index.html;
6
}
7
NEOF
8
EOF

关键是在 SSH 端使用 'EOF'（单引号包裹，禁止本地 shell 展开），并且服务端也用 'NEOF' 禁止 bash 展开。

国内机：移除老旧的 TLSv1.1 协议#

国内节点使用的是宝塔环境，Nginx 版本为 1.28.1。在排查站点配置时，我发现旧的站点文件里还在支持已经不安全的 TLSv1.1 协议。

直接编辑对应的虚拟主机配置文件 /www/server/panel/vhost/nginx/html_xxx.xxx.xxx.xxx.conf，将老旧的 ssl_protocols 过滤收紧：

1
# 剔除 TLSv1.1，仅放行主流安全的版本
2
ssl_protocols TLSv1.2 TLSv1.3;

宝塔面板 Nginx 配置的查找方式

宝塔面板生成的站点配置文件位于 /www/server/panel/vhost/nginx/ 目录下，文件名格式为 html_xxx.xxx.xxx.xxx.conf。修改后务必执行 nginx -t 做语法检查，再 systemctl reload nginx 使配置生效。不要直接在宝塔面板 UI 中编辑后再手动改文件，容易产生冲突。

国内服务器优化后的典型 Nginx 站点配置参考：

1
server {
2
    listen 80;
3
    listen 443 ssl;
4
    listen 443 quic;
5
    http2 on;
6
    server_name www.dawn114514.site dawn114514.site;
7
    index index.html index.htm;
8
    root /www/wwwroot/MyBlog/dist;
9

10
    include /www/server/panel/vhost/nginx/extension/xxx.xxx.xxx.xxx/*.conf;
11
    include /www/server/panel/vhost/nginx/well-known/xxx.xxx.xxx.xxx.conf;
12

13
    ssl_certificate      /www/server/panel/vhost/cert/xxx.xxx.xxx.xxx/fullchain.pem;
14
    ssl_certificate_key  /www/server/panel/vhost/cert/xxx.xxx.xxx.xxx/privkey.pem;
15

16
    ssl_protocols TLSv1.2 TLSv1.3;
17
    ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:!MD5;
18
    ssl_prefer_server_ciphers on;
19
    ssl_session_tickets on;
20
    ssl_session_cache shared:SSL:10m;
21
    ssl_session_timeout 10m;
22

23
    # 启用极速 HTTP/3 (QUIC) 支持
24
    add_header Strict-Transport-Security "max-age=31536000";
25
    add_header Alt-Svc 'quic=":443"; h3=":443"';
26
    error_page 497 https://$host$request_uri;
27

28
    location / {
29
        try_files $uri $uri/ /index.html;
30
    }
31

32
    # 针对自建服务 A 与自建服务 B 的 WebSocket 反向代理转发
33
    # 依赖外部 0.websocket.conf 的全局 Upgrade map 指令
34
}

海外机：零面板环境下的安全加固与配置#

海外机用的是纯净 Ubuntu 系统，没有任何面板辅助。操作步骤如下：

第一步：安装基本服务

1
sudo apt-get update
2
sudo apt-get install -y nginx certbot python3-certbot-nginx

第二步：创建站点配置文件并测试

在 /etc/nginx/sites-available/myblog 中编写初始配置（仅 HTTP），确认 nginx -t 通过后 systemctl reload nginx。

第三步：利用 certbot 一键申请并修改配置

1
sudo certbot --nginx -d dawn114514.site -d www.dawn114514.site \
2
  --agree-tos --register-unsafely-without-email --non-interactive

该命令会自动在 /etc/nginx/sites-available/myblog 中添加 Let’s Encrypt 证书引用和 HTTP 强制跳转 HTTPS。

Certbot 非交互模式

--non-interactive 标志让 certbot 在无终端环境下自动完成证书申请，不需要手动输入邮箱或同意协议。加上 --register-unsafely-without-email 可以跳过邮箱注册步骤（适用于个人项目，生产环境建议填写真实邮箱以便接收证书过期提醒）。

第四步：突破防火墙双重过滤限制

海外机有两层防火墙需要穿透：

OS 级别 iptables 配置：

Iptables 尾部追加规则失效陷阱

Ubuntu 镜像在 iptables 中默认有一行拒绝规则：-A INPUT -j REJECT --reject-with icmp-host-prohibited，位于规则链的最底部。如果你习惯性地使用 iptables -A 往表尾追加 80/443 放行命令，这些命令排在 REJECT 后面会彻底失效。必须使用 -I INPUT 明确插到过滤表的头部（例如第 4、5 行）才会起作用。

1
# 正确示例：插入到过滤表的最前排
2
sudo iptables -I INPUT 4 -p tcp --dport 80 -j ACCEPT
3
sudo iptables -I INPUT 5 -p tcp --dport 443 -j ACCEPT
4

5
# 验证规则顺序是否正确（ACCEPT 必须在 REJECT 前面）
6
sudo iptables -S INPUT

云服务器平台防火墙放行：

除了系统内部的 iptables，甲骨文云在云平台外层还有一道安全规则守护。我们需要登录 Oracle Cloud Web 控制台，在机器关联的网络安全列表中直接添加两条简单的入站规则来放行流量：

Oracle Cloud 的 Always Free 资源包括每月 10TB 出站流量，对于个人博客来说完全够用。但要注意免费实例有资源回收策略——如果 CPU/内存/网络使用率长期过低，Oracle 可能会回收实例。建议配置一个简单的 cron 定时任务保持适度活跃。

海外节点优化后的站点配置文件（/etc/nginx/sites-available/myblog）结构：

1
server {
2
    server_name dawn114514.site www.dawn114514.site yyy.yyy.yyy.yyy _;
3
    root /www/wwwroot/MyBlog/dist;
4
    index index.html;
5

6
    location / {
7
        try_files $uri $uri/ /index.html;
8
    }
9

10
    # 对静态资源文件启用 30 天超长缓存，优化首屏加载
11
    location ~* \.(?:css|js|mjs|json|xml|txt|ico|png|jpg|jpeg|gif|webp|avif|svg|woff2?|ttf|otf|mp3|flac|ogg)$ {
12
        try_files $uri =404;
13
        expires 30d;
14
        add_header Cache-Control "public, max-age=2592000, immutable";
15
    }
16

17
    error_page 404 /404.html;
18

19
    # Certbot 自动化注入的 SSL 配置
20
    listen [::]:443 ssl ipv6only=on;
21
    listen 443 ssl;
22
    ssl_certificate /etc/letsencrypt/live/dawn114514.site/fullchain.pem;
23
    ssl_certificate_key /etc/letsencrypt/live/dawn114514.site/privkey.pem;
24
    include /etc/letsencrypt/options-ssl-nginx.conf;
25
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
26
}
27

28
server {
29
    if ($host = www.dawn114514.site) {
30
        return 301 https://$host$request_uri;
31
    }
32
    if ($host = dawn114514.site) {
33
        return 301 https://$host$request_uri;
34
    }
35

36
    listen 80 default_server;
37
    listen [::]:80 default_server;
38
    server_name dawn114514.site www.dawn114514.site yyy.yyy.yyy.yyy _;
39
    return 404;
40
}