教程 on 美味芝士

给 GitHub Pages 绑定自己的子域名：从仓库设置到 DNS 解析、HTTPS 全记录

Mon, 26 Oct 2026 00:00:00 +0000

GitHub Pages 默认给 *.github.io 地址，想换成自己的子域名（如 www.whysoso.com）只需两步：GitHub 仓库里声明自定义域名 + 注册商加 DNS 解析。本文用 www.whysoso.com → whyboystudy.github.io 实操为例，记录完整流程与踩坑。

第一步：GitHub 仓库里填自定义域名

进 Pages 仓库（用户页即 <用户名>.github.io）→ Settings → Pages → Custom domain，输入子域名（如 www.whysoso.com），点 Save。

GitHub 会自动在发布分支根目录生成 CNAME 文件（内容即你的域名），这是它识别自定义域的依据，别手删。

此时先别勾 Enforce HTTPS——证书未签发前强制会陷入重定向循环。

第二步：注册商加 DNS 记录

子域名只需加 1 条 CNAME 记录，指向 <用户名>.github.io（本文即 whyboystudy.github.io）。

记录要加在真正托管 DNS 的那家：看域名的 NS 指向谁。本文 whysoso.com 注册在 Spaceship，但 NS 已指向 Cloudflare，所以记录在 Cloudflare 加。

方案 A：域名在 Spaceship（自托管 DNS）

Domains → 域名 → Manage → Advanced DNS。
加 1 条 CNAME：Type CNAME，Host www，Value whyboystudy.github.io，TTL Automatic。

方案 B：域名在 Cloudflare（或 NS 已指向 Cloudflare）

选域名 → 左侧 DNS → Records → Add record。
加 1 条 CNAME：Type CNAME，Name www，Target whyboystudy.github.io，TTL Auto。
Proxy status 先设 DNS only（灰云），原因见常见坑。

照抄填的记录表（Cloudflare 版，本文实际用的）：

Type	Name	目标	Proxy
CNAME	www	whyboystudy.github.io	DNS only（灰云）

第三步：验证生效 + 开启 HTTPS

DNS 全球生效需几分钟到几小时。验证：

1
2

nslookup -type=CNAME www.whysoso.com  # 应链到 whyboystudy.github.io
dig +short www.whysoso.com            # macOS / Linux 也可用

本文实测 www 的 CNAME 链为 whyboystudy.github.io → 185.199.108~111.153，即生效。

回到 GitHub Settings → Pages：等 DNS check 变绿勾 → GitHub 自动签发免费证书 → 证书就绪后勾 Enforce HTTPS。

第四步：Hugo 改 baseURL 并重新部署

hugo.yaml / config.toml 里的 baseURL 必须同步，否则站内链接、RSS、sitemap 仍是 .github.io：

`1`	`baseURL = "https://www.whysoso.com/" # 本文实际用`

改完重新生成并推送（push 触发 Actions 自动部署）。

第五步：防止部署清空自定义域名（CNAME）

如果你用 GitHub Actions 部署（如 peaceiris/actions-gh-pages），会出现「每次 Action 跑完 Custom domain 变成空、跳回 *.github.io」——这是最高频的坑，本文 www.whysoso.com 就栽在这。

原因：在 Settings → Pages 填域名后，GitHub 把域名写进发布分支根目录的 CNAME 文件来记住它。但这类 Action 是「用 PUBLISH_DIR（如 ./public）强制覆盖发布分支、清掉其他文件」，而你的 public/ 里没有 CNAME → 每次部署把 GitHub 写好的 CNAME 冲掉 → 域名被清空。

修法：在 Hugo 源码的 static/CNAME 写一行域名（如 www.whysoso.com，不要多余空格或空行）。Hugo 构建时把 static/ 原样拷到 public/，于是 public/CNAME 每次都进发布分支，域名就稳了。

注意：

若工作流 EXTERNAL_REPOSITORY 指向另一个仓库（本仓库只放源码、部署到 用户名.github.io），CNAME 落到那个仓库的发布分支——正是 Pages 读取的地方，无需在本仓库根放 CNAME。
带 CNAME 的部署跑完后，回 Settings → Pages 把自定义域重填一次；之后分支里一直有 CNAME，再也不会被冲掉。

常见坑

Cloudflare 代理（橙云）导致证书签发失败 加记录时先 DNS only（灰云），等证书签发、站点正常后再按需开橙云（CDN 加速）。Cloudflare 的 SSL/TLS 模式设 Full（非 Flexible），否则与 GitHub 的 HTTPS 互重定向成死循环。

域名未注册就加解析 记录只对已注册、NS 已委派的域名生效。先确认 RDAP / whois 域名已存在（本文 whysoso.com 是当天在 Spaceship 注册、NS 指向 Cloudflare 后才配的）。

实战小结

whysoso.com 注册于 Spaceship → NS 指向 Cloudflare → Cloudflare 加 1 条 CNAME（www → whyboystudy.github.io）→ GitHub Pages 填 www.whysoso.com → 证书签发后 Enforce HTTPS → Hugo baseURL 改 https://www.whysoso.com/ 并重部署 → static/CNAME 锁定域名不被部署清空。核心三句：GitHub 声明域名、注册商 DNS 加 CNAME 指到 <用户名>.github.io、证书出来再强制 HTTPS。Cloudflare 用户记「先灰云后橙云、SSL 用 Full」即可。

Ubuntu VPS 搭建 XFCE 远程桌面：从 xrdp 安装到秒断修复、中文输入与 WorkBuddy 实战

Sun, 25 Oct 2026 00:00:00 +0000

在一台只有 2~4G 内存的 Ubuntu VPS 上想要图形界面，GNOME/KDE 太重、跑起来又卡又容易崩。XFCE 是更现实的选择：轻量、稳定、依赖少。本文记录一套能长期稳定跑起来的组合 xrdp + XFCE，以及我在真机上踩过的每一个坑——尤其是「连上秒断」「中文输入法不生效」「snap 版浏览器起不来」「WorkBuddy 闪退」这几类。所有命令都来自实际操作，可直接照抄。

环境假设：Ubuntu 22.04/24.04，全新 VPS，已能 SSH 登录，root 权限。

先想清楚：为什么是 xrdp + XFCE

XFCE 轻量：空闲内存占用几百 MB 量级，在低配 VPS 上能留足余量给浏览器和应用。GNOME 在最小安装服务器上经常直接弹出 “Oh no! Something has gone wrong” 崩溃。
xrdp 原生 RDP：Windows / macOS / 手机都有现成的远程桌面客户端，不用额外装 VNC viewer。默认端口 3389。
关键结论：xrdp 默认会去调 GNOME，而最小安装里没有完整的 GNOME，所以必须显式强制 XFCE，否则一定崩。这是后面所有配置的前提。

第一步：创建专用登录用户

不要直接用 root 登录远程桌面，单独建一个普通用户（本文用 napnap，uid 1001）。很多桌面组件在 root 下行为异常，且安全风险大。

# 交互式创建（会提示设密码）
sudo adduser napnap

# 给 sudo 权限（方便后面装软件）
sudo usermod -aG sudo napnap

如果用非交互方式：

1
2
3

sudo useradd -m -s /bin/bash napnap
sudo passwd napnap
sudo usermod -aG sudo napnap

记一下 uid，后面排查会用到：

1
2

id napnap
# uid=1001(napnap) gid=1001(napnap) ...

第二步：安装 XFCE

1
2

sudo apt update
sudo apt install -y xfce4 xfce4-goodies

xfce4-goodies 是可选组件包（终端、电源管理、截图等小工具），建议装上，体验完整很多。

必装的配套：dbus-x11。 这一步很多人漏掉，后果就是后面「秒断」。XFCE 启动依赖 D-Bus 会话总线，dbus-x11 提供 dbus-launch：

`1`	`sudo apt install -y dbus-x11`

第三步：安装 xrdp

1
2
3

sudo apt install -y xrdp
sudo systemctl enable --now xrdp
sudo systemctl status xrdp --no-pager

装完确认两点：

服务 active (running)；
3389 在监听：

1
2

sudo ss -tlnp | grep 3389
# LISTEN 0 2 *:3389 *:* users:(("xrdp",pid=...,fd=11))

如果开了防火墙（ufw），放行端口：

`1`	`sudo ufw allow 3389/tcp`

云厂商侧（AWS 安全组 / 腾讯云安全组等）也要放行 3389 入站，否则客户端会一直「无法连接」。

登录用户的会话文件：在 napnap 家目录放一个 .xsession，告诉 xrdp 用 XFCE 会话：

1
2

echo "xfce4-session" > /home/napnap/.xsession
chown napnap:napnap /home/napnap/.xsession

即使后面用 startwm.sh 直接 exec startxfce4，这个文件也建议保留，能避免 xrdp 找不到会话类型时回退到 GNOME。

第四步：改 startwm.sh——解决「连上秒断」

这是整篇文章最关键的坑。不改这里，连上去会黑屏一下立刻回到登录界面，日志里写着 Window manager exited quickly (0 secs)。

xrdp 真正执行的是 /etc/xrdp/startwm.sh。默认脚本在最小安装下起不来 XFCE。把整文件替换成下面这个经过验证可用的版本：

#!/bin/sh
# 1. 补回 Xsession 会做的基础环境（语言、编码）
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
# 2. XFCE / D-Bus 用户总线依赖 XDG_RUNTIME_DIR，没有就建
if [ -z "$XDG_RUNTIME_DIR" ]; then
  XDG_RUNTIME_DIR=/run/user/$(id -u)
  export XDG_RUNTIME_DIR
  [ -d "$XDG_RUNTIME_DIR" ] || mkdir -p "$XDG_RUNTIME_DIR"
fi
# 3. 阻止 systemd 误判窗管退出、清掉可能失效的旧 dbus 地址
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
# 4. 强制用 XFCE，并把所有输出重定向到日志方便排查
exec startxfce4 > /home/napnap/startxfce4.log 2>&1

写入方式（root）：

sudo cp /etc/xrdp/startwm.sh /etc/xrdp/startwm.sh.bak   # 先备份
sudo tee /etc/xrdp/startwm.sh > /dev/null <<'EOF'
#!/bin/sh
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
if [ -z "$XDG_RUNTIME_DIR" ]; then
  XDG_RUNTIME_DIR=/run/user/$(id -u)
  export XDG_RUNTIME_DIR
  [ -d "$XDG_RUNTIME_DIR" ] || mkdir -p "$XDG_RUNTIME_DIR"
fi
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4 > /home/napnap/startxfce4.log 2>&1
EOF
sudo chmod +x /etc/xrdp/startwm.sh

为什么这样写能防秒断：

exec startxfce4 替代默认的 startwm 调用链，直接把 XFCE 顶上来，不让 xrdp 去碰 GNOME。
XDG_RUNTIME_DIR 不设置的话，XFCE 的很多组件（通知、电源、面板插件）找不到用户运行时目录，瞬间退出。
unset DBUS_SESSION_BUS_ADDRESS 之后，XFCE 会用第二步装的 dbus-x11 重新拉起一条干净的会话总线；前提是 dbus-x11 已装，否则又会 0 秒退。
把所有输出重定向到 /home/napnap/startxfce4.log 是排错神器：一旦桌面起不来，SSH 里 tail /home/napnap/startxfce4.log 看真实报错，比猜快十倍。

另一种写法是用 exec dbus-launch --exit-with-session startxfce4，显式由 dbus-launch 托管会话。本文的 unset + exec startxfce4 在装了 dbus-x11 时同样稳定，且日志更干净，故采用它。

改完重启 xrdp 让配置生效：

`1`	`sudo systemctl restart xrdp`

第五步：用客户端连上去

Windows：自带「远程桌面连接」（mstsc），计算机填 VPS_IP:3389，用户名 napnap，输密码。
首次连接如果秒断，等几秒重连一次——xrdp 重启后首连偶尔会瞬时抖动。
连上后如果桌面能停留，说明核心配置已通，下面都是体验优化。

第六步：性能优化——降分辨率、关合成特效

低配 VPS 上远程桌面最容易卡。两招见效最快：

1. 降分辨率。云桌面里同时跑 XFCE + 浏览器 + 应用，1080p 很吃带宽和内存。Windows 远程桌面客户端里「显示」选项把分辨率调到 1366×768 或 1280×720，颜色深度 16/24 位即可。也可以在 xrdp 登录界面前的高级选项里设。

2. 关掉窗口合成特效（Compositor）。XFCE 的窗口半透明、阴影、动画依赖合成器，在虚拟 X 会话里既卡又容易花屏。关掉：

图形操作：菜单 → 设置 → 窗口管理器微调（Window Manager Tweaks）→ 「合成器」标签页 → 取消勾选「启用显示合成」（Enable display compositing）。
命令行（需当前已登录桌面会话）：

`1`	`xfconf-query -c xfwm4 -p /general/use_compositing -s false`

注意：xfconf-query 依赖当前会话的 D-Bus，必须在一个已经起来的 XFCE 会话里跑；纯 SSH 下会报 D-Bus 错误，那是正常的，去桌面里点界面关即可。

第七步：浏览器——用 Chrome deb 替代 snap 版 Firefox

Ubuntu 24.04 的 apt install firefox 实际装的是 snap 版，而 xrdp 会话不在 snap 的 cgroup 里，启动会直接报错：

`1`	`session-*.scope is not a snap cgroup`

所以别用 snap 版 Firefox。先卸干净，再装 Chrome 的 deb 包：

# 卸掉 snap firefox（如果装过）
sudo snap remove --purge firefox 2>/dev/null
sudo apt remove --purge -y firefox 2>/dev/null

# 装 Chrome 稳定版 deb
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

装完在 XFCE 菜单 → 互联网里就能打开 Chrome。deb 版不受 snap cgroup 限制，远程桌面里正常起。

第八步：在云桌面里装 WorkBuddy

WorkBuddy 是 Electron 应用。官网下载页没给 Ubuntu/Fedora 的入口（只写了「到系统应用商店下载」），但官方其实构建了 deb/rpm，就挂在自家 CDN 上，通过更新接口就能拿到最新下载地址。先确认架构：

`1`	`uname -m # x86_64 → 用 x64；aarch64 → 用 arm64`

Ubuntu / Debian 系（deb）：

# 从官方更新接口取最新 deb 下载地址（需要 jq；没有就浏览器打开该 URL 复制 url 字段）
url=$(curl -s "https://copilot.tencent.com/v2/update?platform=workbuddy-linux-x64-deb" | jq -r '.url')
curl -L -O "$url"
sha256sum WorkBuddy-linux-x64-deb-*.deb   # 见下方「哈希对不上的提醒」
sudo apt install ./WorkBuddy-linux-x64-deb-*.deb

apt install 会自动解析标准库依赖（libgtk-3-0、libnss3、libsecret-1-0 等），装到 /opt/WorkBuddy，二进制在 /opt/WorkBuddy/workbuddy，并自动注册 /usr/bin/workbuddy、把 chrome-sandbox 设为 4755（setuid）。装完从菜单或终端敲 workbuddy 即可启动。

Fedora / RHEL 系（rpm）：换 rpm 通道，其余同理：

1
2
3

url=$(curl -s "https://copilot.tencent.com/v2/update?platform=workbuddy-linux-x64-rpm" | jq -r '.url')
curl -L -O "$url"
sudo dnf install ./WorkBuddy-linux-x64-rpm-*.rpm

ARM 机器把 platform 里的 x64 换成 arm64 即可（通道：workbuddy-linux-arm64-deb / workbuddy-linux-arm64-rpm）。

关于「第三方镜像失效」：之前 mirror.workbuddy.cn 这类博客里的地址是假的。正道是用上面的官方更新接口动态取地址，不要硬编码 URL（链接里的构建号每次发版都变）。

哈希对不上的提醒：接口 JSON 里的 sha256hash 字段实测和下载文件对不上（疑似算的不是这个文件），下载后自己 sha256sum 留档即可，别拿接口的值当校验标准。另外应用内更新在 Linux 上是死循环（提示去官网下、官网又没 Linux 入口），所以升级就重跑一遍上面的接口取新包。

启动与「闪退」处理。在虚拟 X 会话里，Electron/Chromium 常栽在两处：

chrome-sandbox 权限不对 → FATAL sandbox 错误。修复：

1
2

sudo chown root:root /opt/WorkBuddy/chrome-sandbox
sudo chmod 4755 /opt/WorkBuddy/chrome-sandbox   # 即 -rwsr-xr-x

官方 deb 的 postinst 安装时会把 chrome-sandbox 设成 4755，干净安装一般能直接启动；若某次安装/升级后权限不对、或你是手动解包的方式装的，闪退复发时按上面重设一次即可。

没有 GPU / /dev/shm 太小 → 渲染进程崩。启动参数加上：

`1`	`/opt/WorkBuddy/workbuddy --no-sandbox --disable-gpu --disable-dev-shm-usage`

为了方便，做一个包装脚本放进 PATH，以后终端敲 workbuddy 就带参数：

sudo tee /usr/local/bin/workbuddy > /dev/null <<'EOF'
#!/bin/sh
exec /opt/WorkBuddy/workbuddy --no-sandbox --disable-gpu --disable-dev-shm-usage "$@"
EOF
sudo chmod +x /usr/local/bin/workbuddy

桌面菜单的 .desktop 里 Exec= 也要指向带参数的命令，否则双击图标仍可能闪退。

第九步：中文输入法 fcitx5

XFCE 默认没有中文输入。装 fcitx5：

# 先确认没装旧的 / 冲突的，避免环境变量打架
# （如已装 ibus，可保留，但本文统一用 fcitx5）

sudo apt install -y fcitx5 fcitx5-chinese-addons fcitx5-frontend-all im-config
im-config -n fcitx5

关键坑：xrdp 的 startwm.sh 不会读 ~/.profile，所以平时写在 ~/.profile / ~/.xinitrc 里的输入法环境变量在远程桌面里根本不生效。必须把这几行写进 /etc/xrdp/startwm.sh，放在 exec startxfce4 之前（见第四步）：

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export SDL_IM_MODULE=fcitx

改完 startwm.sh 再 sudo systemctl restart xrdp，重连后：

桌面右上角托盘出现 fcitx 图标；
右键图标 → 配置（Configure）→ 加「拼音」或「双拼」输入法；
Ctrl + 空格 切换中英文。托盘里也能手动点选输入法。

WorkBuddy 能帮忙修：如果在云桌面里怎么都切不出中文，WorkBuddy 会弹提示「可以让 WorkBuddy 修复输入法问题」，直接让它跑一遍修复即可，省得自己逐个排查环境变量。本质就是确保 fcitx5 的 GTK_IM_MODULE / QT_IM_MODULE / XMODIFIERS 在远程会话里真正生效——所以前面才强调要把这几行写进 startwm.sh，而不是只留在 ~/.profile。

第十步：会话管理与排错——避免「logout 后登不上」

xrdp 默认「断线不杀会话」。如果反复重启 xrdp，旧 xrdp-sesman 进程不一定被杀干净，会留下多个 sesman 实例和孤儿 Xorg 会话（:10、:11 之类），多个 sesman 抢同一个会话 socket，结果就是 logout 后再也登不上、卡在登录界面。

在 /etc/xrdp/sesman.ini 打开「断开即杀」，让每次登录都是干净新会话：

sudo sed -i -E 's/^(KillDisconnected=).*/\1true/; s/^(DisconnectedTimeLimit=).*/\10/' /etc/xrdp/sesman.ini
sudo grep -iE "KillDisconnected|DisconnectedTimeLimit" /etc/xrdp/sesman.ini
# 应输出 KillDisconnected=true 和 DisconnectedTimeLimit=0
sudo systemctl restart xrdp

万一已经出现「登不上」，SSH 里清一遍残留再重启：

sudo systemctl stop xrdp
sudo pkill -9 -f xrdp
sleep 1
sudo rm -f /var/run/xrdp/sesman.sock /tmp/.X11-unix/X10 /tmp/.X11-unix/X11
sudo systemctl start xrdp
# 验证：应只剩 1 个 xrdp + 1 个 xrdp-sesman，没有孤儿 Xorg :10/:11
ps aux | grep -E "xrdp|Xorg" | grep -v grep

常见问题排查

客户端一直「无法连接 / 连不上」

3389 没监听：sudo ss -tlnp | grep 3389；服务没起就 sudo systemctl restart xrdp。
防火墙/安全组没放行 3389 入站（最常见）。
VPS 是内网 IP，没绑公网弹性 IP 或没做端口映射。

连上后秒断（黑屏一下回登录界面）

看日志：sudo tail -n 30 /var/log/xrdp-sesman.log 若有 exited quickly (0 secs)，就是 startwm.sh 问题。
看 tail -n 50 /home/napnap/startxfce4.log 的真实报错。
确认 dbus-x11 已装、XDG_RUNTIME_DIR 那段已写进 startwm.sh。

桌面能进但很卡

降分辨率到 1280×720 / 1366×768。
关掉窗口合成特效（见第六步）。
内存紧张就加 swap 兜底：sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile && echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab。

中文输入法切不出来

确认 GTK_IM_MODULE/QT_IM_MODULE/XMODIFIERS 已写进 startwm.sh（不是 ~/.profile），并重连。
im-config -n fcitx5 后重启会话；托盘里确认输入法已添加。

浏览器起不来（snap cgroup 报错）

卸 snap 版 Firefox，改装 Chrome deb（见第七步）。

WorkBuddy 闪退

重设 chrome-sandbox 为 4755，或用 --no-sandbox --disable-gpu --disable-dev-shm-usage 启动（见第八步）。

整套下来，一台 2~4G 的 Ubuntu VPS 就能当一个长期稳定、带中文输入、能开浏览器和 WorkBuddy 的云桌面用。核心就三句话：强制 XFCE 别让 xrdp 碰 GNOME、startwm.sh 把 dbus 和 XDG_RUNTIME_DIR 补好防秒断、snap 类应用换成 deb 版。剩下的都是性能与体验的微调。

Ubuntu 下 Google Chrome 的安装、卸载与验证

Sun, 25 Oct 2026 00:00:00 +0000

Chrome 在 Ubuntu 上的官方包名叫 google-chrome-stable。它不在 Ubuntu 默认软件源里，所以得从 Google 自己的源或 deb 包安装。下面按「先装对 → 再验证 → 最后能干净卸载」的顺序写，照着做即可。

文中命令以 Ubuntu 20.04 / 22.04 / 24.04（amd64） 为准，需要 sudo 权限。其他 Debian 系发行版（如 Linux Mint、Pop!_OS）步骤基本一致。

一、安装前准备

确认系统是 64 位：

1
2

uname -m
# 输出 x86_64 即可，Chrome 仅提供 64 位 Linux 版

能访问外网（deb 与密钥都从 dl.google.com 下载）。国内网络若慢，可换镜像或挂代理，但不要从第三方站下载 deb，避免被植入篡改包。
更新一下本地包索引（可选，但能减少依赖冲突）：
1

sudo apt update

二、方法一：通过官方仓库安装（推荐）

仓库方式会把 Google 的签名密钥和源加入系统，之后 sudo apt upgrade 就能跟着一起升级 Chrome，省去手动重装。

# 1. 创建存放密钥的目录（/etc/apt/keyrings 是推荐位置）
sudo install -m 0755 -d /etc/apt/keyrings

# 2. 下载 Google 签名公钥并转成 gpg 二进制格式
sudo wget -q -O - https://dl.google.com/linux/linux_signing_key.pub \
  | sudo gpg --dearmor -o /etc/apt/keyrings/google-chrome.gpg
sudo chmod a+r /etc/apt/keyrings/google-chrome.gpg

# 3. 写入软件源（stable 通道）
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/google-chrome.gpg] \
  http://dl.google.com/linux/chrome/deb/ stable main" \
  | sudo tee /etc/apt/sources.list.d/google-chrome.list > /dev/null

# 4. 更新索引并安装
sudo apt update
sudo apt install -y google-chrome-stable

如果第 2 步 gpg --dearmor 提示找不到 gpg，先装一下：sudo apt install -y gnupg。

三、方法二：直接下载 deb 包安装

不想加源、只想一次性装好，用这个方法最快。缺点是不能随系统自动更新，升级得重新下载。

# 1. 下载最新稳定版 deb
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

# 2. 安装（apt 会自动处理依赖，包括拉取 libnss3 等）
sudo apt install -y ./google-chrome-stable_current_amd64.deb

# 3. 装完可删除下载的 deb
rm -f google-chrome-stable_current_amd64.deb

注意 ./ 不能省：直接 apt install 文件名.deb 会被当成「从源里找叫这个名字的包」而报错，加上 ./ 才表示「本地文件路径」。

四、验证安装是否正确

装完后别急着用，先确认装的是 Google 官方版本、路径也在预期位置。

# 1. 看版本号（能正常输出版本即安装成功）
google-chrome-stable --version
# 例：Google Chrome 130.0.6723.58

# 2. 看可执行文件装到哪了
which google-chrome-stable
# 正常返回：/usr/bin/google-chrome-stable

# 3. 校验签名来源（确认是 Google 的包，而非第三方）
apt-cache policy google-chrome-stable
# 输出里应有 *** 标记来自 dl.google.com/linux/chrome/deb 的行

有图形界面时，直接按 Super 键搜 “Chrome” 或在终端运行 google-chrome-stable & 即可启动。

无图形界面的服务器验证（headless）

服务器通常没桌面，无法开窗口，用无头模式跑一个最小验证：

1
2
3

# 连 GPU / 沙箱都不需要，能正常拉回页面 DOM 即代表可用
google-chrome-stable --headless --no-sandbox --disable-gpu \
  --dump-dom https://www.google.com | head -n 5

--no-sandbox 在 root 用户或受限容器里常是必需的；正常桌面用户不必加。如果报错 error while loading shared libraries，多半缺依赖，执行 sudo apt install -y libnss3 libatk-bridge2.0-0 libgtk-3-0 补齐即可。

五、卸载与彻底清理

1. 卸载主程序

# 仅移除程序，保留个人配置
sudo apt remove google-chrome-stable

# 连配置文件一起删（purge）
sudo apt purge google-chrome-stable

# 清理因依赖它而装、现已无用的包
sudo apt autoremove

2. 清理仓库方式留下的源与密钥

如果你用的是「方法一」，卸载后最好把源和密钥一并删掉，否则 apt update 仍会去连 Google 的源：

1
2
3

sudo rm -f /etc/apt/sources.list.d/google-chrome.list
sudo rm -f /etc/apt/keyrings/google-chrome.gpg
sudo apt update   # 确认不再报 Google 源相关错误

3. 删除用户个人数据（可选）

浏览器缓存、登录态等存在用户目录，上面步骤不会动它。需要彻底清空：

`1`	`rm -rf ~/.config/google-chrome`

六、常见问题

Q：安装时提示 N: Download is performed unsandboxed as root？ 只是 apt 的提示信息，不是错误，deb 已正常装好，可忽略。

Q：启动时报 Failed to move to new namespace？ 沙箱在容器 / 某些内核配置下会失败，加 --no-sandbox 启动，或在服务器场景直接用上面的 headless 命令。

Q：想装测试版 / 开发版？ 包名分别是 google-chrome-beta 和 google-chrome-unstable，用同样的方式把 google-chrome-stable 换成对应名字即可。

Q：怎么确认没装成第三方改包？ 用 apt-cache policy google-chrome-stable 看版本来源是否来自 dl.google.com/linux/chrome/deb，再核对 apt-key list 或 /etc/apt/keyrings/google-chrome.gpg 的指纹是否与 Google 官方公布一致。

按上面的顺序，安装、验证、卸载都能干净走通。日常使用推荐「方法一」的仓库方式，升级省心；一次性临时用选「方法二」更快。

Cloudflare R2 实战指南：建桶、上传、缓存与防盗链

Wed, 21 Oct 2026 00:00:00 +0000

R2 是 Cloudflare 的对象存储，兼容 S3 接口，最大的卖点是没有出网流量费。很多人第一次用它，是因为把图片、视频放在别处被流量费咬了一口，换过来之后发现账单只剩存储和请求两项。

这篇文章按实际操作顺序写：建桶、传文件、绑域名、配缓存、加防盗链，最后是日常运维和排错。文中价格与免费额度以 Cloudflare 官方文档为准，具体以控制台显示为实。

先搞清楚 R2 的计费模型

R2 只收三样东西的钱：存储量、Class A 操作、Class B 操作。出网流量（Egress）对所有存储类型都是零费用，这是它和 S3 最本质的区别。

项目	Standard	Infrequent Access
存储	$0.015 / GB-月	$0.01 / GB-月
Class A 操作	$4.50 / 百万次	$9.00 / 百万次
Class B 操作	$0.36 / 百万次	$0.90 / 百万次
数据取回费	无	$0.01 / GB
最短存储期	无	30 天
出网流量	免费	免费

免费额度只对 Standard 生效，每月 10 GB 存储、100 万次 Class A、1000 万次 Class B。个人博客、小站点的图片和附件基本用不到付费区间。

理解 Class A 和 Class B 的区别，是省钱的关键：

Class A（贵，写类）：PutObject、CopyObject、ListObjects、CreateMultipartUpload、UploadPart 等，凡是"改动状态"的算这里。
Class B（便宜，读类）：GetObject、HeadObject 等读取操作。
免费：DeleteObject、DeleteBucket、AbortMultipartUpload。

有一个容易被忽略的细节：计费单位向上取整。做了 100 万零 1 次 Class A，按 200 万次计费；存了 1.1 GB-月，按 2 GB-月计费。所以别写出"每秒 List 一次目录"这种代码，List 属于 Class A，会把免费额度吃得很快。

建桶与控制台操作

建桶时注意两点：桶名全局唯一、创建后不能改名；存储位置（Location）选自动或就近区域即可，R2 会自动做全球分布，位置主要影响写入延迟和数据驻留合规。

建好之后，桶的 Settings 页面有几个开关值得先说清楚：

Public access → R2.dev subdomain：打开后会给你一个 pub-xxxxxxxx.r2.dev 的地址，能直接公网访问。这个域名只适合测试，Cloudflare 明确说明它有速率限制、不保证性能，不要拿它上生产。
Public access → Custom Domains：绑定自己的域名，这才是生产用法，下一节细说。
CORS Policy：前端直传或跨域读取时需要配，否则浏览器会拦。

用 API Token 和命令行传文件

控制台能拖拽上传，但批量操作还是要靠命令行。先在 R2 页面右侧的 “Manage R2 API Tokens” 创建一个 Token，权限选 Object Read & Write，可以限定到某个桶。记下三样东西：Access Key ID、Secret Access Key、以及账户的 S3 端点：

`1`	`https://<ACCOUNT_ID>.r2.cloudflarestorage.com`

方式一：rclone（适合同步目录、断点续传）

[r2]
type = s3
provider = Cloudflare
access_key_id = <ACCESS_KEY_ID>
secret_access_key = <SECRET_ACCESS_KEY>
endpoint = https://<ACCOUNT_ID>.r2.cloudflarestorage.com
acl = private

# 上传整个目录，并带上缓存头
rclone copy ./images r2:my-bucket/images \
  --header-upload "Cache-Control: public, max-age=31536000, immutable" \
  --progress

方式二：AWS CLI（R2 兼容 S3，换个 endpoint 就能用）

aws configure set aws_access_key_id <ACCESS_KEY_ID>
aws configure set aws_secret_access_key <SECRET_ACCESS_KEY>
aws configure set region auto

aws --endpoint-url https://<ACCOUNT_ID>.r2.cloudflarestorage.com \
  s3 cp ./dist s3://my-bucket/assets --recursive \
  --cache-control "public, max-age=31536000, immutable"

上传时顺手把 Cache-Control 写进对象元数据，是后面缓存能生效的前提。带内容哈希的静态资源（app.a1b2c3.js 这种）可以放心用一年；会变的文件用 max-age=86400 更稳。

绑定自定义域名，缓存才有可能生效

这一步是整个教程的分水岭。用 r2.dev 域名访问，请求根本不经过 Cloudflare 的 CDN 缓存，也就谈不上缓存命中、WAF 和速率限制；只有绑定自定义域名并开启橙色云代理，这些能力才会挂上去。

操作路径：桶 → Settings → Public access → Custom Domains → Connect Domain，填一个子域名，例如 cdn.example.com。前提是这个域名已经托管在同一个 Cloudflare 账户下，系统会自动写入一条 CNAME 记录，代理状态必须是橙色云（Proxied），灰色云等于直连，缓存和防护全部失效。

绑定完成后验证两件事：访问 https://cdn.example.com/你的文件名 能拿到内容；响应头里出现 cf-cache-status，初始一般为 MISS 或 DYNAMIC，配好缓存规则后应该变成 HIT。

缓存：两层配置，缺一不可

R2 前面这层缓存由 Cloudflare 负责，效果取决于两处配置：对象自带的 Cache-Control 头，和域名上的 Cache Rules。前者是"源站怎么说"，后者是"CDN 怎么执行"。

第一层：对象元数据。 上传时设置 Cache-Control: public, max-age=31536000, immutable，告诉 CDN 和浏览器这个文件可以长期缓存。已经上传的文件可以改元数据，或干脆重传。

第二层：Cache Rules。 路径是域名 → Caching → Cache Rules → Create rule。一条够用的规则长这样：

规则名：r2-cdn-cache
匹配条件：Hostname equals cdn.example.com
缓存资格：Eligible for cache
Edge TTL：Ignore cache-control header and use this TTL → 30 天（或 7 天）
Browser TTL：Respect origin（沿用源站）

为什么不直接沿用源站的 Cache-Control？因为 Cloudflare 的默认行为只缓存常见静态扩展名，HTML 之类默认不缓存。用 Cache Rules 显式声明 TTL，能让"边缘缓存多久"脱离源站头的限制，特别是当对象上传时压根没设头的情况下。

不同内容的 TTL 可以参考这个思路：

内容	Edge TTL	说明
图片、字体	30 天	基本不改，缓存收益最高
带哈希的 JS/CSS	1 年	文件名变即内容变，可 immutable
视频、压缩包	30 天	体积大，命中一次省一次 Class B
PDF、文档	7 天	偶尔更新，留一点回旋余地
JSON、接口响应	不缓存	动态内容，缓存会读到脏数据

缓存配好之后，收益是双重叠加的：命中边缘缓存的请求不会打到 R2，既不消耗 Class B 操作，也不产生任何存储读取。一个日访问几万次的图片站，缓存命中率从 40% 提到 95%，账单差距可能是一个数量级。

改完规则记得刷缓存：Caching → Purge Cache，可以按 URL 刷，也可以整站刷。否则旧的边缘副本会一直按老 TTL 活着。

防盗链：先认清它能防到什么程度

防盗链的本质是"判断请求是不是从我的页面发起的"。绕不过去的前提是：Referer 可以由客户端随意伪造，所以它只能挡住直接引用你链接的一般站点，挡不住有心人。真正要保护付费资源，得用签名 URL 或鉴权代理。

方案一：WAF 自定义规则校验 Referer（最常用）

路径：域名 → Security → WAF → Custom rules → Create rule。

`1`	`(http.host eq "cdn.example.com" and http.referer ne "" and not http.referer contains "example.com")`

动作选 Block。这条规则的意思是：访问 CDN 域名、带了 Referer、但 Referer 不是自己站点的，一律拦截。

http.referer ne "" 这个条件很重要——浏览器直接打开图片、或者从微信/QQ 里点开时，Referer 往往是空的。加了这一句表示"放行空 Referer"，体验更好；如果资源敏感，就去掉它，让空 Referer 也被挡。

方案二：签名 URL（适合私有资源）

公开资源用 Referer 够了，付费下载、限时链接这种就要签名。R2 支持 S3 预签名，生成的是带时效的临时地址：

1
2

aws --endpoint-url https://<ACCOUNT_ID>.r2.cloudflarestorage.com \
  s3 presign s3://my-bucket/private/report.pdf --expires-in 3600

链接一小时后失效，转发出去也没用。缺点是每个文件都要单独生成，适合后端按需签发，不适合海量静态资源。

方案三：Worker 做鉴权代理

把域名指向 Worker，在 Worker 里校验 token、Cookie、UA 或调用频率，通过后再用 env.MY_BUCKET.get(key) 从 R2 取对象返回。灵活度最高，可以加黑白名单、限速、按用户计次，代价是要写代码，且 Worker 请求本身有免费额度限制。

方案四：速率限制兜底

防盗链防的是"别人引用"，防不住"有人拿脚本刷你的公开链接"。域名 → Security → WAF → Rate limiting rules，对同一 IP 设阈值，比如 10 秒内超过 100 次请求就 Block 或 Managed Challenge。免费计划也提供少量规则额度，配一条针对大文件路径的规则很划算。

组合起来用：WAF 挡盗链、Rate Limiting 挡刷量、签名 URL 保敏感资源，三层各管一段。

日常运维：迁移、清理与成本

从 S3 搬数据有两种官方工具：Super Slurper 适合一次性批量迁移，会自动分片、重试；Sippy 适合渐进式迁移，请求命中 R2 就直接返回，没有就从源桶拉过来并回填，业务可以先切流量再慢慢搬。两者工具本身免费，只算 R2 的 Class A 操作费。

对象生命周期：桶的 Settings 里可以配生命周期规则，比如把 90 天未访问的对象转到 Infrequent Access，或直接删除临时文件。注意 IA 有 30 天最短存储期，删早了照样按 30 天收钱，别拿它存短期文件。

成本自查清单：

缓存命中率是否够高（cf-cache-status: HIT 的占比）
有没有代码在频繁 ListObjects（这是 Class A，很贵）
大文件是否走了分片上传并正常完成（残留的分片会占存储）
免费额度是否已经贴近上限（10 GB / 100 万 Class A / 1000 万 Class B）

常见问题排查

访问返回 403：先看对象是不是私有、域名有没有绑对；如果是刚配的 WAF 规则，去 Security Events 里看是不是被自己拦了。

cf-cache-status 一直是 DYNAMIC：说明请求没被当作可缓存内容。检查域名是否橙色云、Cache Rule 是否真的命中、文件扩展名是否在缓存范围内。

改了文件但访问还是旧内容：边缘缓存没过期。要么 Purge 缓存，要么用带哈希的文件名做版本控制，后者才是长久做法。

前端直传报 CORS 错误：桶的 Settings 里配 CORS Policy，把允许的 Origin 写清楚，AllowedMethods 至少包含 PUT，需要读取再加 GET。

上传大文件失败：超过 5 GB 的对象必须走分片上传（Multipart Upload），普通 PutObject 单次上限是 5 GB，用 rclone 或 SDK 会自动处理。

怀疑被刷：看 R2 的请求量图表和域名的流量分析，对照 Class A/B 操作数。异常增长通常来自某个公开链接被批量请求，先上 Rate Limiting，再考虑给该路径加签名。