运维与服务器 on 扎塔-Zata

S3 兼容存储踩坑记：boto3 新默认校验和撞上 NotImplemented

Thu, 10 Sep 2026 23:58:52 +0800

一场"全线 500"的发布事故

用自家 CLI 发布一篇博客，服务端返回 500。第一反应：肯定是包格式不对——毕竟几分钟前刚被 422 拒过一次（一个 2.9MB 的自包含 HTML 超了单条目 2MiB 上限），说明接口是通的，可能是我 ZIP 打包的方式不合规范。

于是按标准流程排查：换 Markdown 源文件 + 图片资源重新打包、用最小草稿（三行文字的 md）测基本链路、HTML 单文件再试一遍……结果所有创建请求一律 500，draft 和 publish 两个端点无一幸免。

但诡异的是：登录正常，草稿列表正常，健康检查正常，公开博客列表也能刷出来。所有读路径全绿，所有写路径全红。

如果真是包格式问题，最小草稿不可能挂；如果是认证问题，读接口不可能全通。这不像"我的请求有问题"，更像"服务端某个环节坏了"。

422 和 500 之间隔着一道分界线

回头看现象，有一条隐藏的分界线：

超限的 index.html 报 422（校验错误，Zip entry exceeds the 2 MiB limit）
所有通过校验的请求报 500

后端是分层架构：API 层收包 → core 层的 BlogService.extract_zip_package 做校验（格式、大小、路径白名单、symlink）→ 校验通过后 upload_blog 把正文和附件逐个写入对象存储。

422 在校验层抛出，说明请求已经正常穿过 API 层；500 卡在校验通过后的第一步——put_object。把服务端日志拉出来，最底下赫然一行：

botocore.exceptions.ClientError: An error occurred (NotImplemented) when
calling the PutObject operation: Aws MultiChunkedEncoding
STREAMING-UNSIGNED-PAYLOAD-TRAILER is not supported.

问题根本不在博客业务，也不在包格式——是对象存储的写入挂了。博客发布只是撞在枪口上的第一个受害者：任何要往 S3 写东西的功能（博客、语音、知识库）此时全部阵亡。

先补一点背景：S3 兼容生态与请求编码

S3 API 是事实标准，但"兼容"是程度问题

AWS S3 的 REST API 已经是对象存储的事实标准，MinIO、Cloudflare R2、Backblaze B2、各家云厂商的兼容端点都实现了这套协议。自建 MinIO 时，客户端通过几个参数接入：

boto3.client(
 "s3",
 endpoint_url="http://your-minio:9000", # 指向自建端点，而非 aws
 region_name="us-east-1", # MinIO 通常随便填一个
 aws_access_key_id=...,
 aws_secret_access_key=...,
 config=boto3.session.Config(
 s3={"addressing_style": "path"}, # 关键：path-style
 ),
)

其中 addressing_style 决定 bucket 怎么进 URL：path 风格是 http://endpoint/bucket/key，virtual_hosted 风格是 http://bucket.endpoint/key。自建 MinIO 没法给每个 bucket 配域名泛解析，所以必须用 path-style——这是自建存储的第一个常识坑。

但"实现了 S3 API"不等于"实现了 AWS 最新加的每一个字段"。S3 协议在演进，兼容实现永远在追赶，追赶不上的时候，就会返回一个很直白的错误码：NotImplemented。

签名 V4 之下，请求体有三种"泳姿"

AWS 签名协议 V4 在传输 payload 时有这么几种形态：

形态	特点
signed payload	请求体整体参与签名计算，头里放完整哈希
`UNSIGNED-PAYLOAD`	请求体不参与签名，靠 TLS 保证完整性
`STREAMING-*`	请求体按 `aws-chunked` 分块流式传输，边传边签

而这次出事的 STREAMING-UNSIGNED-PAYLOAD-TRAILER 是最新的变体：分块流式 + 不签名 + trailer——即在所有数据块传完之后，再追加一个尾部块，携带整个请求体的 CRC32 校验和。这套机制是 AWS 2024 年底力推的"默认数据完整性"改造的一部分。

根因：boto3 1.36 改了一个默认值

2025 年 1 月，boto3 1.36.0 发布，官方 changelog 里有一条不起眼的变更：

Default value of request_checksum_calculation is changed from when_required to when_supported.

翻译成人话：

以前（when_required）：只有 API 明确要求校验和时才算。PutObject 不要求，所以请求体就是普通字节流，任何 S3 兼容实现都吃得下。
现在（when_supported）：只要 API 支持校验和（PutObject 正好支持），就默认给请求体算 CRC32，并用上面那套 STREAMING-UNSIGNED-PAYLOAD-TRAILER 编码传输。

于是新版 boto3 对旧 MinIO（以及一批没跟进的兼容端点）发出的每个 PutObject 都长成了它们看不懂的样子，对端的回应整齐划一：NotImplemented。

为什么是"部署之后"才炸？仓库里 pyproject.toml 写的是 boto3>=1.43.28，依赖锁在 1.43.28。上一版镜像构建时拉的依赖、和这次重新构建拉的依赖，中间隔着这次默认值变更——代码一行没改，重新构建镜像本身就成了变更。这也是"锁文件 + 常态化重新部署"模式的一个隐性代价：依赖漂移会以最意想不到的方式找上门。

修复：一行 Config，三个层次

修复本身轻得可笑，在创建 boto3 客户端的 Config 里显式把行为钉回旧默认：

# 修复前：跟随 SDK 默认，1.36+ 对 PutObject 附带流式校验尾
config=boto3.session.Config(s3={"addressing_style": addressing_style})

# 修复后：仅在 API 要求时才计算校验和
config=boto3.session.Config(
 s3={"addressing_style": addressing_style},
 request_checksum_calculation="when_required",
)

除了改代码，还有两条等价路径，按生效成本排序：

环境变量（不重新构建镜像，改完配置重启即生效）：给后端进程加 AWS_REQUEST_CHECKSUM_CALCULATION=when_required，botocore 会读这个变量；
代码 Config（本文做法）：写死在适配器里，不依赖部署环境是否记得配这个变量；
升级存储端：新版本 MinIO 已支持流式校验尾，升级后可以吃回新默认。但注意必须升到 2026-04 之后的补丁版本——这条 trailer 路径先后曝出 CVE-2025-31489、CVE-2026-40344 等认证绕过漏洞（签名校验不完整，持有任意 secret 即可上传），修复分别落在 RELEASE.2025-04-03T14-56-28Z 和 RELEASE.2026-04-11T03-20-12Z。对安全敏感的自建场景，when_required 依旧是更稳的答案。但"为了让客户端新默认能跑而去升级存储"这个依赖方向，在自建场景里通常不如反过来稳。

选代码层还有一个架构上的理由：全仓库只有一个创建 boto3 客户端的地方——infrastructure 层的对象存储适配器，博客、语音、知识库全部经由它读写。修一处，全站愈合；这也意味着这类坑永远值得修在适配器里，而不是散落在各调用方。

同类清扫：适配器里还埋着一个 ASCII 坑

顺着这次排查把对象存储适配器翻了一遍，发现它早已修过另一个"协议约束"类的问题，记录于此，因为它们本质上是同一类坑：S3 的某些约束不在文档第一页，而在 HTTP 协议的物理规则里。

S3 的用户元数据（x-amz-meta-*）走的是 HTTP header，而 RFC 7230 规定 header 值必须是 ASCII。存中文描述时，botocore 的 validate_ascii_metadata 会在发请求之前就拒绝你：

put_object(key=..., data=..., metadata={"title": "融入"}) # ParamValidationError

适配器里的解法是"写入时编码 + 侧车标记还原"：非 ASCII 值先 percent-encode，同时多写一个 <key>-encoding: utf-8-pct 的侧车键；读取时发现有侧车标记就 unquote 还原。不依赖任何带外信息，元数据自描述。

def _sanitize_s3_metadata(metadata):
 for key, value in metadata.items():
 if value.isascii():
 sanitized[key] = value
 else:
 sanitized[key] = quote(value, safe="") # 值编码
 sanitized[f"{key}-encoding"] = "utf-8-pct" # 侧车标记

把它和这次的校验和坑放在一起看，S3 兼容存储的踩坑地图就清晰了：一类的坑源于"协议在演进，兼容端在追赶"（NotImplemented）；另一类源于"协议在收紧，客户端在把关"（ASCII 校验）。前者修客户端编码方式，后者修数据编码方式，但都该修在同一个适配器里。

验证

修复的验证分三层，也正好对应问题的影响面：

单元测试：对象存储适配器的元数据编解码测试全过，确认 Config 变更不影响既有行为；
影响面：全仓库搜索 boto3.client 只有适配器一处调用点——博客、语音、知识库三条业务线同时被这一行修复覆盖；
真实入口：重新部署后，用 CLI 以原来的命令重新发布那篇文章，一次通过，公开页面正常渲染。

顺带一提，之前 422 拒掉的那个 2.9MB 自包含 HTML，最后也没有硬塞进去，而是改用设计内的路径：Markdown 正文 + 图片平铺进 assets/ 打包上传。事后看这次事故像是两件事，其实共享同一个教训——别和平台默认值较劲，走它给你留的路。

几点收获

“兼容 S3"是一个光谱，不是一个开关。协议基础操作（对象增删改查）早就稳定，差异都藏在演进中的新特性里。判断一个兼容端点的成色，看它对最新协议扩展的支持比看 README 有用。
SDK 的默认值也是 API。boto3 这次变更完全符合语义化版本（major 没动，默认值动了），但对你来说行为就是变了。升级依赖 = 引入一次隐形变更，重新部署和改代码应该获得同级别的敬畏。
读写分离是天然的故障定位器。“读全绿、写全红"直接把嫌疑范围从整个 API 收窄到存储写入路径。分层架构平时的意义在排障时兑现：日志栈从 API 层一路穿到 botocore，每层只做一件事，所以每一栈帧都在缩小包围圈。
报错信息里最值钱的词是 NotImplemented。它不是"你错了”，而是"我们（实现方）还没做这个”——看到它就该去查协议演进和版本差异，而不是盯着自己的请求参数找茬。

代理配置与环境变量实战

Sat, 06 Jun 2026 10:00:00 +0800

概述

代理配置分为两个层面：

系统代理：由操作系统或 GUI 客户端（如 Clash Verge）管理，主要影响浏览器和 GUI 应用。
环境变量代理：通过 http_proxy / https_proxy / ALL_PROXY 等环境变量设置，主要影响命令行工具。

两者互相独立。系统代理设置了，终端里的 curl/git/docker 不一定走代理；反之亦然。

一、macOS 系统代理（Clash Verge）

Clash Verge 开启「系统代理」后，会自动配置 macOS 的网络代理设置，浏览器等 GUI 应用会走代理。

1.1 查看当前系统代理

networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

1.2 绕过列表（Bypass）

在 Clash Verge 的「系统代理」设置中配置绕过地址，如：（一般默认就有了）

127.0.0.1, localhost, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

注意：系统代理的绕过列表主要影响浏览器和 GUI 应用，对命令行工具不生效。

二、Shell 环境变量配置

2.1 基础变量

在 ~/.zshrc（或 ~/.bashrc）中添加：

# 代理地址（根据你的客户端端口修改）
export http_proxy="http://127.0.0.1:7897"
export https_proxy="http://127.0.0.1:7897"
export ALL_PROXY="socks5://127.0.0.1:7897"

# 绕过本地和局域网
export NO_PROXY="127.0.0.1,localhost,::1,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12"

生效：

source ~/.zshrc

2.2 快速开关代理

可以添加别名方便切换：

# ~/.zshrc
alias proxy='export http_proxy=http://127.0.0.1:7897; export https_proxy=http://127.0.0.1:7897; export ALL_PROXY=socks5://127.0.0.1:7897'
alias unproxy='unset http_proxy; unset https_proxy; unset ALL_PROXY'

2.3 只对当前命令生效

http_proxy=http://127.0.0.1:7897 curl -I https://github.com

三、NO_PROXY 绕过详解

3.1 问题现象

Clash Verge 开启系统代理后，curl 访问 localhost 返回 404：

curl http://localhost:8000/api/xxx
# {"detail":"Not Found"}

curl -v 发现请求走了代理：

Uses proxy env variable http_proxy == 'http://127.0.0.1:7897'

3.2 原因

Clash Verge 的绕过列表不影响命令行工具。curl 读取 http_proxy 环境变量后，会尝试通过代理访问 localhost，而代理服务器不认识这个本地地址。

3.3 解决

补充 NO_PROXY 环境变量：

export NO_PROXY="127.0.0.1,localhost,::1,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12"

常见 NO_PROXY 值：

地址	说明
`127.0.0.1`	本地 IPv4
`localhost`	本地主机名
`::1`	本地 IPv6
`192.168.0.0/16`	私网 A 段
`10.0.0.0/8`	私网 B 段
`172.16.0.0/12`	私网 C 段

3.4 验证

curl -v http://localhost:8000/health
# 不再出现 "Uses proxy env variable"

四、Git 代理配置

Git 不读取 http_proxy 环境变量（某些版本会读，但不可靠），需要单独配置：

4.1 HTTP/HTTPS 代理

git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

4.2 SOCKS5 代理

git config --global http.proxy socks5://127.0.0.1:7897

4.3 取消代理

git config --global --unset http.proxy
git config --global --unset https.proxy

4.4 仅对特定域名配置

git config --global http.https://github.com.proxy http://127.0.0.1:7897

五、Docker 代理配置

Docker 的代理分两个层面：Daemon 代理（影响 docker pull 等命令）和客户端默认代理（影响 docker run / docker build 自动注入的环境变量）。

5.1 Docker 客户端默认代理

配置 ~/.docker/config.json，让 docker run 和 docker build 自动注入代理环境变量：

mkdir -p ~/.docker

~/.docker/config.json：

{
 "proxies": {
 "default": {
 "httpProxy": "http://127.0.0.1:7897",
 "httpsProxy": "http://127.0.0.1:7897",
 "noProxy": "127.0.0.1,localhost,::1"
 }
 }
}

注意：这个配置只影响容器内部和构建过程，不影响 docker pull 拉取镜像。

5.2 Docker Daemon 代理

docker pull 等命令由 Docker Daemon 执行，Daemon 作为系统服务运行，不读取 Shell 环境变量，需要单独配置。

注意：macOS 上的特殊行为

Docker Desktop for Mac 运行在一个轻量级 Linux VM 中，这个 VM 的网络流量经过 macOS 主机的网络栈。因此即使没有在 Docker 中手动配置代理，Clash Verge 等工具开启的 macOS 系统代理也会被 VM “捎带” 走。这会导致：

开启 Clash 系统代理时，docker pull 能正常拉取（走了代理）
关闭 Clash 系统代理后，docker pull 可能失败或极慢（因为原先走代理的流量现在直连不通了）

如果你需要 Docker 在无论系统代理开或关的情况下都能稳定工作，建议显式配置 Daemon 代理（见下方）。

Linux (systemd)：

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf << 'EOF'
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7897"
Environment="HTTPS_PROXY=http://127.0.0.1:7897"
Environment="NO_PROXY=localhost,127.0.0.1,::1"
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

macOS (Docker Desktop)：

Settings → Resources → Proxies → Manual proxy configuration

5.3 容器内代理

运行容器时传入：

docker run -e http_proxy=http://host.docker.internal:7897 \
 -e https_proxy=http://host.docker.internal:7897 \
 -e NO_PROXY="localhost,127.0.0.1" \
 ubuntu

注意：容器内访问宿主机代理，macOS 用 host.docker.internal，Linux 用宿主机的局域网 IP。

六、包管理器代理

6.1 pip

pip install package-name --proxy http://127.0.0.1:7897

# 或设置环境变量
export PIP_PROXY=http://127.0.0.1:7897

6.2 npm

npm config set proxy http://127.0.0.1:7897
npm config set https-proxy http://127.0.0.1:7897

# 取消
npm config delete proxy
npm config delete https-proxy

6.3 uv

# uv 读取标准环境变量
export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897

# 或使用 --native-tls（某些证书问题场景）
uv pip install package-name --native-tls

七、常用工具代理

工具	代理方式
`curl`	读取 `http_proxy` / `https_proxy` / `ALL_PROXY`
`wget`	读取 `http_proxy` / `https_proxy`，或用 `-e http_proxy=`
`ssh`	用 `-o ProxyCommand="nc -X 5 -x 127.0.0.1:7897 %h %p"`
`brew`	读取环境变量，或 `HOMEBREW_CURLRC=1` + `~/.curlrc`
`go get`	读取 `http_proxy` / `https_proxy`

7.1 curl 指定代理

curl -x http://127.0.0.1:7897 https://api.github.com

# 或 SOCKS5
curl -x socks5://127.0.0.1:7897 https://api.github.com

7.2 wget 指定代理

wget -e http_proxy=http://127.0.0.1:7897 https://example.com

八、一键验证

配置完成后，验证代理是否生效：

# 查看当前代理环境变量
echo "HTTP: $http_proxy"
echo "HTTPS: $https_proxy"
echo "ALL: $ALL_PROXY"
echo "NO: $NO_PROXY"

# 测试外网（应走代理）
curl -s -o /dev/null -w "%{http_code}" https://github.com

# 测试本地（应直连）
curl -v http://localhost:8000 2>&1 | grep -i "proxy"

# 查看出口 IP（对比开关代理）
curl -s https://httpbin.org/ip

九、常见问题

Q1: 终端已经设置了代理，但某些命令还是不生效？

某些工具（如 Git）不读环境变量，需要单独配置。详见上文各节。

Q2: Docker 容器内无法访问宿主机代理？

macOS: 用 host.docker.internal:7897
Linux: 用宿主机局域网 IP，如 192.168.1.x:7897
或配置 Docker 的 --network host（仅限 Linux）

Q3: NO_PROXY 设置后不生效？

注意大小写：

大多数工具读 NO_PROXY
部分老工具读 no_proxy 建议两个都设：

export NO_PROXY="..."
export no_proxy="$NO_PROXY"

服务器磁盘管理基础

Fri, 05 Jun 2026 10:00:00 +0800

服务器运维的第一步是搞清楚自己手上有几块盘、有多大、挂在哪。本文覆盖从磁盘查看、分区格式化到持久化挂载的完整流程。

查看磁盘概况

1. lsblk —— 最直观的树形视图

lsblk

输出示例：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 49G 0 part /
sdb 8:16 0 100G 0 disk
└─sdb1 8:17 0 100G 0 part /mnt
nvme0n1 259:0 0 200G 0 disk

解读：

sda、sdb、nvme0n1 是 3 块物理磁盘
sda 分了 2 个区，分别挂载到 /boot 和 /
sdb 分了 1 个区，挂载到 /mnt
nvme0n1 未分区、未挂载

常用参数：

# 只看物理盘，不显示分区
lsblk -d -o NAME,SIZE,TYPE,MODEL

# 显示文件系统类型和 UUID
lsblk -f

2. df -h —— 查看已挂载分区的使用情况

df -h

输出示例：

Filesystem Size Used Avail Use% Mounted on
/dev/sda2 49G 15G 32G 32% /
/dev/sda1 1.0G 200M 800M 20% /boot
/dev/sdb1 100G 10G 90G 10% /mnt

3. fdisk -l —— 查看所有磁盘详情（含未挂载）

sudo fdisk -l

需要 root 权限，能看到 sector 大小、磁盘标签类型等详细信息。

4. 查看磁盘类型（HDD / SSD / NVMe）

# 方法1：通过旋转状态判断（SSD 为 0）
cat /sys/block/sda/queue/rotational
# 0 = SSD/NVMe, 1 = 机械硬盘

# 方法2：直接查看硬件信息
lsblk -d -o NAME,ROTA,TYPE,MODEL

# 方法3：NVMe 专用信息
sudo nvme list

分区与格式化

对新磁盘进行分区

以 /dev/sdb 为例：

sudo fdisk /dev/sdb

交互命令：

n —— 新建分区
p —— 主分区
1 —— 分区号
回车两次 —— 使用默认起始和结束扇区（占用整块盘）
w —— 写入并退出

大于 2TB 的磁盘请使用 gdisk 或 parted，fdisk 不支持 GPT 大分区。

格式化分区

# ext4（Linux 最常用）
sudo mkfs.ext4 /dev/sdb1

# xfs（适合大文件、高并发）
sudo mkfs.xfs /dev/sdb1

挂载磁盘

临时挂载

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data

重启后失效。

持久化挂载（/etc/fstab）

先获取分区的 UUID：

lsblk -f /dev/sdb1
# 或
sudo blkid /dev/sdb1

编辑 fstab：

sudo nano /etc/fstab

添加一行（务必用 UUID，不要用设备名，防止重启后设备名变化导致挂错盘）：

UUID=xxxxx-xxxxx-xxxxx /mnt/data ext4 defaults,noatime 0 2

字段说明：

UUID=... —— 分区的唯一标识
/mnt/data —— 挂载点
ext4 —— 文件系统类型
defaults,noatime —— 挂载选项（noatime 减少不必要的写操作，延长 SSD 寿命）
0 —— dump 备份标记（一般填 0）
2 —— fsck 检查顺序（根目录填 1，其他填 2，不检查填 0）

验证配置是否正确：

sudo mount -a

无报错即表示配置正确。如果配错了，重启后可能进不了系统，所以 mount -a 验证这一步不能省。

场景：把 Docker 数据迁移到数据盘

这是最常见的需求之一。系统盘通常只有 50G，数据盘有几百 G。将 Docker 数据根目录改到 /mnt/docker_data：

sudo systemctl stop docker
sudo systemctl stop docker.socket

sudo mkdir -p /mnt/docker_data
sudo rsync -aP /var/lib/docker/ /mnt/docker_data/

sudo nano /etc/docker/daemon.json

写入：

{
 "data-root": "/mnt/docker_data"
}

sudo systemctl start docker

验证：

docker info | grep "Docker Root Dir"
# 应输出 /mnt/docker_data

更详细的方案（软链接、Compose 级挂载等）可参考 Docker 容器相关命令中的"数据卷自动挂载到 /mnt"一节。

常用命令速查表

需求	命令
查看物理磁盘列表	`lsblk -d`
查看分区 + 挂载点	`lsblk`
查看已挂载磁盘使用率	`df -h`
查看所有磁盘详情	`sudo fdisk -l`
查看分区 UUID	`lsblk -f` 或 `sudo blkid`
判断 SSD/HDD	`cat /sys/block/sdX/queue/rotational`
新建分区	`sudo fdisk /dev/sdX`
格式化 ext4	`sudo mkfs.ext4 /dev/sdX1`
临时挂载	`sudo mount /dev/sdX1 /mnt/xxx`
验证 fstab	`sudo mount -a`
查看目录占用空间	`du -sh /path`

注意事项

操作前确认设备名：sda、sdb 在不同机器、甚至同一机器重启后可能变化，写脚本或 fstab 时尽量用 UUID。
不要直接格式化已挂载的分区：先 umount，或者在救援模式下操作。
云服务器的数据盘：首次使用需要先在控制台"挂载"到实例，然后在系统内分区格式化。阿里云、AWS、GCP 都是如此。
LVM 场景：某些云镜像默认使用 LVM，此时 lsblk 看到的结构会更复杂（vg-xxx、lv-xxx），扩容操作需要用 lvextend + resize2fs。

数据库备份实战

Thu, 28 May 2026 14:55:07 +0800

前言

数据是企业的核心资产，数据库备份是数据安全的最后一道防线。本文将系统介绍 PostgreSQL 和 MySQL 的备份方法、自动化策略以及恢复演练流程。

一、PostgreSQL 备份

1.1 pg_dump 基础用法

pg_dump 是 PostgreSQL 最常用的逻辑备份工具，支持单数据库导出。

# 基本备份命令
pg_dump -h localhost -U postgres -d mydb > backup.sql

# 压缩备份（推荐）
pg_dump -h localhost -U postgres -d mydb -Fc > backup.dump

# 仅备份结构（不含数据）
pg_dump -h localhost -U postgres -d mydb --schema-only > schema.sql

# 仅备份数据（不含结构）
pg_dump -h localhost -U postgres -d mydb --data-only > data.sql

# 备份指定表
pg_dump -h localhost -U postgres -d mydb -t users -t orders > tables.sql

参数说明：

参数	说明
`-h`	数据库主机地址
`-U`	连接用户名
`-d`	数据库名称
`-Fc`	自定义格式压缩（推荐，支持并行恢复）
`-t`	指定备份的表

1.2 pg_dumpall 全库备份

备份整个 PostgreSQL 实例（所有数据库 + 全局对象）：

# 备份所有数据库和全局对象（角色、表空间等）
pg_dumpall -h localhost -U postgres > all_databases.sql

# 仅备份全局对象（角色定义）
pg_dumpall -h localhost -U postgres --globals-only > globals.sql

1.3 恢复方法

# 恢复 SQL 格式备份
psql -h localhost -U postgres -d mydb < backup.sql

# 恢复自定义格式备份（支持并行）
pg_restore -h localhost -U postgres -d mydb -j 4 backup.dump

# 恢复前创建新数据库
createdb -h localhost -U postgres mydb_restore
pg_restore -h localhost -U postgres -d mydb_restore backup.dump

二、MySQL 备份

2.1 mysqldump 基础用法

# 基本备份命令
mysqldump -h localhost -u root -p mydb > backup.sql

# 备份所有数据库
mysqldump -h localhost -u root -p --all-databases > all_databases.sql

# 备份指定表
mysqldump -h localhost -u root -p mydb users orders > tables.sql

# 仅备份结构
mysqldump -h localhost -u root -p mydb --no-data > schema.sql

# 仅备份数据
mysqldump -h localhost -u root -p mydb --no-create-info > data.sql

推荐参数组合：

# 生产环境推荐参数
mysqldump -h localhost -u root -p \
 --single-transaction \  # InnoDB 一致性快照
 --routines \  # 包含存储过程和函数
 --triggers \  # 包含触发器
 --events \  # 包含事件
 --master-data=2 \  # 记录 binlog 位置（用于主从同步）
 mydb > backup.sql

2.2 恢复方法

# 恢复数据库
mysql -h localhost -u root -p mydb < backup.sql

# 恢复所有数据库
mysql -h localhost -u root -p < all_databases.sql

三、其他 PostgreSQL 图形化工具

除了 Navicat，还有多种优秀的 PostgreSQL 客户端工具支持备份和恢复功能。

3.1 pgAdmin

pgAdmin 是 PostgreSQL 官方推荐的免费图形化管理工具：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask pgadmin4

# 或从官网下载：https://www.pgadmin.org/download/

备份步骤：

连接数据库服务器，选择目标数据库
右键点击数据库 →「备份」
配置备份选项：
- 格式：Custom（推荐）、Directory、Plain SQL、Tar
- 编码：UTF8（推荐）
- 中定义：选择「仅结构」或「结构和数据」
选择备份文件保存位置，点击「备份」

恢复步骤：

右键点击目标数据库 →「恢复」
选择备份文件（.backup 或 .dump）
配置恢复选项：
- 架构：选择要恢复的 schema
- 数据：选择要恢复的表
点击「恢复」执行

优点：

免费开源，官方推荐
功能全面，支持服务器管理
跨平台（Windows/macOS/Linux）

缺点：

界面较复杂，新手上手较难
大数据库备份可能较慢

3.2 DBeaver

DBeaver 是一款功能强大的免费数据库管理工具，支持 PostgreSQL 及多种数据库：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask dbeaver-community

# 或从官网下载：https://dbeaver.io/download/

备份步骤：

右键点击数据库 →「工具」→「备份数据库」
选择备份对象（整个库或指定表）
配置备份选项：
- 格式：SQL、Dump、CSV 等
- 选项：包含索引、触发器、外键等
保存备份文件

恢复步骤：

右键点击目标数据库 →「工具」→「恢复数据库」
选择备份文件
配置恢复选项
执行恢复

优点：

完全免费开源
支持 80+ 种数据库
界面友好，功能丰富
支持数据导出/导入

缺点：

功能较多，界面稍显复杂

3.3 DataGrip

JetBrains DataGrip 是一款专业的数据库 IDE（付费）：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask datagrip

# 或从官网下载：https://www.jetbrains.com/datagrip/download/

备份方式：

右键数据库 →「Dump to File」导出
使用 Database Diff 进行数据库同步备份

特点：

强大的 SQL 编辑和调试功能
支持多数据库管理
与 JetBrains 全家桶集成良好

3.4 HeidiSQL

HeidiSQL 主要用于 MySQL/MariaDB，但也支持 PostgreSQL：

备份：

右键数据库 →「导出数据库为 SQL」
支持自定义导出选项

特点：

免费、轻量级
Windows 专用

3.5 phpPgAdmin

基于 Web 的 PostgreSQL 管理工具：

特点：

浏览器访问，无需安装客户端
适合服务器管理
功能相对基础

3.6 Adminer

轻量级单文件数据库管理工具：

特点：

仅一个 PHP 文件，非常轻量
支持 PostgreSQL、MySQL、MongoDB 等
可直接通过 Web 访问

3.7 工具对比

工具	类型	价格	跨平台	特点
Navicat	桌面应用	付费	Windows/macOS/Linux	功能全面，界面美观
pgAdmin	桌面应用	免费	全平台	官方推荐，功能强大
DBeaver	桌面应用	免费	全平台	开源社区活跃
DataGrip	IDE	付费	全平台	开发者友好
HeidiSQL	桌面应用	免费	Windows	轻量级
phpPgAdmin	Web 应用	免费	全平台	无需安装客户端
Adminer	Web 应用	免费	全平台	极轻量级

3.8 命令行工具补充

除了图形化工具，以下命令行工具也非常有用：

pg_dumpall（已介绍）：备份所有数据库

pg_dumpall -h localhost -U postgres > all.sql

psql（已介绍）：恢复 SQL 文件

psql -h localhost -U postgres -d mydb < backup.sql

pg_basebackup：物理备份（完整数据库复制）

# 创建物理备份
pg_basebackup -h localhost -U postgres -D /backup/base -Ft -z -P

# 恢复物理备份
pg_restore -d postgres /backup/base

Barman：企业级备份管理工具

# 配置备份服务器
barman check pg_server
barman backup pg_server
barman recover pg_server latest /var/lib/postgresql/data

四、Navicat 图形化备份

Navicat 是一款流行的数据库管理工具，支持 MySQL、PostgreSQL、SQL Server、Oracle 等多种数据库，提供直观的图形界面进行备份操作。

安装方法：

# 使用 Homebrew 安装 Navicat Premium（macOS）
brew install --cask navicat-premium

# 或安装 Navicat for PostgreSQL 专用版
brew install --cask navicat-for-postgresql

# 或从官网下载：https://www.navicat.com.cn/download/navicat-premium

4.1 PostgreSQL 备份

连接数据库：在左侧连接列表中选择 PostgreSQL 连接
开始备份：
- 右键点击目标数据库 → 选择「备份数据库」
- 或菜单栏选择「工具」→「备份数据库」
配置备份选项：
- 选择备份格式（建议选择「自定义」格式）
- 可选择要包含的对象（表、视图、函数等）
保存备份：点击「开始」后选择保存位置

4.2 MySQL 备份

连接数据库：在左侧连接列表中选择 MySQL 连接
数据同步（迁移备份）：
- 菜单栏选择「工具」→「数据同步」
- 源选择当前数据库
- 目标选择文件或另一个数据库
导出数据库：
- 右键数据库 →「转储 SQL 文件」→「结构和数据」或「仅结构」
- 自动生成 .sql 文件保存到本地

4.3 定时自动备份（Navicat Premium）

Navicat Premium 支持定时任务自动备份：

新建批处理作业：
- 菜单栏选择「工具」→「自动运行」或「计划」
- 点击「新建批处理作业」
添加备份任务：
- 从左侧拖拽「备份」任务到右侧流程区
- 选择连接和数据库
配置定时计划：
- 勾选「计划」选项卡
- 设置执行频率（每天、每周等）
- 设置执行时间
保存并启用：
- 保存批处理作业
- 勾选「启用」启动定时任务

4.4 Navicat Cloud 备份

Navicat Cloud 提供云端备份同步功能：

登录 Navicat Cloud：
- 菜单栏「文件」→「登录 Navicat Cloud」
- 输入账号密码
同步备份：
- 右键数据库 →「备份到 Navicat Cloud」
- 或通过「工具」→「同步」上传备份
恢复云端备份：
- 从 Navicat Cloud 下载备份文件
- 恢复到本地数据库

4.5 Navicat 恢复数据库

备份的最终目的是恢复，Navicat 提供了便捷的恢复功能：

PostgreSQL 恢复步骤：

右键点击目标数据库 → 选择「还原数据库」
选择备份文件（.backup 或 .dump 格式）
配置恢复选项：
- 仅还原结构：只恢复表结构，不恢复数据
- 仅还原数据：只恢复数据，表结构需已存在
- 结构和数据：完整恢复（推荐）
点击「开始」执行恢复

MySQL 恢复步骤：

运行 SQL 文件：
- 右键目标数据库 →「运行 SQL 文件」
- 选择之前导出的 .sql 备份文件
- 执行导入
数据同步恢复：
- 菜单栏「工具」→「数据同步」
- 源选择备份文件或备份库
- 目标选择要恢复的数据库
- 执行同步

恢复注意事项：

场景	注意事项
覆盖恢复	确保目标库已清空或删除，避免数据冲突
部分恢复	可选择仅恢复特定表，减少恢复时间
跨版本恢复	高版本备份可能无法恢复到低版本数据库
字符集问题	确保备份和恢复使用相同字符集，避免乱码

4.6 Navicat 备份注意事项

注意事项	说明
备份位置	建议保存到非系统盘，避免系统崩溃丢失
文件命名	包含日期时间，便于追溯（如 `mydb_20260528.sql`）
定期检查	定期验证备份文件能否正常恢复
大数据库	超大数据库建议使用命令行工具，性能更优
密码保护	敏感数据库建议设置备份文件密码

五、自动化备份脚本

5.1 PostgreSQL 自动备份脚本

#!/bin/bash
# pg_backup.sh - PostgreSQL 自动备份脚本

# 配置变量
PG_HOST="localhost"
PG_USER="postgres"
PG_PORT="5432"
BACKUP_DIR="/backup/postgresql"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)

# 创建备份目录
mkdir -p $BACKUP_DIR

# 获取所有数据库列表
DATABASES=$(psql -h $PG_HOST -U $PG_USER -p $PG_PORT -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;")

# 遍历备份每个数据库
for DB in $DATABASES; do
 DB=$(echo $DB | tr -d ' ')
 if [ -n "$DB" ]; then
 echo "正在备份数据库: $DB"
 pg_dump -h $PG_HOST -U $PG_USER -p $PG_PORT -d $DB -Fc > "$BACKUP_DIR/${DB}_${DATE}.dump"
 fi
done

# 清理过期备份
find $BACKUP_DIR -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "备份完成！"

5.2 MySQL 自动备份脚本

#!/bin/bash
# mysql_backup.sh - MySQL 自动备份脚本

# 配置变量
MYSQL_HOST="localhost"
MYSQL_USER="root"
MYSQL_PASS="your_password"
BACKUP_DIR="/backup/mysql"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)

# 创建备份目录
mkdir -p $BACKUP_DIR

# 获取所有数据库列表
DATABASES=$(mysql -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASS -e "SHOW DATABASES;" | grep -v Database | grep -v information_schema | grep -v performance_schema)

# 遍历备份每个数据库
for DB in $DATABASES; do
 echo "正在备份数据库: $DB"
 mysqldump -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASS \
 --single-transaction --routines --triggers --events \
 $DB | gzip > "$BACKUP_DIR/${DB}_${DATE}.sql.gz"
done

# 清理过期备份
find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

echo "备份完成！"

5.3 配置定时任务

# 编辑 crontab
crontab -e

# 每天凌晨 2 点执行备份
0 2 * * * /scripts/pg_backup.sh >> /var/log/pg_backup.log 2>&1
0 2 * * * /scripts/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

六、云存储备份

5.1 上传到 AWS S3

#!/bin/bash
# upload_to_s3.sh

BACKUP_DIR="/backup/postgresql"
S3_BUCKET="s3://your-bucket/database-backups"
DATE=$(date +%Y%m%d)

# 同步备份文件到 S3
aws s3 sync $BACKUP_DIR $S3_BUCKET/$DATE/ \
 --storage-class STANDARD_IA \
 --delete

# 设置生命周期规则自动清理旧备份（在 S3 控制台配置）

5.2 上传到 Cloudflare R2

# 使用 rclone 同步到 R2
rclone sync /backup/postgresql r2:your-bucket/database-backups/$(date +%Y%m%d)/

七、备份策略最佳实践

6.1 备份类型对比

类型	说明	优点	缺点
全量备份	备份所有数据	恢复简单快速	占用空间大，耗时长
增量备份	仅备份变化数据	占用空间小	恢复需要全量+所有增量
差异备份	备份自上次全量后的变化	恢复比增量快	比增量占用更多空间

6.2 推荐策略

生产环境推荐备份策略：

┌─────────────────────────────────────────────────────┐
│ 周日：全量备份 │
│ 周一~周六：增量备份 │
│ 保留周期：至少 4 周 │
│ 异地备份：同步到云存储（S3/R2/OSS） │
│ 恢复演练：每月至少 1 次 │
└─────────────────────────────────────────────────────┘

6.3 备份验证清单

备份文件是否完整生成
备份文件大小是否合理
备份是否按时执行（检查 cron 日志）
异地备份是否同步成功
定期进行恢复演练

八、数据恢复（命令行）

命令行恢复是生产环境中最重要的技能，本节详细介绍 PostgreSQL 和 MySQL 的恢复操作。

7.1 PostgreSQL 恢复详解

基础恢复命令：

# 恢复 SQL 格式备份（纯文本）
psql -h localhost -U postgres -d mydb < backup.sql

# 恢复自定义格式备份（.dump 文件）
pg_restore -h localhost -U postgres -d mydb backup.dump

# 并行恢复（加快大数据库恢复速度）
pg_restore -h localhost -U postgres -d mydb -j 4 backup.dump

创建新数据库恢复：

# 1. 创建新数据库
createdb -h localhost -U postgres mydb_new

# 2. 恢复数据到新数据库
pg_restore -h localhost -U postgres -d mydb_new backup.dump

恢复前清理目标库：

# 如果目标库存在且要完全覆盖，先删除
dropdb -h localhost -U postgres mydb

# 重新创建数据库
createdb -h localhost -U postgres mydb

# 恢复数据
pg_restore -h localhost -U postgres -d mydb backup.dump

选择性恢复（仅恢复指定表）：

# 列出备份中的所有对象
pg_restore -l backup.dump

# 仅恢复特定表
pg_restore -h localhost -U postgres -d mydb -t users backup.dump
pg_restore -h localhost -U postgres -d mydb -t orders backup.dump

# 仅恢复存储过程
pg_restore -h localhost -U postgres -d mydb -P -t function_name backup.dump

恢复前检查选项：

# 先检查备份文件内容（不执行恢复）
pg_restore --help # 查看所有选项

# 不带数据恢复（仅检查结构）
pg_restore -h localhost -U postgres -d mydb --schema-only backup.dump

# 恢复到另一个表空间
pg_restore -h localhost -U postgres -d mydb --tablespace=new_space backup.dump

7.2 MySQL 恢复详解

基础恢复命令：

# 恢复单个数据库
mysql -h localhost -u root -p mydb < backup.sql

# 恢复所有数据库（备份时包含 CREATE DATABASE 语句）
mysql -h localhost -u root -p < all_databases.sql

# 恢复压缩备份（gzip 格式）
gunzip < backup.sql.gz | mysql -h localhost -u root -p mydb

# 或使用 zcat
zcat backup.sql.gz | mysql -h localhost -u root -p mydb

指定字符集恢复：

# 如果有字符集问题，指定字符集
mysql -h localhost -u root -p --default-character-set=utf8mb4 mydb < backup.sql

# 或在 SQL 文件开头设置
mysql -h localhost -u root -p --init-command="SET NAMES utf8mb4" mydb < backup.sql

覆盖恢复（先清空后导入）：

# 1. 删除并重建数据库
mysql -h localhost -u root -p -e "DROP DATABASE IF EXISTS mydb; CREATE DATABASE mydb;"

# 2. 恢复数据
mysql -h localhost -u root -p mydb < backup.sql

选择性恢复（仅恢复指定表）：

# 方法1：使用 sed 提取指定表
sed -n '/DROP TABLE.*`表名`;/,/UNLOCK TABLES;/p' backup.sql > table.sql
mysql -h localhost -u root -p mydb < table.sql

# 方法2：使用 mysqlimport（需要先创建空表）
mysqlimport -h localhost -u root -p mydb table_data.txt

# 方法3：使用 mydumper 并行导出/导入指定表
mydumper -h localhost -u root -p -o /backup/tables -t users -t orders
myloader -h localhost -u root -p -d /backup/tables -o mydb

表结构与数据分离恢复：

# 仅恢复表结构
mysql -h localhost -u root -p mydb < schema.sql

# 仅恢复数据（表结构需已存在）
mysql -h localhost -u root -p mydb --init-command="SET foreign_key_checks=0; SET unique_checks=0; SET SESSION tx_isolation='READ-UNCOMMITTED';" < data.sql

7.3 恢复高级技巧

时间点恢复（PITR）：

PostgreSQL 支持基于时间点的恢复：

# 1. 停止 PostgreSQL
sudo systemctl stop postgresql

# 2. 备份当前数据目录
sudo cp -r /var/lib/postgresql/data /var/lib/postgresql/data.bak

# 3. 恢复到指定时间点
PGDATA=/var/lib/postgresql/data pg_restore -P --clean --create --dbname=postgres backup.dump

# 或编辑 postgresql.conf 设置恢复目标时间
# recovery_target_time = '2026-05-28 10:00:00'

MySQL binlog 恢复：

# 1. 确定恢复时间点
mysqlbinlog --start-datetime="2026-05-28 10:00:00" --stop-datetime="2026-05-28 12:00:00" mysql-bin.000001 > recovery.sql

# 2. 应用恢复
mysql -h localhost -u root -p mydb < recovery.sql

增量备份恢复：

# PostgreSQL WAL 归档恢复
# 1. 恢复基础全量备份
pg_restore -h localhost -U postgres -d postgres backup.dump

# 2. 应用 WAL 文件
psql -h localhost -U postgres -d mydb < 000000010000000000000001
psql -h localhost -U postgres -d mydb < 000000010000000000000002

跨服务器恢复：

# PostgreSQL：恢复远程数据库
pg_dump -h remote_host -U postgres -d mydb | pg_restore -h localhost -U postgres -d mydb

# MySQL：远程到本地
mysqldump -h remote_host -u root -p mydb | mysql -h localhost -u root -p mydb

7.4 恢复检查清单

执行恢复前务必检查以下项目：

检查项	操作
备份文件完整性	检查文件大小和校验和
磁盘空间	确认目标磁盘有足够空间
数据库版本	确保备份和目标版本兼容
字符集	确认字符集设置一致
连接权限	确认恢复账号有足够权限
依赖关系	检查存储过程、触发器依赖
外键约束	恢复时关闭外键检查可加速

九、恢复演练

恢复演练是备份策略中最容易被忽视但最重要的环节！

9.1 演练脚本

#!/bin/bash
# restore_drill.sh - 恢复演练脚本

BACKUP_FILE="/backup/postgresql/mydb_20260528_020000.dump"
TEST_DB="mydb_drill_test"
PG_HOST="localhost"
PG_USER="postgres"

echo "=== 数据库恢复演练开始 ==="
echo "时间: $(date)"

# 1. 创建测试数据库
echo "1. 创建测试数据库: $TEST_DB"
dropdb -h $PG_HOST -U $POSTGRES_USER $TEST_DB 2>/dev/null || true
createdb -h $PG_HOST -U $PG_USER $TEST_DB

# 2. 执行恢复
echo "2. 执行恢复..."
pg_restore -h $PG_HOST -U $PG_USER -d $TEST_DB $BACKUP_FILE

# 3. 验证数据
echo "3. 验证数据完整性..."
TABLE_COUNT=$(psql -h $PG_HOST -U $PG_USER -d $TEST_DB -t -c "SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';")
echo " 恢复表数量: $TABLE_COUNT"

# 4. 清理测试数据库
echo "4. 清理测试数据库..."
dropdb -h $PG_HOST -U $PG_USER $TEST_DB

echo "=== 恢复演练完成 ==="

9.2 演练报告模板

数据库恢复演练报告
==================
日期：2026-05-28
演练人员：张三

备份文件：mydb_20260528_020000.dump
备份大小：1.2 GB

演练结果：
- 恢复耗时：3分28秒
- 表数量：45
- 数据完整性：✓ 通过
- 应用连接测试：✓ 通过

结论：备份有效，恢复流程正常。

十、常见问题

Q1: 备份时数据库是否需要停服？

不需要。 PostgreSQL 的 pg_dump 和 MySQL 的 mysqldump --single-transaction 都支持在线热备份，不会阻塞业务。

Q2: 大数据库备份太慢怎么办？

PostgreSQL：使用 -j 参数并行备份/恢复
MySQL：考虑使用 mydumper 工具并行导出
超大数据库建议使用物理备份工具（pg_basebackup、XtraBackup）

Q3: 如何备份 Docker 中的数据库？

# PostgreSQL
docker exec postgres pg_dump -U postgres mydb > backup.sql

# MySQL
docker exec mysql mysqldump -u root -pPassword mydb > backup.sql

总结

备份是刚需：没有备份的数据库就是在裸奔
自动化是关键：手动备份一定会被遗忘
异地备份是保障：服务器挂了，备份还在
演练是验证：没测试过的备份等于没有备份
监控是补充：备份失败要及时告警

记住：数据无价，备份先行！

server_ops

Tue, 24 Mar 2026 15:25:22 +0800

注意事项

🩸 血泪教训：别再把数据库和业务代码塞进同一个 Docker 容器了！

前言：

刚接触 Docker 的时候，我曾陷入一个深深的误区——认为“容器化部署”就等于把前端、后端、MySQL、Redis 等所有东西全都写进一个 docker-compose.yml 里，然后在服务器上敲一行 docker-compose up -d，看着整个世界“一键启动”，简直爽翻了。

直到最近，我经历了一次惨痛的教训：业务代码引发的资源耗尽导致 MySQL 崩溃，随之而来的是极其痛苦的备份恢复，整个服务直接瘫痪。

这次事故让我彻底顿悟：在生产环境中，绝不能把基础设施（Infra）和实际业务代码混在一起部署。

1. 为什么“一键打包”只适合玩具项目？

把所有服务部署在同一台机器上，在本地开发或测试环境确实是银弹，但在生产环境却是一场定时炸弹。从“单机思维”走向“架构思维”，我们需要明白以下几个核心差异：

🆚 无状态（业务应用） vs 有状态（数据库）

你的后端 API 是“无状态”的，随时可以重启、销毁、水平扩展，崩了拉起一个新的立刻就能用。而数据库（MySQL/PostgreSQL）是“有状态”的，里面存着身家性命。把它们绑在一起，无异于让脆弱的消耗品和贵重的传家宝放在同一个易碎的盒子里。

💣 恐怖的“爆炸半径”（Blast Radius）

如果业务代码出现 Bug（比如内存泄漏），或者遭遇突发流量，服务器的 CPU 和内存会被瞬间吃光。这时 Linux 的 OOM Killer 就会无情启动，强制杀掉占用内存大的进程——通常数据库就是那个“冤大头”。业务代码的锅，导致数据库崩溃，进而导致全站瘫痪。

此外，业务日志和数据库争抢磁盘 IOPS，也会让数据库性能大打折扣。

💡 架构顿悟：让计算归计算，存储归存储。 将业务应用和数据库分别部署在不同的服务器上，进行物理隔离，是迈向高可用架构的第一步。

2. 妥协与选择：自建 Docker 版 PostgreSQL

明确了分离部署的原则后，我面临了一个新问题：我手头的云厂商 RDS 只有 MySQL，但我目前的业务非常想用 PostgreSQL。

云厂商的高级托管服务（如 AWS RDS 或 Serverless 方案如 Neon/Supabase）当然是首选，但如果受限于预算或现有资源，单独买一台服务器，用 Docker 跑 PostgreSQL 依然是一个极具性价比且成熟的方案。

很多人担心 Docker 部署数据库会有性能损耗。但在中小规模业务面前，那 2%~5% 的网络/IO损耗完全可以忽略不计。相反，只要坚持了**“物理分离”**的原则，Docker 带来的环境一致性和迁移便利性绝对物超所值。

3. 生产级 Docker PostgreSQL 部署指南

既然成为了自己的 DBA，就不能像本地开发那样随意。以下是我整理的部署在独立数据库服务器上的生产级 docker-compose.yml 模板：

version: '3.8'

services:
 postgres:
 image: postgres:16-alpine  # 推荐指定明确的版本号，Alpine体积更小
 container_name: postgres_prod
 restart: always  # 宿主机重启时自动拉起
 environment:
 POSTGRES_USER: myuser  # ⚠️ 不要用默认的 postgres 作为日常用户名
 POSTGRES_PASSWORD: MyStrongPassword_123! 
 POSTGRES_DB: mydb 
 TZ: Asia/Shanghai 
 ports:
 # ⚠️ 警告：千万不要写 "5432:5432" 直接暴露公网！
 - "5432:5432"
 volumes:
 # 核心！必须把数据挂载到宿主机，绝对不能留在容器内
 - /data/postgres_data/data:/var/lib/postgresql/data
 # 挂载一个备份目录，方便宿主机的定时任务导出数据
 - /data/postgres_data/backups:/backups
 command:
 # 【性能调优】Docker PG默认 shared_buffers 极小 (128MB)
 # 推荐把 shared_buffers 设置为这台独立服务器总物理内存的 25% (假设分配1GB)
 - "postgres"
 - "-c"
 - "shared_buffers=1GB"
 - "-c"
 - "max_connections=200"

4. 守住底线：数据库保命的“三道防线”

脱离了云数据库 RDS 的温室，自建 Docker 数据库必须自己做好以下三道保险，否则之前的悲剧迟早重演：

🛡️ 第一道防线：防勒索（网络隔离）

自建数据库最容易踩的坑就是被勒索软件删库要比特币。

绝对不要把 5432 端口暴露在公网上！

去云服务器控制台的安全组（防火墙）设置中，配置 5432 端口的入站规则：仅允许你业务服务器的内网 IP 访问。

🚀 第二道防线：突破默认限制（性能调优）

不要抱怨 Docker 跑 PG 慢，往往是因为没改配置。PG 默认的 shared_buffers 非常保守（128MB），会导致疯狂读写硬盘。如果你这台专用的 DB 服务器有 4G 内存，直接在 docker command 里设为 1GB（25% 原则），性能会有质的飞跃。

💾 第三道防线：自动化异地备份（保命符）

由于没了 RDS 的自动备份，我们必须手动写 Crontab 脚本每天导出，并且一定要传到异地（如对象存储 OSS/S3）。

一个简单的 Bash 备份脚本参考 (backup.sh)：

#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/data/postgres_data/backups"

# 1. 容器内执行 pg_dump 导出
docker exec postgres_prod pg_dump -U myuser -d mydb -F c -f /backups/mydb_$DATE.dump

# 2. 删除7天前的旧备份（防止撑爆硬盘）
find $BACKUP_DIR -name "*.dump" -type f -mtime +7 -exec rm -f {} \;

# 3. 【关键】上传到对象存储或另一台机器
# ossutil cp $BACKUP_DIR/mydb_$DATE.dump oss://my-backup-bucket/

通过 crontab -e 设定每天凌晨 3 点执行：0 3 * * * /bin/bash /data/postgres_data/backup.sh

写在最后

从“把所有东西塞进一个容器里一键启动”，到“将业务逻辑与基础设施拆分并做好隔离与备份”，这是每一个开发者向后端架构师蜕变的必经之路。

“性能损失”从来不是自建数据库的痛点，“运维疏忽”才是。只要严格遵守分离部署 + 挂载卷 + 限制公网访问 + 定时异地备份，你用 Docker 搭建的 PostgreSQL，足以平稳支撑你的业务走过漫长的初创和成长期。

5. 用户权限管理：创建只读用户

在实际生产环境中，我们经常需要给第三方工具或只读分析需求提供数据库访问，但绝不能直接暴露拥有写权限的超级用户。

以下是在 PostgreSQL 中创建一个只读用户的完整命令：

-- 1. 创建只读用户（替换密码为强密码）
CREATE USER readonly_vanta WITH PASSWORD 'Vanta123456!';

-- 2. 授予数据库连接权限
GRANT CONNECT ON DATABASE "Vanta" TO readonly_vanta;

-- 3. 授予 schema 的使用权限
GRANT USAGE ON SCHEMA public TO readonly_vanta;

-- 4. 授予现有所有表的查询权限
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_vanta;

-- 5. 【关键】设置默认权限，使该用户自动拥有未来新建表的查询权
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly_vanta;

💡 注意事项

创建用户后，务必在安全组中限制该用户的连接来源 IP，避免公网直接暴露。

如果数据库已有多个 schema，需要针对每个 schema 重复执行 GRANT USAGE 和 GRANT SELECT。

如需回收权限，可使用 REVOKE 命令或直接用 DROP USER readonly_vanta; 删除用户。

阿里云服务器

Sun, 22 Mar 2026 22:35:40 +0800

注意事项

我碰到过一次，下面新加的防火墙策略和上面的策略冲突，导致下面的失效，如果下面的策略没有问题，就不要加上面的策略

服务器爬墙

Fri, 20 Mar 2026 00:31:26 +0800

安装和配置

mihomo安装包

mmdb文件

mihomo - github地址

maxmind-geoip - github地址

首先下载deb包和mmdb（或者压缩包）
传输到远程服务器

scp <deb包名>.deb root@remote_server:/root/
scp <mmdb文件名>.mmdb root@remote_server:/root/

安装deb包

dpkg -i /root/<deb包名>.deb

4.下载 Country.mmdb

# 进入配置目录
cd /etc/mihomo
# 下载 Country.mmdb
curl -L -o Country.mmdb https://ghp.ci/https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb

#或者

# 复制 mmdb 文件
cp /root/<mmdb文件名>.mmdb Country.mmdb
# 复制 mmdb 文件
cp Country.mmdb /etc/mihomo/

修改配置文件

# 编辑配置文件
vim /etc/mihomo/config.conf


# 粘贴你的clash配置文件
【-------】


# 把这几行添加到配置文件的开头
geodata-loader: memconservative
geodata-mode: false # 某些版本可用
external-controller: 0.0.0.0:9090 # 外部控制端口，建议 0.0.0.0 方便远程访问
secret: "your_secret_password" # 控制面板密码 (强烈建议修改)
external-ui: ui # 控制面板文件目录 (可选)

重启服务

# 重启服务
systemctl restart mihomo

# 立即查看日志
journalctl -u mihomo -f

访问控制面板

# 访问控制面板
http://remote_server:9090/ui?secret=your_secret_password

配置环境变量

# 写入环境变量
echo "export http_proxy=http://127.0.0.1:7890" >> ~/.bashrc
echo "export https_proxy=http://127.0.0.1:7890" >> ~/.bashrc
# 使其立即生效
source ~/.bashrc

设置开机自启

# 设置开机自启
systemctl enable mihomo

域名迁移

Sat, 14 Mar 2026 02:44:12 +0800

域名迁移避坑指南：解决 DNS 缓存与数据一致性的终极方案

在服务器迁移、更换 IP 或域名解析切换的过程中，开发者最常遇到的噩梦莫过于：明明 DNS 解析已经生效，Ping 也是新 IP，但部分用户依然访问的是旧服务器，甚至导致数据写入错误或服务不可用。

很多开发者倾向于直接关停旧服务以“止损”，但这往往会导致用户端出现 502/504 错误或连接超时，严重影响用户体验。本文将深入剖析 DNS 缓存的机制，解释为何“刷新页面”无效，并提供三种不同级别的平滑迁移方案，帮助你实现用户无感知的无缝切换。

一、为什么解析生效了，流量还在旧 IP？

即使你在本地通过 ping 或 nslookup 确认解析已更新，部分用户（甚至你自己）仍可能访问旧 IP。这并非玄学，而是由 DNS 缓存的多级机制 和 网络连接特性 决定的。

1. DNS 缓存的多级“拦路虎” DNS 解析并非实时查询，而是层层缓存。当用户发起请求时，IP 地址的获取顺序如下：

浏览器缓存：Chrome、Safari 等浏览器自带 DNS 缓存（如 Chrome 的 chrome://net-internals/#dns）。
操作系统缓存：Windows/macOS/Linux 系统内核会缓存 DNS 记录。
本地网络设备：家庭或公司的路由器、光猫可能缓存了旧解析。
运营商（ISP）缓存：这是最不可控的一环。电信、联通等运营商为了节省带宽，往往无视你设置的 TTL（生存时间），强行缓存旧记录。部分地区可能需要几小时甚至 48 小时才能彻底刷新。

2. 长连接（Keep-Alive）未断开 如果客户端（App、浏览器页面、第三方 API）与旧服务器建立了 HTTP 长连接或 WebSocket，只要连接未断开，后续请求会直接在原有的 TCP 连接上发送，根本不会触发新的 DNS 查询。

二、为什么用户疯狂“刷新”也没用？

很多开发者误以为让用户“刷新页面”就能获取最新网络状态。实际上，浏览器的“刷新”刷新的是 HTTP 请求，而不是 DNS 解析。

真实情况：只要上述任何一个缓存环节（浏览器、系统、路由器、运营商）命中了旧 IP，用户无论按多少次 F5，流量依然会死死地打在旧服务器上。
何时生效：除非用户切换网络（如 WiFi 切 5G）、重启路由器、或手动清空 DNS 缓存（ipconfig /flushdns），否则只能被动等待缓存过期（TTL 到期）。

直接关停旧服务的后果： 如果旧服务器直接关机或杀进程，访问旧 IP 的用户将面临：

连接失败/超时：用户以为网站倒闭或服务器宕机。
502/504 错误：如果只关了应用没关网关。
数据焦虑：正在提交表单或付款的用户遇到报错，会疯狂重复提交，导致数据混乱或用户流失。

三、三大解决方案：如何完美处理旧服务？

核心诉求是：防止数据错误（写错库、数据不同步），同时保证用户体验。 根据业务容忍度，可选择以下三种方案。

方案 A：旧服务器做“反向代理”（⭐️ 最优解，强推）

这是大厂做无缝迁移的标准做法。不要停掉旧服务器的网络，而是让旧服务器充当“跳板”，将收到的流量透明地转发给新服务器。

原理：无论用户 DNS 刷新与否，最终处理请求和写入数据的都是新服务器。
优点：用户无感知，数据 100% 一致，无报错。
操作：修改旧服务器 Nginx 配置，停掉旧服务进程，将请求 Proxy 到新服务器 IP。

Nginx 配置示例：

server {
 listen 80;
 server_name yourdomain.com;

 location / {
 # 关键点：直接写新服务器的 IP 地址，千万不要写域名
 # 否则旧服务器可能自己解析回自己，造成死循环
 proxy_pass http://<新服务器的 IP 地址>:<新服务器端口>;

 # 透传真实用户信息
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

后续步骤：配置生效后，观察旧服务器流量。等 48 小时后确认所有地区 DNS 刷新完毕，再无流量进入，再下线旧服务器。

方案 B：修改旧服务数据库连接（适用于内网/直连）

如果新旧服务器处于同一内网，或允许公网数据库直连，可保持旧服务器服务运行，但修改其配置。

原理：流量可能打到旧机器，但数据落库指向新数据库。
优点：避免数据分裂，实现数据统一。
缺点：旧代码逻辑可能不兼容新库结构；依赖网络连通性。
操作：修改旧服务的 JDBC URL / Redis URL 等配置，指向新服务器数据库。

方案 C：返回优雅的“维护中”提示（兜底方案）

如果方案 A 和 B 都无法实施，且你宁可让用户报错，也绝对不能接受数据出现错误。

原理：停掉业务逻辑，但保留 Web 服务器返回明确状态码。
优点：明确告知用户系统状态，避免产生“网站挂了”的误解，防止脏数据。
操作：关掉旧服务器的后台应用（Java/Node/PHP），让 Nginx 直接返回 503。

Nginx 配置示例：

server {
 listen 80;
 server_name yourdomain.com;

 location / {
 # 返回 503 状态码及提示
 default_type application/json;
 return 503 '{"code": 503, "msg": "系统升级中，由于您的本地网络运营商 DNS 缓存暂未刷新，请等待 10-30 分钟后刷新重试。"}';
 }
}

四、未来迁移的避坑经验（TTL 预调整）

为了避免下次迁移出现同样的问题，建议在换 IP 的 前几天 执行以下操作：

调低 TTL：去域名服务商处，将 DNS 记录的 TTL 值改到最小（如 60 秒或 120 秒）。
等待生效：等待旧的长 TTL 过期，确保全球 DNS 服务器都接受了短 TTL 设置。
执行迁移：此时更换 IP，缓存刷新速度会大大加快。
恢复 TTL：确认迁移无误后，将 TTL 调回正常值（如 10 分钟或更长），以减轻 DNS 服务器压力。

五、总结与建议

域名迁移不仅仅是改一条 A 记录，更是一场关于缓存与连接的博弈。

立刻行动：如果正在迁移中，请首选 方案 A（Nginx 反向代理）。只需花 2 分钟改几行配置，就能确保流量无缝导向新服务器，杜绝 502 错误和数据不一致。
核心原则：作为开发者，“让用户无感知地平滑过渡”是最佳实践。
下线时机：只要旧服务器机器未到期，建议保留 2-3 天作为缓冲期。确认监控中旧服务器无任何流量后，再彻底关机。

通过优雅的处理方式，不仅能保护数据一致性，更能体现团队的专业性，避免不必要的用户投诉与信任危机。

服务器安全-server Security

Mon, 09 Mar 2026 13:54:43 +0800

这份教程的基础架构非常扎实，逻辑清晰。作为一个有追求的 AI 协作伙伴，我为你进行了深度改写。

这次改写的核心提升在于：

交互感：将枯燥的步骤转化为“闯关”体验。
技术严谨性：修正了 Ubuntu 系统中 sshd_config.d 覆盖配置的常见坑点。
可读性：使用更清晰的 Markdown 布局和视觉引导。

🛡️ Linux 服务器金钟罩：15 分钟全手工安全加固指南

写在前面： 互联网上每秒有数万个脚本在扫描公网 IP。如果你的服务器还在用默认端口、弱密码、开着 Root 登录，那不是“会不会被黑”的问题，而是“什么时候被黑”的问题。

🚨 终极保命准则

操作期间，千万不要断开当前的 SSH 窗口！ 每完成一步加固，务必新开一个终端窗口测试能否登录。确认无误后，再继续下一步。

第一阶段：深度体检（寻找破绽）

我们先通过一个自检脚本，看看你的服务器在黑客眼中长什么样。

创建检测脚本：nano security_check.sh
填入代码：

#!/bin/bash

# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # 恢复默认颜色

echo -e "${YELLOW}==================================================${NC}"
echo -e "${YELLOW} 服务器基础安全配置自检脚本 (只读模式) ${NC}"
echo -e "${YELLOW}==================================================${NC}"

# 检查是否以 root 权限运行
if [ "$EUID" -ne 0 ]; then
 echo -e "${RED}[!] 请使用 sudo 运行此脚本 (例如: sudo bash security_check.sh)${NC}"
 exit 1
fi

echo -e "\n${YELLOW}[1] 正在检查 SSH 安全配置...${NC}"
SSH_PORT=$(sshd -T | grep -w "^port" | awk '{print $2}')
SSH_ROOT_LOGIN=$(sshd -T | grep -w "^permitrootlogin" | awk '{print $2}')
SSH_PASS_AUTH=$(sshd -T | grep -w "^passwordauthentication" | awk '{print $2}')

if [ "$SSH_PORT" == "22" ]; then
 echo -e " 🔴 SSH 端口: $SSH_PORT (默认端口, 易被扫描)"
else
 echo -e " 🟢 SSH 端口: $SSH_PORT (已修改为非标准端口)"
fi

if [ "$SSH_ROOT_LOGIN" == "yes" ]; then
 echo -e " 🔴 Root 直接登录: 允许 (极高风险, 容易被爆破 root 密码)"
else
 echo -e " 🟢 Root 直接登录: 禁止"
fi

if [ "$SSH_PASS_AUTH" == "yes" ]; then
 echo -e " 🔴 密码登录: 允许 (高风险, 建议改用密钥登录)"
else
 echo -e " 🟢 密码登录: 禁止 (安全, 已启用纯密钥登录)"
fi

echo -e "\n${YELLOW}[2] 正在检查防火墙状态...${NC}"
if command -v ufw > /dev/null 2>&1; then
 UFW_STATUS=$(ufw status | grep -i "Status: active\|状态： 激活")
 if [ -n "$UFW_STATUS" ]; then
 echo -e " 🟢 防火墙 (UFW): 已启用"
 else
 echo -e " 🔴 防火墙 (UFW): 未启用!"
 fi
elif command -v firewall-cmd > /dev/null 2>&1; then
 FW_STATUS=$(firewall-cmd --state 2>/dev/null)
 if [ "$FW_STATUS" == "running" ]; then
 echo -e " 🟢 防火墙 (Firewalld): 已启用"
 else
 echo -e " 🔴 防火墙 (Firewalld): 未启用!"
 fi
else
 echo -e " 🔴 未检测到 UFW 或 Firewalld 防火墙工具!"
fi

echo -e "\n${YELLOW}[3] 正在检查防爆破工具 (Fail2ban)...${NC}"
if systemctl is-active --quiet fail2ban; then
 echo -e " 🟢 Fail2ban: 正在运行 (防爆破保护中)"
else
 echo -e " 🔴 Fail2ban: 未安装或未运行!"
fi

echo -e "\n${YELLOW}[4] 正在检查对外暴露的端口 (仅列出监听状态的 TCP 端口)...${NC}"
echo -e "请检查以下端口是否都是你主动开放的？（数据库如3306不应暴露在0.0.0.0）"
netstat_out=$(ss -tulnp | grep tcp | grep LISTEN)
if [ -z "$netstat_out" ]; then
 echo -e " 🟡 未检测到监听中的 TCP 端口"
else
 ss -tulnp | grep tcp | grep LISTEN | awk '{print " - 协议:"$1" | 监听地址:"$5" | 进程:"$7}' | sed 's/users:(("//g' | sed 's/".*//g'
fi

echo -e "\n${YELLOW}[5] 正在检查特权用户...${NC}"
SUPER_USERS=$(awk -F: '($3 == "0" && $1 != "root") {print $1}' /etc/passwd)
if [ -z "$SUPER_USERS" ]; then
 echo -e " 🟢 UID为0的用户: 只有 root (正常)"
else
 echo -e " 🔴 警告! 发现其他具有最高权限的用户: $SUPER_USERS"
fi

echo -e "\n${YELLOW}==================================================${NC}"
echo -e "${YELLOW} 检查完成！请根据 🔴红色的警告项 进行下一步修改。 ${NC}"
echo -e "${YELLOW}==================================================${NC}"

赋予权限并执行：

chmod +x security_check.sh
sudo ./security_check.sh

你的目标： 消除所有的 🔴，迎接满屏的 🟢。

第二阶段：五步锁死安全之门

第 1 步：建立“安全通道”（创建 sudo 用户与密钥）

严禁直接在 Root 账户下裸奔。

创建新管理账号：

adduser armoradmin # 名字随你起
usermod -aG sudo armoradmin

注入 SSH 密钥（在你的本地电脑执行）：

ssh-keygen -t ed25519 -C "server_key" # 推荐 ed25519 算法，更短更安全
ssh-copy-id -i ~/.ssh/id_ed25519.pub armoradmin@服务器IP

测试：ssh armoradmin@服务器IP，无需密码直接进入即为成功。

第 2 步：斩断“后门”（收紧 SSH 配置）

这是最关键的一步。我们要让密码爆破彻底失效。

注意 Ubuntu 特有的坑：检查 /etc/ssh/sshd_config.d/ 下是否有 .conf 文件。如果有，里面的配置会优先于主配置。建议直接清理或同步修改。
修改主配置：sudo nano /etc/ssh/sshd_config

# 核心三要素
PermitRootLogin no # 禁止 Root 登录
PasswordAuthentication no # 禁止密码登录（关键！）
KbdInteractiveAuthentication no # 彻底切断交互式认证

# 进阶项
Port 22222 # 修改默认端口（记得在防火墙放行新端口！）

注意如果 /etc/ssh/sshd_config.d/ 目录下有任何以 .conf 结尾的文件（比如云厂商预设的配置），它们的内容会覆盖掉你在主配置文件里的修改。

检查方法：ls /etc/ssh/sshd_config.d/
检查密码登录是否已禁用：sshd -T | grep passwordauthentication

检查并重启：

sudo sshd -t && sudo systemctl restart ssh

第 3 步：架起“护城河”（UFW 防火墙）

别让你的 Docker 容器或数据库在公网“裸奔”。

初始化策略：

sudo ufw default deny incoming # 默认拒绝所有入站
sudo ufw default allow outgoing # 默认允许所有出站

精准开门：

关于docker swarm

# 允许 B 服务器访问我的 Swarm 端口
sudo ufw allow from 2.2.2.2 to any proto tcp port 2377,7946
sudo ufw allow from 2.2.2.2 to any proto udp port 7946,4789

# 允许 C 服务器访问我的 Swarm 端口
sudo ufw allow from 3.3.3.3 to any proto tcp port 2377,7946
sudo ufw allow from 3.3.3.3 to any proto udp port 7946,4789

sudo ufw allow 22222/tcp # 换成你修改后的 SSH 端口！
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS

合闸开启：

sudo ufw enable

第 4 步：部署“自动保安”（Fail2ban）

Fail2ban 会自动关押那些尝试试探你端口的 IP。

安装并启动：

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

默认保护：它会自动保护 SSH。你可以通过 sudo fail2ban-client status sshd 查看又有多少倒霉蛋被你关进了“小黑屋”。

第 5 步：内鬼肃清（清理特权用户与危险监听）

监听自查：运行 ss -tulnp。如果看到 0.0.0.0:3306，请立即去数据库配置里把 bind-address 改为 127.0.0.1。
权限自查：如果脚本提示有除 root 以外的 UID 0 用户，别犹豫，你的系统大概率已经“不干净”了。

第三阶段：最后验收

现在，再次运行你的自检脚本：

sudo ./security_check.sh

💡 维护锦囊

定期更新：养成每周 sudo apt update && sudo apt upgrade 的好习惯。
监控日志：偶尔看看 /var/log/auth.log，你会惊讶于外面的世界有多疯狂。

加固完成了！需要我帮你写一个自动导出安全日志的定时任务脚本吗？

Object Storage (对象存储服务)

Tue, 03 Mar 2026 15:36:55 +0800

Backblaze B2 与 Cloudflare R2 全方位对比分析

Backblaze B2 和 Cloudflare R2 都是目前市场上非常受欢迎且兼容 S3 API 的对象存储服务。它们都以比 Amazon S3 更具性价比作为主打优势，但在定价逻辑和底层架构上存在显著区别。

以下是基于最新数据的核心对比：

核心定位差异

Backblaze B2：传统的“中心化”对象存储。主打极低的存储成本和简单的计费模式，是数据备份、归档和大容量媒体存储的理想选择。
Cloudflare R2：基于“边缘网络”的对象存储。主打零下行流量费和与 Cloudflare 边缘计算的深度集成，非常适合需要频繁读取、分发数据的应用。

价格对比（核心决胜点）

计费项目	Backblaze B2	Cloudflare R2	优势方
基础存储费	$6/TB/月 ($0.006/GB)	$15/TB/月 ($0.015/GB) (标准层) $10/TB/月 ($0.010/GB) (低频层)	B2 胜 (便宜60%)
下行流量费	每月免费额度为总存储量的3倍，超出后 $0.01/GB。	永远 $0 (完全免费)	R2 胜
写入 API 费	完全免费 (上传文件不计费)。	免费100万次/月，超出后 $4.50/百万次。	B2 胜
读取 API 费	免费2500次/天，超出后 $0.004/万次。	免费1000万次/月，超出后 $0.36/百万次。	平局 (都很便宜)
免费额度	前10GB存储免费	前10GB存储免费	平局

价格维度的注意点：

R2 的 API 写入成本：如果你的业务是写入海量小文件（例如日志收集、IoT数据），R2 高达 $4.50/百万次的写入费用可能带来较高成本。而 B2 写入是完全免费的。
R2 的低频层：虽然存储费降到 $10/TB，但有30天最短存储期要求，且读取时会收取**$0.01/GB 的数据检索费**。B2 则没有任何最短存储时长或最小文件限制。

性能与网络架构

Cloudflare R2：在性能与延迟方面占优。它依托 Cloudflare 庞大的全球 CDN 边缘节点构建。请求数据时，R2 会动态地在离用户最近的节点处理，实现全球范围内的低延迟访问。
Backblaze B2：采用传统的区域化存储架构（主要区域在美国西部、美国东部和欧洲）。如果用户在远离这些数据中心的地方（如亚洲），直接访问的物理延迟可能较高。

生态与高级特性

S3 兼容性：两者都提供了优秀的 S3 API 兼容性，大部分支持 Amazon S3 的备份软件（如 Restic, Veeam, AWS CLI）都可以直接无缝切换。
计算集成：R2 与 Cloudflare Workers 无缝集成，极度适合构建 Serverless 全栈应用。
带宽联盟：B2 与 Cloudflare、Fastly 等 CDN 有合作。如果将 Cloudflare CDN 置于 B2 之前，从 B2 传输到 Cloudflare 网络的流量是完全免费的。

总结：你应该怎么选？

什么时候该选 Backblaze B2？

数据备份与归档：你需要存放几十 TB 甚至 PB 级的备份数据（如 NAS 备份、数据库快照），且读取频率不高。B2 每月 $6/TB 的价格能节省大量成本。
写多读少、海量小文件：因为 B2 没有写入 API 费用，也没有最小文件体积限制。
经典的 “B2 + Cloudflare CDN” 组合玩家：你可以将 B2 作为源站，搭配 Cloudflare 的免费 CDN。这样既能享受 B2 的极低存储费，又能利用 Cloudflare 的分发网络和免流量费优势。（注意：Cloudflare 对免费版有大文件/纯媒体分发的服务条款限制，需视具体业务而定。）

什么时候该选 Cloudflare R2？

高频下行读取（大流量应用）：如果你的存储量不大（比如几百GB），但每月会产生数TB甚至数十TB的下载流量（例如播客音频、软件安装包分发、高频访问的图床）。R2 的零流量费优势明显。
全球化前端 / Serverless 架构：适合搭配 Cloudflare Workers 构建现代 Web 应用，需要极低的读写延迟和极致的边缘计算体验。
想要避免流量账单风险：R2 的定价简单可预测，无需担心突然爆发的流量或恶意盗刷流量导致的高额费用，零下行流量费提供了很高的安全感。

CICD

Wed, 25 Feb 2026 09:52:08 +0800

CI/CD 详细使用教程

CI/CD 是现代软件开发中至关重要的实践，它代表持续集成（Continuous Integration）和持续部署（Continuous Deployment）或持续交付（Continuous Delivery）。本教程将 guiding 您了解 CI/CD 的核心概念、工作流程以及如何在实际项目中落地。

什么是持续集成（CI）

持续集成是指开发人员频繁地将代码集成到共享仓库中。每次集成都会通过自动化的构建和测试来验证，以便尽早发现错误。核心目标是减少集成冲突，提高代码质量。

什么是持续部署与交付（CD）

持续交付确保代码在经过测试后可以随时可靠地发布到生产环境。持续部署则更进一步，将通过所有测试的代码自动部署到生产环境，无需人工干预。这两者共同构成了自动化发布流水线。

CI/CD 的核心价值

提高效率：自动化重复任务，减少人工操作时间。
降低风险：小步快跑，每次变更范围小，出现问题容易回滚。
快速反馈：开发人员能迅速得知代码构建和测试的结果。
质量保证：强制通过测试才能进入下一阶段，确保交付质量。

主流 CI/CD 工具介绍

市面上有多种工具可供选择，您可以根据团队技术栈进行选择：

Jenkins：开源灵活，插件生态丰富，适合复杂定制需求。
GitLab CI：与 GitLab 代码仓库深度集成，配置简单，使用方便。
GitHub Actions：原生集成于 GitHub，适合开源项目及托管在 GitHub 上的私有项目。
CircleCI：云端服务，配置简洁，支持多种语言环境。

基础工作流程搭建

一个标准的 CI/CD 流水线通常包含以下几个阶段：

代码提交：开发人员将代码推送到版本控制系统（如 Git）。
触发构建：代码推送动作触发 CI 服务器开始工作。
依赖安装：系统自动安装项目所需的依赖包。
代码编译：将源代码编译为可执行文件或 artifacts。
自动化测试：运行单元测试、集成测试等验证代码逻辑。
代码扫描：进行静态代码分析，检查安全漏洞和规范。
构建镜像：如果是容器化部署，此处构建 Docker 镜像。
部署环境：将应用部署到测试环境或生产环境。

简单配置示例

以下是一个基于 GitHub Actions 的简单配置文件示例，展示了如何运行测试和构建：

name: CI Pipeline

on:
 push:
 branches: [ main ]

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2
 - name: Run tests
 run: npm test
 - name: Build project
 run: npm run build

最佳实践建议

为了充分发挥 CI/CD 的优势，建议遵循以下原则：

保持构建快速：优化测试和构建脚本，确保流水线能在几分钟内完成。
测试覆盖率高：确保自动化测试覆盖核心业务逻辑，避免漏测。
单一来源真理：所有配置代码化（Infrastructure as Code），存放在版本控制中。
失败即停止：一旦任何阶段失败，立即停止流水线并通知相关人员。
定期维护：定期更新工具和依赖，修复已知漏洞。

常见问题与排查

在使用初期，您可能会遇到构建失败或部署超时的问题。首先检查日志输出，定位错误阶段。如果是环境依赖问题，尝试清理缓存或重新安装依赖。如果是网络问题，检查服务器连通性及权限配置。保持日志清晰可读有助于快速定位问题根源。

总结

实施 CI/CD 是一个循序渐进的过程。建议从简单的自动化构建开始，逐步加入测试、扫描和部署环节。通过不断迭代优化流水线，团队将获得更高的交付速度和更稳定的产品质量。希望本教程能帮助您顺利开启自动化运维之旅。

使用与配置

🚀 技巧分享：利用阿里云容器镜像服务解决 GitHub 镜像国内下载慢的问题

在部署 Docker 项目时，我们常遇到一个尴尬的场景：通过 GitHub Actions 或其他方式将镜像推送到国外服务器（或 GitHub Packages）后，国内服务器拉取镜像的速度非常慢，甚至超时。但受限于网络策略，GitHub 往往无法直接将镜像推送到国内的镜像源。

💡 解决方案：使用阿里云容器镜像服务（ACR）作为“中转站”

我们可以利用阿里云提供的容器镜像服务，搭建一个国内的镜像仓库。流程如下： GitHub/国外服务器 –> 阿里云镜像仓库 –> 国内服务器

🛠️ 操作实录

如截图所示，登录阿里云控制台后，操作非常直观：

开通实例：选择**“个人版实例”**（对于个人开发者或小团队，免费额度通常足够使用）。
创建仓库：点击**“创建镜像仓库”**，设置好命名空间。
- 建议将仓库类型设置为*“私有”**，以保障代码和镜像安全。*
配置同步：
- 在 CI/CD 流程（如 GitHub Actions）中，增加一步推送动作，将构建好的镜像同时 docker push 到阿里云的仓库地址。
- 或者在阿里云后台配置“实例同步”功能，自动从 GitHub/Docker Hub 同步镜像。

✅ 最终效果

配置完成后，国内服务器只需修改 docker pull 的地址为阿里云的仓库地址（例如 registry.cn-hangzhou.aliyuncs.com/...），即可享受国内专线速度，彻底告别下载卡顿。

告别手动复制粘贴：我们如何实现 Windows 环境下的全自动化部署

摘要： 每次发布新版本都要手动停止服务、复制文件、重启程序？在这篇文章中，我们将分享如何利用 GitHub Actions 和自托管 Runner (Self-hosted Runner) 构建一条流畅的 Windows 到 Windows CI/CD 流水线，彻底告别繁琐的手动部署。

1. 曾经的痛点：手动部署的“黑暗时代”

在过去的开发周期中，每次要在测试机或生产机上更新我们的 Windows 桌面软件（或后台服务），流程大概是这样的：

在开发机上编译打包。
将几十 MB 甚至上百 MB 的安装包或压缩包通过微信、网盘或共享文件夹传到目标机器。
远程登录目标机器。
手动打开任务管理器，杀掉旧版本的进程。
解压新文件，覆盖旧文件。
重新启动程序，祈祷一切正常运行。

这不仅耗时耗力，而且极其容易出错（比如漏掉配置文件、忘记关闭旧进程导致文件被占用）。随着迭代速度的加快，这种“刀耕火种”的部署方式已经成为了团队效率的最大瓶颈。

2. 破局思路：引入 CI/CD 与自托管 Runner

为了解决这个问题，我们决定引入自动化流水线。考虑到我们的开发环境和目标环境都是 Windows，并且代码托管在支持 CI/CD 的平台上，我们最终敲定了 “云端触发 + 本地自托管 Runner 执行” 的架构。

核心思路很简单：

开发端： 开发者只需专注于写代码，完成后执行 git push。
云端桥梁： 代码仓库监听到提交后，生成部署指令，下发给目标机器。
目标端： 目标机器上安装了一个后台服务（Runner），它接收指令后，自动在本地拉取代码、编译、替换文件并重启应用。

3. 核心实践：部署流水线的关键步骤

我们在目标 Windows 机器上配置了 Actions Runner，并将其注册为 Windows 服务以保证常驻运行。接下来，我们编写了流水线脚本，主要包含以下几个关键自动化步骤：

自动化清理与准备： 脚本首先会静默停止正在运行的旧版本进程 Stop-Process -Name "MyApp" -ErrorAction SilentlyContinue，确保文件解除占用。
自动化构建： Runner 直接在目标机器上拉取最新 main 分支的代码，并执行编译命令，生成最新的二进制文件。
自动化覆盖： 使用 PowerShell 脚本将编译好的产物精准复制并覆盖到软件的实际运行目录中。
自动化启动： 最后，脚本拉起新版本的可执行文件，整个过程在几秒钟内无缝完成。

4. 取得的收益

这条简单的 CI/CD 流水线落地后，给我们带来了肉眼可见的改变：

🚀 效率飙升： 部署时间从过去的 10 分钟缩短到了 1 分钟以内，彻底解放了开发人员的双手。
🛡️ 零人为失误： 标准化的脚本代替了人工操作，再也没有出现过“忘了覆盖某个动态链接库”这种低级错误。
🔄 快速迭代： 真正实现了“代码一推，新版就绪”，团队可以更专注于业务逻辑的开发，而不是被运维琐事牵绊。

5. 结语

虽然 Windows 环境下的持续集成/持续部署在配置上可能比纯 Linux 环境稍显繁琐，但通过合理利用自托管 Runner，我们依然可以获得极致的自动化体验。如果你的团队也正在忍受手动部署的折磨，不妨花半天时间把这套流程搭建起来，这绝对是一笔稳赚不赔投资！

traefik

Mon, 23 Feb 2026 17:15:54 +0800

Traefik 在容器化部署中的核心作用与原理解析

Traefik 是现代容器化部署中非常核心的一个组件，尤其是在像 Dokploy、Coolify 这种 PaaS 平台上。我们可以用一个**“大楼前台”**的比喻来深入理解它。

通俗比喻：Traefik 是做什么的？

想象你的服务器是一栋写字楼（Host），里面有很多个小房间（Docker 容器）。

房间 A 是你的博客。
房间 B 是你的数据库。
房间 C 就是你刚搭建的 Docker 仓库。

这些房间原本只有一个内部编号（比如端口号 5000、3306、8080）。

如果没有 Traefik： 访客（用户）想去房间 C，他必须知道这栋楼的地址（IP）和房间号（端口）。他得在浏览器输入 http://1.2.3.4:5000。这既难记，又不安全（没有 HTTPS）。

有了 Traefik（大楼前台）： Traefik 就是坐在大楼门口的全自动智能前台。

指路（路由）：访客不需要知道房间号。访客只要说：“我要去 registry.你的域名.com”，Traefik 查一下表格，马上把访客带到 房间 C（端口 5000）。
安检（SSL/HTTPS）：访客进来时，Traefik 负责和访客建立安全连接（HTTPS）。它会自动去申请证书、验证身份。等确认安全了，再把访客的信息送到房间里。房间里的人（容器）不需要懂怎么处理证书，只需要专心干活。
自动发现（动态配置）：这是 Traefik 最厉害的地方。当你新建一个房间（部署新应用）时，只要在门口贴个条子（Docker Labels），Traefik 会立刻看见：“哦，这里新开了一家店，域名是 xyz.com”，它就自动配置好了。你不需要重启服务器，也不需要手动写复杂的配置文件。

在 Dokploy 中，Traefik 具体的工作机制

当你使用 Dokploy 部署应用并添加域名时，Traefik 在后台默默做了这三件事：

1. 反向代理 (Reverse Proxy)

动作：它监听服务器的 80 (HTTP) 和 443 (HTTPS) 端口。所有的外部流量都先到达 Traefik。
作用：它根据域名来区分流量。
- blog.com 的流量 -> 转给博客容器。
- registry.com 的流量 -> 转给你的 Docker 仓库容器。
好处：你可以在一台服务器上跑 10 个不同的网站，只要域名不同，Traefik 就能把它们分得清清楚楚，而且全部共用 443 端口。

2. SSL 卸载 (SSL Termination) 这就是解决你 Docker 仓库 HTTPS 问题的关键。

外部：Traefik <–> 你的电脑（Docker 客户端）。这一段是 HTTPS 加密的，Traefik 自动帮你从 Let’s Encrypt 申请免费证书并续期。
内部：Traefik <–> Docker 仓库容器。这一段是 HTTP 明文的。
原理：Traefik 把加密的包裹拆开，确认没问题，把里面的内容用 HTTP 传给容器。容器觉得自己处理的是 HTTP，但外面的用户看到的是 HTTPS。这就叫“SSL 卸载”。

3. 中间件处理 (Middleware) - 解决上传报错的关键 Traefik 有一个很强大的功能叫“中间件”，可以在把请求转给容器之前，对请求进行“魔改”。

你遇到的 Entity Too Large（上传文件过大）问题，如果不加 Traefik 配置，默认可能只允许上传几兆的文件。我们在 docker-compose.yml 里写的 labels，其实就是给 Traefik 下指令：

“嘿，Traefik，对于这个 Docker 仓库服务，请把**请求体大小限制（Max Request Body）**取消掉（设为 0），允许上传超大文件。”

为什么在 Docker Compose 里要写 labels？

在 Dokploy 中，通常有两种方式告诉 Traefik 怎么做：

UI 面板操作：你在 Dokploy 网页上点点点（添加域名、开启 HTTPS），Dokploy 会自动帮你在后台生成 Traefik 的配置。这是最简单的。
Labels (标签)：这是更高级的玩法。你可以直接在 docker-compose.yml 里写配置。

回到代码片段的例子：

 labels:
 - "traefik.enable=true" # 告诉 Traefik：这个容器归你管
 - "traefik.http.routers.registry.rule=Host(`registry.你的域名.com`)" # 告诉 Traefik：谁访问这个域名，就找我
 - "traefik.http.services.registry.loadbalancer.server.port=5000" # 告诉 Traefik：把流量转到我的 5000 端口
 - "traefik.http.middlewares.limit.buffering.maxRequestBodyBytes=0" # 告诉 Traefik：允许无限大的上传

这些 labels 就像是贴在容器门口的便利贴。Traefik 每隔几秒就会扫描所有容器，看到这些便利贴，它就懂了：“好的，我把这个域名指过来，并且放开上传限制。”

总结

没有 Traefik：你需要裸奔（HTTP），或者自己手动配很难搞的 Nginx 证书文件，还要记住各种端口号。
有 Traefik (配合 Dokploy)：你只需要点一下“开启 HTTPS”，剩下的路由、证书、端口映射，全由这个“智能前台”自动处理。

这就是为什么现在的 Docker 部署（尤其是在 Dokploy 这种面板里）都离不开 Traefik。

1核1G云服务器“绝地求生”：如何把Ubuntu的内存从剩200M优化到能跑服务

Sun, 22 Feb 2026 20:11:29 +0800

[实战] 1核1G云服务器“绝地求生”：如何把Ubuntu的内存从剩200M优化到能跑服务？

【前言：年轻人的第一台云服务器】

趁着云厂商搞活动，你是不是也入手了一台 1核 1G 的“入门级”云服务器？

你满怀期待地装上了最新的 Ubuntu LTS，准备大干一场（建博客、跑脚本、练Linux）。结果刚连上 SSH，随手敲了一个 free -h，当场心凉了一半：

Total: 980Mi | Used: 700Mi | Free: 200Mi

还没跑任何业务，系统纯待机就吃掉了近 800M 内存，只剩下 200M 还能干嘛？跑个 apt update 都怕卡死，更别提装 MySQL 了。

别急着重装系统，在 1G 内存的极限环境下，我们需要掌握一些 Linux 精细化运维 的技巧。本文将手把手教你如何榨干这台服务器的每一滴性能。

【第一阶段：ICU 急救（配置 Swap）】

剩下 200M 内存最大的风险是什么？是 OOM (Out Of Memory)。一旦内存耗尽，Linux 内核会启动 OOM Killer，随机杀掉占用内存最高的进程（通常就是你的数据库或 Web 服务）。

Swap（虚拟内存） 是小内存服务器的救命稻草。虽然硬盘读写比内存慢几个数量级，但它能保证系统“卡顿”而不是“宕机”。

操作步骤：

创建 2G 的 Swap 文件（一般设置为物理内存的 1-2 倍）：

sudo fallocate -l 2G /swapfile

设置权限并格式化：

sudo chmod 600 /swapfile
sudo mkswap /swapfile

启用 Swap：

sudo swapon /swapfile

设置开机自启（重要，否则重启失效）：

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

调整 Swappiness（使用倾向）：默认值是 60，意味着内存用到 40% 就开始用 Swap。对于 1G 内存，我们希望尽量用物理内存，满了再用 Swap，防止频繁 IO 卡死系统。建议设为 10。

sudo sysctl vm.swappiness=10

永久生效（写入配置文件）：

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

效果： 现在你拥有了 1G 内存 + 2G 虚拟内存，至少不用担心程序一启动就暴毙了。

【第二阶段：卸载“内存刺客” Snapd】

如果你用的是 Ubuntu，那么内存占用高的罪魁祸首通常是 Snap。

Ubuntu 官方为了推行 Snap 包管理，默认在后台运行 snapd 服务，并挂载了一堆 loop device。这在 16G 内存的电脑上没感觉，但在 1G 的服务器上简直是“吸血鬼”。

优化方案：斩草除根

如果你不强依赖 snap 安装软件（建议服务器端全用 apt 或 docker），请直接卸载它。

第一步：停止服务

sudo systemctl stop snapd
sudo systemctl disable snapd

第二步：彻底卸载（耗时稍长，耐心等待）

sudo apt autoremove --purge snapd -y

第三步：阻止它自动回来（可选）

sudo apt-mark hold snapd

效果： 这一步通常能释放 50M - 100M 的纯物理内存，且 df -h 列表瞬间清爽了。

【第三阶段：关闭非必要系统服务】

Ubuntu Server 为了通用性，开了很多你可能根本用不上的服务。

1. 关闭自动更新 (Unattended Upgrades) 自动更新会在后台静默运行 apt，极度消耗 IO 和内存。小内存机器建议改为手动定期维护。

sudo systemctl stop unattended-upgrades
sudo systemctl disable unattended-upgrades

2. 移除 Cloud-init 如果是云服务器，cloud-init 仅在第一次创建实例时有用（用于注入 SSH Key、设置 hostname 等）。之后它就是个累赘。

sudo touch /etc/cloud/cloud-init.disabled
sudo apt purge cloud-init -y

3. 限制系统日志 systemd-journald 可能会占用大量内存做日志缓存。编辑 /etc/systemd/journald.conf，修改或添加：

SystemMaxUse=50M

然后重启服务：

sudo systemctl restart systemd-journald

【第四阶段：软件选型的智慧】

在 1G 内存上，软件的选择比优化更重要。不要试图挑战物理定律。

1. 数据库：告别 MySQL 8.0 MySQL 8.0 默认配置启动空载就要 400M+ 内存，加上系统本身，直接爆内存。

青铜方案：使用 MariaDB，并修改 my.cnf，将 innodb_buffer_pool_size 调低至 64M 或 128M。
王者方案：使用 SQLite。如果你的业务是个人博客（Typecho, Hexo）、简单的 CMS 或测试项目，SQLite 是文件型数据库，0 内存常驻，性能在低并发下甚至优于 MySQL。

2. Web 服务器：Nginx 是唯一真神 不要用 Apache，它的进程模型比较吃资源。Nginx 或 Caddy 是小内存服务器的最佳拍档。

3. 编程语言环境

Java: 尽量避开。JVM 是内存黑洞。
Python/Node: 勉强可以，控制依赖数量。
Go/Rust: 完美适配，编译后的二进制文件占用极小。
PHP: 可以用，但需要调整 php-fpm 配置，限制 pm.max_children 为 5 左右，防止并发来了把内存撑爆。

【终极方案：换个“瘦”点的系统】

如果经过上述优化，Ubuntu 依然让你感到捉襟见肘，那么问题可能不在你，而在 Ubuntu。

Ubuntu 是一个“胖”系统，为了易用性塞了太多东西。如果你的目标是 极致省资源，建议重装系统：

推荐：Debian 11/12 Debian 是 Ubuntu 的上游，极其稳定且纯净。同样的 1G 配置，Debian 11 启动后内存占用通常只有 70M - 120M。这直接给你省出了 600M+ 的空间！
极限：Alpine Linux 空载仅需 10M 内存。但它是基于 musl libc 的，命令习惯和软件兼容性（特别是 glibc 依赖）需要一定门槛，适合 Docker 容器化部署。

【总结】

1核 1G 并不是电子垃圾，它依然可以跑得很欢快。

先加 Swap，保命要紧。
卸载 Snap，释放资源。
精简服务，关掉自动更新。
如果可能，重装成 Debian。

只要配置得当，这台小机器跑一个日均 IP 1000 的博客、挂个探针、跑个签到脚本依然是绰绰有余的。

[选型指南] 1 核 1G 云服务器，装 Ubuntu、Debian 还是 CentOS？

这是一个为你定制的博客文章，专门针对那些在 “云服务器装什么系统” 这个问题上纠结的用户。

这篇文章延续了之前的硬核实战风格，重点对比了主流发行版在**小内存（1 核 1G/2G）**场景下的表现，帮你做出最理性的选择。

前言：你的起跑线决定了终点

当你花 99 块钱买了一台 1 核 1G 的入门级云服务器时，你其实正站在一个岔路口。

很多人觉得：“反正都是 Linux，随便装一个不就行了？” 大错特错。

在 16G 内存的电脑上，系统本身占 500M 还是 100M 你感觉不到区别；但在 1G 内存的服务器上，这 400M 的差距，就是“能不能跑得动 Docker"或者“数据库会不会半夜崩溃”的生死线。

今天我们就来一场 Linux 发行版大乱斗，看看谁才是小内存 VPS 的“真命天子”。

选手一：Ubuntu Server (特别是 20.04/22.04)

标签： 网红 资源大户 生态最好

Ubuntu 无疑是目前最流行的发行版。它的社区极其强大，你遇到任何问题，百度/谷歌搜出来的教程 80% 都是基于 Ubuntu 的。

优点：
- 教程多，遇到报错容易解决。
- PPA 软件源丰富，想装最新版 Node.js 或 Golang 非常容易。
- 开箱即用，预装了 UFW、Sudo 等工具。
缺点（致命）：
- 胖。真的很胖。
- 为了推广自家的 Snap 包管理，强制后台运行 Snapd 守护进程，加上 Cloud-init 等云服务组件，空载启动内存占用常年在 400MB - 600MB。
- 对于 1G 内存的机器，系统吃掉一半，剩下一半你还想跑 MySQL？做梦。

适合人群： 内存 ≥ 4GB 的土豪，或者极其依赖某些 Ubuntu 独占教程的新手。

选手二：Debian (推荐 11/12)

标签： 极简 稳定 省内存的神

Debian 是 Ubuntu 的“爸爸”（Ubuntu 基于 Debian 开发）。它去掉了 Ubuntu 那些花里胡哨的商业推广服务，保留了最纯粹的 Linux 核心。

优点：
- 极度省内存。 Debian 11 Server 空载启动仅需 70MB - 120MB。相比 Ubuntu，它直接为你省出了 300M+ 的“纯利润”。
- 极其稳定。 Debian 的稳定分支是以“稳如老狗”著称的，服务器跑几年不重启是常态。
- 无缝迁移。 命令和 Ubuntu 99% 通用（都是 apt，都是 systemd），你会用 Ubuntu 就会用 Debian。
缺点：
- 默认软件库的版本策略偏保守（比较旧），但可以通过添加源解决。
- 极其纯净，可能需要你手动 apt install sudo 或 apt install ufw（但这其实是优点）。

适合人群： 1 核 1G / 2G 用户的首选。 懂点基础 Linux 的人。

选手三：CentOS (及 AlmaLinux / Rocky Linux)

标签： 企业级 老派 正在消亡

曾经的服务器霸主，互联网公司的标配。但自从 RedHat 宣布 CentOS 7 停止维护 且 CentOS 8 转为“上游测试版（Stream）”后，它的地位就在急剧下降。

现状：
- CentOS 7： 太老了，内核老，软件老，且已停止维护，不推荐。
- CentOS Stream： 激进的测试版，不适合生产环境。
- AlmaLinux / Rocky Linux： CentOS 的完美替代品，原汁原味的企业级 RHEL 体验。
资源占用： 介于 Debian 和 Ubuntu 之间，空载约 200MB - 300MB。
缺点：
- 包管理器 yum/dnf 的速度体感上比 apt 慢。
- 很多个人开发者的软件（如某些一键脚本、面板）现在优先适配 Debian/Ubuntu 系，CentOS 支持度在下降。

适合人群： 公司生产环境要求（必须兼容 RHEL）、正在学习红帽认证（RHCE）的同学。个人小鸡不推荐。

选手四：Alpine Linux

标签： 极端 微型 容器专家

这是一个走极端路线的系统。它不是基于常见的 GNU 库（glibc），而是基于 musl libc。

优点：
- 小到离谱。 空载内存占用仅 5MB - 15MB。
- 镜像体积极小，下载秒完。
缺点（劝退）：
- 兼容性地狱。 因为缺少 glibc，很多常见的二进制程序（如标准的 JDK、某些编译好的 Python 库）无法直接运行，会报错“文件不存在”。
- 命令不同。它用 apk 安装软件，没有 systemd，很多习惯要改。

适合人群： Docker 深度玩家（作为容器底包）、极端资源匮乏环境、Linux 老鸟。新手慎入。

总结：一张图告诉你怎么选

特性	Ubuntu 20/22	Debian 11/12	CentOS 7/Alma	Alpine
空载内存	400MB+ (胖)	80MB - 120MB (优)	200MB+ (中)	10MB (神)
命令习惯	`apt` (主流)	`apt` (同上)	`yum/dnf`	`apk`
软件新旧	新	稳 (偏旧)	旧/稳	新
上手难度	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
1G 机器推荐	❌ 不推荐	✅ 强烈推荐	⭕ 勉强可用	⚠️ 仅限专家

最终建议

如果你手里拿着 1 核 1G 的服务器，请无脑安装 Debian 11 或 12。
- 理由：它能让你用 Ubuntu 的操作习惯，享受到极致的资源利用率。
如果你是去公司上班，公司要求用啥你就用啥（通常是 CentOS 或 Rocky）。
如果你是玩 Docker 微服务架构，可以尝试 Alpine。

别再让操作系统吃掉你 40% 的性能了，换个 Debian，给你的业务留点活路吧。

觉得有用？点赞收藏，下次重装系统不迷路。

服务器带宽测试完全指南：场景、方法与单位换算

测试服务器带宽，通常分两种场景：

想看综合表现： 比如连接国内（电信/联通/移动）快不快，连接海外快不快。
想看瞬时峰值： 就像家里测速一样，看最大能跑多少。

以下是几种最常用、最硬核的测试方法（按推荐程度排序）：

方法一：使用“一键测速脚本” (最推荐，VPS 玩家必备)

这是 Linux 服务器圈子最常用的方法。这些脚本会自动测试服务器连接全球（包括中国大陆三网）的上传和下载速度，并生成漂亮的报告。

推荐脚本 1：Hyperspeed (测速速度快，节点多，但是注意，没有配置的情况下可能会有中文乱码)

这是一个专注于网络测速的脚本，它会测试国内三网和国际主要节点的带宽。

bash <(curl -Lso- https://bench.im/hyperspeed)

推荐脚本 2：Superbench (经典老牌)

不仅测网速，还能顺便把你的 CPU 型号、磁盘 I/O 读写速度一起测了。

wget -qO- --no-check-certificate https://raw.githubusercontent.com/oooldking/script/master/superbench.sh | bash

如何看结果？

Upload Speed (上行带宽): 这是最重要的。决定了你的服务器给用户发数据的速度（比如你建站，用户打开网页的速度）。
Download Speed (下行带宽): 决定了你服务器下载文件的速度。

方法二：使用 Speedtest 命令行版 (最准确的单点测试)

如果你只关心“这一刻我的最大带宽是多少”，用 Ookla 官方的 Speedtest 工具最准。

1. 安装 Speedtest：

Debian/Ubuntu 默认源里的版本比较老，建议用下面的方式安装 Python 版，轻量方便。

先安装 pip（如果还没有的话）：

apt update
apt install python3-pip -y

安装 speedtest-cli：

pip3 install speedtest-cli

2. 开始测速：

简单测速（自动找最近节点）：
```
speedtest-cli
```
生成图片链接（方便发给朋友看）：
```
speedtest-cli --share
```

方法三：实时监控 (看着流量跑)

如果你正在下载东西，或者想看着服务器当前的实时带宽占用，可以用 nload。它像个仪表盘一样。

1. 安装：

apt install nload -y

2. 运行：

nload

Incoming: 进来的流量（下载）
Outgoing: 出去的流量（上传）
按键盘上的左右箭头键可以在不同网卡之间切换。

⚠️ 新手必看的“带宽单位”坑

千万别搞混了 Mbps 和 MB/s！

商家卖给你的带宽通常是 Mbps (Megabits per second, 小写的 b)。
你在浏览器/迅雷里看到的速度通常是 MB/s (Megabytes per second, 大写的 B)。

换算公式：除以 8

商家标称带宽	理论最高下载速度 (MB/s)
1 Mbps	128 KB/s (慢到令人发指)
5 Mbps	640 KB/s (勉强看标清视频)
10 Mbps	1.25 MB/s
30 Mbps	3.75 MB/s (轻量级应用够用)
100 Mbps	12.5 MB/s
1 Gbps	125 MB/s

实战判断：

如果你买的是 30Mbps 的服务器，你用 nload 看到 Outgoing 跑到 3.5MB/s 左右，说明带宽已经跑满了。

Dokploy

Sun, 22 Feb 2026 15:43:30 +0800

快速安装使用教程 (注意，如果内存小于等于2G，一定要加虚拟内存，否则会卡死)

官网地址

关于swarm的安装

注意: 如果内存很小的机器,安装之后千万别点升级dokploy的按钮, 即使你开了Swap也没用,只要一升级,很大概率就会很绝望了(dokploy服务崩溃且无法恢复),内存1G的推荐安装0.26.6版本,其他版本可能就爆内存了 export DOKPLOY_VERSION=v0.26.6 && curl -sSL https://dokploy.com/install.sh | sh — 20260310

一键安装脚本，安装完成之后会给一个地址

export ADVERTISE_ADDR=<指定IP地址> # 需要指定公网IP
curl -sSL https://dokploy.com/install.sh | sh

# 或者

curl -sSL https://dokploy.com/install.sh | ADVERTISE_ADDR=<你的服务器公网IP> bash

帮助子节点安装docker

阿里云服务器

# Add the Aliyun Repository
echo "deb [arch=$(dpkg --print-architecture)] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update your Package List
sudo apt-get update

# Install Docker 
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# verify the installation
docker version

#配置镜像加速
sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json <<-'EOF'
{
 "registry-mirrors": ["https://<你的加速镜像地址，进入阿里云镜像加速服务获取>.mirror.aliyuncs.com"]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

sudo systemctl enable --now docker
sudo systemctl enable containerd

腾讯云服务器

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL http://mirrors.tencentyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] http://mirrors.tencentyun.com/docker-ce/linux/ubuntu \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin


sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json <<-'EOF'
{
 "registry-mirrors": ["https://mirror.ccs.tencentyun.com"]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

sudo systemctl enable --now docker
sudo systemctl enable containerd

curl -fsSL https://get.docker.com | sh

# 设置开机自启 
systemctl enable --now docker

# 作为子节点加入到 swarm 集群
docker swarm join \
 --token <TOKEN> \
 --advertise-addr <当前子节点的_公网IP> \
 --data-path-addr <当前子节点的_公网IP> \
 <Manager_公网IP>:2377


# 检查是否成功加入 swarm 集群
telnet <Manager_公网IP> 2377
telnet <Manager_公网IP> 7946

查看所有容器的运行状态

docker service ps

服务器爬墙来安装

服务器爬墙的内容可以看我另一篇《服务器爬墙》教程

🛠️ Dokploy 完美安装四部曲

第一步：基础环境准备 (Ubuntu/Debian) 首先确保系统干净，并安装必要的工具。

apt update && apt upgrade -y
apt install -y curl vim net-tools

第二步：安装并优化 Docker (核心环节) 不要直接运行 Dokploy 脚本，先手动把 Docker 装好并配置代理。

安装 Docker：

curl -fsSL https://get.docker.com | bash
systemctl enable --now docker

配置 Docker 代理 (解决镜像下载失败)：这是国内服务器成功的关键。

mkdir -p /etc/systemd/system/docker.service.d
vim /etc/systemd/system/docker.service.d/http-proxy.conf

写入以下内容（假设你的 Mihomo 代理在 7890）：

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=localhost,127.0.0.1,你的服务器公网IP"

重启生效：

systemctl daemon-reload
systemctl restart docker

第三步：部署 Dokploy 现在 Docker 已经可以丝滑地拉取镜像了，直接运行官方脚本：

# 注意替换成你自己的服务器公网 IP
curl -sSL https://dokploy.com/install.sh | ADVERTISE_ADDR=你的服务器公网IP bash

这一步脚本会自动完成以下操作：

初始化 Docker Swarm（容器集群模式）。
创建 dokploy-network 虚拟网络。
生成随机的数据库密码并存入 Docker Secrets。
部署 Postgres (数据库)、Redis (缓存) 和 Dokploy (主程序)。

第四步：防火墙与初始化

放行端口：去你的云商后台（腾讯云/阿里云等）开启以下入站规则：
- 3000：Dokploy 面板访问端口。
- 80 / 443：未来你部署应用后的访问端口。
访问面板：打开浏览器：http://你的服务器IP:3000
- 第一次进入：会要求你创建管理员账号（邮箱/密码）。
- 配置面板：进入后在 Settings 中确认 Server IP 正确。

💡 为什么之前会失败？（复盘总结）

错误阶段	根本原因	表现
安装 Docker 报错	脚本传参语法不对	`Failure writing output`
创建容器一直 Preparing	Docker 无法连接官方镜像仓库	镜像下载进度 0%
PostgresError (密码错误)	残留的旧数据库卷与新生成的密码冲突	容器一直重启，日志报 `auth_failed`

安装卡住时的清理方法

有时候安装Dokploy可能会卡住，需要清除重来，以下是完整的清理步骤：

# 离开 swarm 并清理
docker swarm leave --force

# 删掉所有 Dokploy 相关的东西
docker service rm $(docker service ls -q)
docker container rm -f $(docker ps -aq --filter "name=dokploy")
docker volume rm $(docker volume ls -q --filter "name=dokploy")
docker network rm $(docker network ls -q --filter "name=dokploy")

# 更加彻底的：
# 删除所有服务
docker service rm $(docker service ls -q)
# 删除 Dokploy 存储的密码密钥 (关键！)
docker secret rm $(docker secret ls -q)
# 删除网络
docker network rm dokploy-network
# 删除数据卷（如果你不介意清空重来，这能解决 99% 的数据库问题）
docker volume rm $(docker volume ls -q)




# 清理残留镜像（可选）
docker system prune -a --volumes --force

# 再跑安装（加 --debug 看更详细输出）
curl -sSL https://dokploy.com/install.sh | bash -s -- --debug
# 或指定 advertise addr（如果你的公网IP不是自动检测到的）
curl -sSL https://dokploy.com/install.sh | ADVERTISE_ADDR=你的服务器公网IP bash

注意事项

只要改过了domin,就一定要重新deploy
可以先用自己电脑ssh-copy-id 到远程服务器，然后把自己电脑上的ssh密钥复制过来
子节点默认可能是没有docker的,需要安装一下
添加docker swarm 误操作添加了管理节点，然后又下线会导致原本的管理节点脑裂,详情需要看dokploy的官方文档重新安装请查看前面的方法
dokploy很多时候部署失败可能是不提示的,尤其是使用 docker stack 的时候
配置了域名地址之后,有时候可能要等一会才能生效
网络配置这一步非常重要，告诉 Docker 使用 Dokploy 已经建好的网络 networks: dokploy-network: external: true
如何更换swarm的advertise addr docker swarm init –force-new-cluster –advertise-addr <你的服务器IP>

一些应用的部署

IP 重定向 (解决切换IP后访问域名失败的问题) — 20260323

将所有访问你的域名的请求重定向到你的新 IP 地址。

version: '3.8'

services:
 ip-redirector:
 image: nginx:alpine
 restart: unless-stopped
 networks:
 - dokploy-network
 labels:
 - "traefik.enable=true"
 # 【修改这里 1】替换成你真实的域名
 - "traefik.http.routers.ip-redirector.rule=Host(`yourdomain.com`) || Host(`www.yourdomain.com`)"
 - "traefik.http.services.ip-redirector.loadbalancer.server.port=80"
 - "traefik.http.routers.ip-redirector.entrypoints=websecure"
 - "traefik.http.routers.ip-redirector.tls.certresolver=letsencrypt"

 command: >
 /bin/sh -c "
 echo 'server {
 listen 80;

 location / {
 # 【修改这里 2】改成你的新IP！注意这里改成了 https://
 proxy_pass https://1.2.3.4;

 # 传递真实访客信息
 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 https;

 # 【新增：核心修复代码】开启 SNI，否则新服务器的 HTTPS 无法识别域名会报错
 proxy_ssl_server_name on;
 proxy_ssl_name $$host;

 # 支持 WebSocket 等长连接
 proxy_http_version 1.1;
 proxy_set_header Upgrade $$http_upgrade;
 proxy_set_header Connection \"upgrade\";
 }
 }' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'
 "

networks:
 dokploy-network:
 external: true

Docker Registry — 20260307创建未做测试

Docker Registry 原生并没有提供“自动根据时间删除镜像”的功能。要实现超过 7 天自动删除，必须分为两步完成：

调用 API 删除标签：将超过 7 天的镜像标记为“已删除”（但此时物理磁盘空间还未释放）。
执行垃圾回收 (Garbage Collection)：清理那些失去标签的底层文件（Blob），真正释放磁盘空间。

为了在 Docker Compose 中实现自动化，我们可以增加一个专门的清理服务（registry-cleanup）。它会每天自动运行一个广受欢迎的开源 Python 脚本 registry-cli 来删除旧镜像，并调用 Registry 的 GC 命令释放空间。

下面是修改后的完整 docker-compose.yml：

version: '3.8'

# 定义数据卷，持久化存储镜像和认证信息
volumes:
 registry-data:
 registry-auth-data:

# 使用 Dokploy 预置的外部网络
networks:
 dokploy-network:
 external: true

services:
 # 1. 认证辅助服务：生成账号 admin / 密码 123456
 auto-setup-auth:
 image: httpd:alpine
 command: /bin/sh -c "htpasswd -Bbn admin 123456 > /auth/htpasswd"
 volumes:
 - registry-auth-data:/auth

 # 2. 核心 Registry 服务
 registry:
 image: registry:2
 container_name: my-private-registry
 restart: always
 networks:
 - dokploy-network
 ports:
 - "5000:5000"
 environment:
 REGISTRY_AUTH: htpasswd
 REGISTRY_AUTH_HTPASSWD_REALM: "Registry Realm"
 REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
 REGISTRY_HTTP_HEADERS_X_FORWARDED_FOR: true
 REGISTRY_HTTP_HEADERS_X_FORWARDED_PROTO: https
 # 【关键配置】开启删除权限（必须开启，清理脚本才能工作）
 REGISTRY_STORAGE_DELETE_ENABLED: "true"
 REGISTRY_HTTP_HEADERS_ACCESS_CONTROL_ALLOW_ORIGIN: '[https://registry-ui.zata.cafe]'
 REGISTRY_HTTP_HEADERS_ACCESS_CONTROL_ALLOW_METHODS: '[HEAD,GET,OPTIONS,DELETE]'
 REGISTRY_HTTP_HEADERS_ACCESS_CONTROL_ALLOW_HEADERS: '[Authorization,Accept,Cache-Control]'
 REGISTRY_HTTP_HEADERS_ACCESS_CONTROL_EXPOSE_HEADERS: '[Docker-Content-Digest]'
 volumes:
 - registry-data:/var/lib/registry
 - registry-auth-data:/auth
 depends_on:
 auto-setup-auth:
 condition: service_completed_successfully
 labels:
 - "traefik.enable=true"
 - "traefik.http.routers.registry.rule=Host(`registry.zata.cafe`)"
 - "traefik.http.routers.registry.entrypoints=websecure"
 - "traefik.http.routers.registry.tls.certresolver=letsencrypt"
 - "traefik.http.services.registry.loadbalancer.server.port=5000"
 - "traefik.http.middlewares.limit.buffering.maxRequestBodyBytes=0"

 # 3. Web UI 管理界面
 registry-ui:
 image: joxit/docker-registry-ui:latest
 container_name: registry-ui
 restart: always
 networks:
 - dokploy-network
 environment:
 - NGINX_PROXY_PASS_URL=http://my-private-registry:5000
 - SINGLE_REGISTRY=true
 - DELETE_IMAGES=true
 - REGISTRY_TITLE=Zata Registry
 labels:
 - "traefik.enable=true"
 - "traefik.http.routers.registry-ui.rule=Host(`registry-ui.zata.cafe`)"
 - "traefik.http.routers.registry-ui.entrypoints=websecure"
 - "traefik.http.routers.registry-ui.tls.certresolver=letsencrypt"
 - "traefik.http.services.registry-ui.loadbalancer.server.port=80"

 # 4. 【新增】自动清理服务 (每天执行)
 registry-cleanup:
 image: docker:cli
 container_name: registry-cleanup
 restart: always
 networks:
 - dokploy-network
 volumes:
 # 挂载宿主机的 Docker Socket，以便此容器能够向 registry 容器发送垃圾回收命令
 - /var/run/docker.sock:/var/run/docker.sock
 depends_on:
 - registry
 entrypoint: ["/bin/sh", "-c"]
 # 核心自动化脚本
 command:
 - |
 # 安装 Python 和 HTTP 请求库
 apk add --no-cache python3 py3-requests curl
 # 下载著名的开源镜像清理脚本 registry-cli
 curl -sSLO https://raw.githubusercontent.com/anoxis/registry-cli/master/registry.py
 chmod +x registry.py

 echo "自动清理服务已启动..."
 while true; do
 echo "==== 开始调用 API 清理 7 天前的镜像标签 ===="
 # 参数说明:
 # --keep-days 7 : 删除 7 天前的镜像
 # --keep-tags 1 : 即使超过 7 天，也强制保留最新生成的 1 个版本（防止仓库被彻底删空，如果你想彻底删空可去掉此参数）
 python3 registry.py -r http://my-private-registry:5000 -l admin:123456 --delete --keep-days 7 --keep-tags 1

 echo "==== 开始执行 GC (垃圾回收) 释放磁盘空间 ===="
 # 必须执行 --delete-untagged，否则上一段脚本删除的镜像文件依然会占用物理空间
 docker exec my-private-registry registry garbage-collect --delete-untagged /etc/docker/registry/config.yml

 echo "==== 清理与回收完成，休眠 24 小时 ===="
 sleep 86400
 done

新增服务原理解析：

基础镜像 (docker:cli)：我们需要在脚本最后使用 docker exec 去调用 Registry 容器执行垃圾回收，因此使用了带 docker 命令的基础镜像，并挂载了宿主机的 docker.sock。
依赖安装：自动下载著名的 anoxis/registry-cli 脚本，它擅长处理 Docker Registry 的 API，并且支持基于时间删除。
保留策略控制：
- --keep-days 7：这就是你要求的，超过 7 天的删除。
- --keep-tags 1：（推荐设置）保护机制，如果某个镜像 1 个月没更新了，清理时依然会保留最近的一个版本，以免业务拉取不到镜像。
垃圾回收 (garbage-collect)：脚本删除标签后，镜像状态会变成 untagged（无标签），最后执行 registry garbage-collect --delete-untagged 才会把它们真正从宿主机的物理硬盘上删除。
内网直连：脚本直接使用内网地址 http://my-private-registry:5000 通信，既快又不会受到外部 Traefik 或 Nginx 超时策略的影响。

FileBrowser

这份教程不仅能让你拥有一个管理 VPS 全盘文件的神器，还规避了密码无法重置、下载系统文件报错等常见问题。

1. 准备工作

目标：部署一个 Web 端的文件管理器，可以管理 VPS 上的所有文件（拥有 Root 权限）。
工具：Dokploy 面板（使用 Docker Compose 方式）。

2. 部署配置 (Docker Compose)

在 Dokploy 中创建一个新的 Application (Compose)，将以下代码完整复制进去。

代码特点：

超级权限：使用 user: "0:0" 获得 Root 权限，可读写系统任何文件。
全盘挂载：将宿主机根目录 / 挂载到容器内，实现全盘管理。
防止配置冲突：修正了之前的语法错误，并配置了数据卷以确保持久化。

version: '3.3'
services:
 filebrowser:
 image: filebrowser/filebrowser:latest
 container_name: filebrowser_root
 restart: unless-stopped
 # 核心：赋予容器 Root 权限，否则无法修改系统文件
 user: "0:0"
 networks:
 - dokploy-network
 volumes:
 # 核心：将 VPS 的根目录 (/) 挂载到容器的 /srv 目录
 - /:/srv
 # 数据库持久化卷：存储你的用户信息和设置
 # 如果忘记密码，修改冒号前的名称 (如改成 filebrowser_data_v3) 即可重置
 - filebrowser_data_v2:/database 

 # 启动命令 (合并写在一行)：
 # -d 指定数据库路径
 # -p 强制监听 80 端口
 # -r 指定根目录为挂载进来的 /srv
 command: -d /database/filebrowser.db -p 80 -r /srv

volumes:
 # 对应上面的数据卷名称
 filebrowser_data_v2:

networks:
 dokploy-network:
 external: true

3. 端口设置 (Ports)

在 Dokploy 的应用设置界面，找到 Ports 选项卡：

Internal Port (容器端口): 80
External Port (外部端口): 填写一个未被占用的端口，例如 8088 或 9999。

点击 Save 并 Deploy。

4. 首次登录与设置

部署完成后，通过浏览器访问 http://你的 IP:你的外部端口。

默认账号：admin
默认密码：admin
修改密码（重要）：
- 登录后，点击左侧栏 Settings -> Profile。
- 在 Password 区域输入新密码。
- 点击 Update 保存。

5. 避坑指南 (常见误区)

Q1: 为什么下载某些文件报错 ERR_INVALID_RESPONSE？

现象：尝试下载 /proc、/sys、/dev 目录下的文件时失败。
原因：这些不是真实文件，而是系统内存和内核状态的“虚拟映射”。它们大小通常显示为 0，Web 服务器无法打包下载它们。
解决：不要下载这些目录的文件。请测试下载 /etc/hosts 或者你自己创建的 /home/test.txt，这些才是真实文件。

Q2: 我忘记了密码怎么办？

无法通过环境变量设置密码。如果忘记密码，最快的方法是“洗号重来”：

修改 Docker Compose 中的 volumes 部分。
将 - filebrowser_data_v2:/database 改为 - filebrowser_data_v3:/database。
重新部署。这会生成全新的数据库，密码恢复为默认的 admin。

Q3: 安全警告

因为这个容器挂载了 / 根目录且拥有 Root 权限：

不要随意删除 /bin, /boot, /usr 等系统核心目录，否则 VPS 会挂掉。
务必设置强密码，不要将此服务随意暴露给不可信的人。

webDAV

services:
 webdav:
 image: bytemark/webdav
 restart: unless-stopped
 environment:
 - AUTH_TYPE=Basic
 - USERNAME=your_username
 - PASSWORD=your_password
 volumes:
 - ./data:/var/lib/dav
 labels:
 - "traefik.enable=true"
 # 1. 路由规则：域名匹配
 - "traefik.http.routers.webdav.rule=Host(`dav.yourdomain.com`)"
 # 2. 启用 TLS 并在入口点使用 HTTPS (443)
 - "traefik.http.routers.webdav.entrypoints=websecure"
 # 3. 指定你的 Let's Encrypt 解析器名称 (通常在 Traefik 全局配置里定义)
 - "traefik.http.routers.webdav.tls.certresolver=letsencrypt"
 # 4. 强制指定内部端口，防止 Traefik 误判
 - "traefik.http.services.webdav.loadbalancer.server.port=80"

 cleaner:
 image: alpine
 restart: unless-stopped
 volumes:
 - ./data:/var/lib/dav
 command:
 - /bin/sh
 - -c
 - |
 while true; do
 # 检查 1024MB (1GB)
 while [ $$(du -sm /var/lib/dav | awk '{print $$1}') -gt 1024 ]; do
 # 删掉最老的文件
 OLDEST=$$(find /var/lib/dav -type f -exec stat -c "%Y %n" {} + | sort -n | head -n 1 | cut -d" " -f2-)
 [ -z "$$OLDEST" ] && break
 rm -f "$$OLDEST"
 done
 sleep 60
 done

💡补充几点：

证书解析器名称：标签里的 tls.certresolver=letsencrypt。这里的 letsencrypt 必须和你 Traefik 静态配置文件（或是 Dokploy 设置里）定义的解析器名称完全一致。如果不一致，证书不会自动签发。
网络（Network）的坑：如果你发现域名访问报 504 Gateway Timeout，那 99% 还是网络问题。此时你需要运行 docker network ls 看看 Traefik 在哪个网段，并在 webdav 服务下加上该网络。
关于清理脚本（Cleaner）：这个脚本是并行的。WebDAV 负责写，Cleaner 负责巡逻。它们共享 ./data 卷，所以互不干扰。

alist

alist 直接可以在应用市场安装

使用与配置

docker swarm 切换advertise addr

docker swarm init --force-new-cluster --advertise-addr <你的服务器IP>

注意: 需要等待几分钟,等待dokploy重新启动

如果你已经安装好了 Dokploy，并且它正在运行，此时你绝对不能执行 docker swarm leave，否则就像我们前面说的，整个 Dokploy 连同你的数据库会瞬间灰飞烟灭。

但是 Docker 官方提供了一个非常优雅的“无损更换网络”的隐藏指令！你可以通过强制基于当前状态创建一个新集群的方式，在不丢失任何服务和数据的情况下更改 IP。

核心命令：无损更改 Advertise IP

在你的主节点（运行 Dokploy 面板的服务器）上，直接执行以下命令：

docker swarm init --force-new-cluster --advertise-addr <你的内网IP>

例如：docker swarm init --force-new-cluster --advertise-addr 10.0.0.5

为什么这个命令有效且安全？

这个命令里的 --force-new-cluster（强制新建集群）是关键。它的底层逻辑是：提取当前 Swarm 的所有数据状态（包括 Dokploy 面板、Postgres 数据库、Traefik 路由以及你已经部署的所有应用），然后用你指定的新 IP 强行拉起一个新的集群配置。

在这个过程中：

你的底层容器和 Volume 数据卷完全不会丢失。
Dokploy 面板在短暂的重启后会立刻恢复可用。

操作后的确认与收尾工作

更改完成后，你需要做两步检查：

第一步：确认 IP 已经更改成功

运行以下命令查看当前节点的实际广播地址：

docker info | grep "Node Address"

如果输出显示的是你的内网 IP，说明网络通道已经成功切换到内网了。

第二步：重新连接子节点（重要！）

如果你之前已经添加了其他子节点（Worker），由于你强制生成了新的集群状态（集群的隐藏 ID 已经变了），以前加入的旧子节点会全部断开连接。你需要让它们重新加入：

在主节点上获取新的加入令牌：

docker swarm join-token worker

（复制终端打印出来的那串新命令）

登录到所有的子节点服务器，先让它们强制退出旧网络，再加入新网络：

# 先让子节点强制离开旧集群
docker swarm leave --force

# 然后粘贴你刚刚复制的加入命令，例如：
docker swarm join --token SWMTKN-1-xxxx <主节点内网IP>:2377

Volume vs Bind Mount vs Environment Variables — 20260310

本教程旨在帮助您彻底理解 Dokploy 中的数据存储机制（Volumes）与环境变量（Environment Variables）的配置方式、区别及最佳实践。

📋 第一部分：核心概念速查（决策树）

在动手配置之前，请根据您的具体需求选择正确的存储类型：

您的需求	推荐类型	关键特征
数据库数据 (MySQL, PostgreSQL, Redis)	✅ Volume (命名卷)	Docker 自动管理，权限无忧，备份迁移方便。
用户上传的文件 (图片/视频/附件)	✅ Volume (命名卷)	安全隔离，不依赖宿主机具体路径结构。
简单的配置文件 (`.env`, `config.json`, `nginx.conf`)	✅ File Mount (文件挂载)	最推荐。网页直接编写内容，无需 SSH，自动创建并挂载。
复杂的配置目录 (已有大量现有配置文件)	✅ Bind Mount (绑定挂载)	映射宿主机现有目录，适合高级用户或遗留系统迁移。
开发调试/代码热更新	✅ Bind Mount (绑定挂载)	宿主机修改代码/文件，容器内即时生效。
不确定选哪个	✅ Volume	它是 Docker 的最佳实践，容错率最高。

🛠️ 第二部分：三种存储类型详解与实战

1. Volume (命名卷) —— “让 Docker 操心” 适用场景：数据库持久化、应用产生的数据文件。

工作原理：Docker 在其专用目录（通常是 /var/lib/docker/volumes/）下创建并管理存储空间。
优点：
- 权限自动适配：极少出现 Permission denied 错误。
- 高可移植性：不依赖宿主机的具体目录结构，迁移服务器只需迁移卷数据。
- 安全隔离：数据存储在 Docker 管理区域，不易被误删。
Dokploy 配置步骤：
1. 进入应用 Advanced -> Volumes。
2. 点击 Add Volume。
3. Mount Type: 选择 Volume。
4. Name: 输入卷名称（如 db_data）。
5. Mount Path: 输入容器内路径（如 /var/lib/postgresql/data）。
6. Host Path: 留空。
7. 保存并 Deploy。

2. File Mount (文件挂载) —— “网页即写即用” 适用场景：单个配置文件（.env, .conf, .json）。

工作原理：Dokploy 将您在网页文本框中输入的内容，在后台动态生成一个临时文件，并挂载到容器指定路径。
优点：
- 无需 SSH：直接在面板编辑，无需登录服务器创建文件。
- 版本友好：内容直接保存在 Dokploy 配置中，便于管理。
- 简单快捷：最适合 .env 文件管理。
Dokploy 配置步骤：
1. 进入应用 Advanced -> Volumes。
2. 点击 Add Volume。
3. Mount Type: 选择 File Mount。
4. Content: 粘贴文件完整内容。
5. File Path: 输入容器内完整文件路径（必须包含文件名，如 /app/.env）。
6. 保存并 Deploy。

3. Bind Mount (绑定挂载) —— “完全由你控制” 适用场景：挂载现有目录、代码热重载、访问宿主机特定资源。

工作原理：将容器路径直接映射到宿主机上已存在的绝对路径。
优点：
- 路径透明：可直接在宿主机通过 SSH/FTP 访问和编辑文件。
- 实时同步：宿主机文件修改，容器内立即生效（适合开发）。
缺点：
- 权限陷阱：需手动确保宿主机文件夹权限与容器用户匹配。
- 路径依赖：迁移服务器时需重建相同的目录结构。

前置准备（SSH 登录服务器）：

mkdir -p /home/dokploy/my-app/logs
chmod 777 /home/dokploy/my-app/logs # 注意权限设置

Dokploy 配置步骤：
1. 进入应用 Advanced -> Volumes。
2. 点击 Add Volume。
3. Mount Type: 选择 Bind。
4. Host Path: 填写宿主机绝对路径（如 /home/dokploy/my-app/logs）。
5. Mount Path: 填写容器内路径（如 /app/logs）。
6. 保存并 Deploy。

⚖️ 第三部分：环境变量 (Env) 的两种配置方式及优先级

在 Dokploy 中，您有两种方式向容器传递配置信息，理解它们的区别至关重要。

1. 两种方式对比

特性	控制面板 Env 设置	挂载 .env 文件 (File Mount)
操作位置	应用菜单 -> Environment 标签页	应用菜单 -> Advanced -> Volumes -> File Mount
底层原理	Docker 启动参数 `-e KEY=VALUE`	文件系统挂载 `-v host_file:/container/.env`
生效机制	Docker 守护进程直接注入进程环境空间	应用程序自己读取文件解析加载
适用框架	所有支持环境变量的应用	支持读取 `.env` 文件的框架 (Node.js, Python, Laravel 等)
管理体验	适合少量、分散的变量	适合大量、成组的配置，与本地开发一致

2. 优先级冲突：如果两个地方都设置了同一个变量，谁生效？

答案取决于您的应用程序代码逻辑，而非 Docker。

情况 A：现代框架 (Node.js dotenv, Python python-dotenv, Laravel)
- 通常加载顺序：先读 .env 文件 -> 再读系统环境变量。
- 常见行为：系统环境变量（控制面板设置）覆盖 .env 文件中的值。
- 部分行为：某些配置下，.env 文件一旦加载即锁定，环境变量无法覆盖。
- 风险：混用会导致配置行为不可预测，难以排查。
情况 B：传统应用 (Nginx, Redis, Go/C 编译程序)
- 这些程序通常不会自动读取 .env 文件。
- 它们只认系统环境变量（控制面板设置）或特定的配置文件（如 nginx.conf）。
- 结论：对于这类应用，挂载 .env 文件通常无效，必须使用控制面板 Env 或直接挂载对应的 conf 文件。

3. 💡 最佳实践建议

二选一原则：针对同一组配置，不要混用两种方式。
- 方案 A（推荐用于 Web 应用）：完全使用 File Mount 挂载完整的 .env 文件。
  - 理由：保证本地开发环境与生产环境配置文件完全一致，复制粘贴即可，减少人为遗漏。
- 方案 B（推荐用于基础服务/简单变量）：完全使用 控制面板 Env 设置。
  - 理由：界面清晰，管理方便，适合变量较少的情况。
明确应用行为：查阅应用文档，确认它是优先读取文件还是优先读取环境变量。
敏感信息：如果极度敏感，考虑使用 Bind Mount 挂载服务器上权限严格控制的独立文件，避免内容出现在 Dokploy 数据库备份中。

⚠️ 第四部分：常见陷阱与故障排查

1. 权限错误 (Permission Denied)

现象：容器启动失败，日志提示无法写入文件或读取配置。
原因：多见于 Bind Mount。容器内用户 UID 与宿主机文件夹所有者不一致。
解决：
- 优先改用 Volume。
- 若必须用 Bind，在服务器执行 chown -R <UID>:<GID> /host/path。

2. 路径错误

File Mount：File Path 必须是完整路径 + 文件名（例：/app/.env），不能只是目录。
Bind Mount：Host Path 必须是绝对路径，不能用 ~ 或相对路径。

3. 修改未生效

File Mount / Env Panel：修改后必须点击 Deploy 重新创建/启动容器。
Bind Mount：文件修改通常即时生效，但应用程序可能需要重启才能重新加载配置（除非支持热重载）。

4. 数据迁移

Volume：需使用 Docker 命令或 Dokploy 备份功能迁移卷数据。
Bind Mount：直接打包宿主机对应文件夹 (tar) 传输到新服务器即可。

🏁 总结流程图

graph TD Start[开始配置存储] --> Q1{数据类型？} Q1 -- 数据库/持久化数据 --> Vol[使用 Volume<br>安全/自动管理] Q1 -- 单个配置文件 (.env) --> File[使用 File Mount<br>网页编辑/最便捷] Q1 -- 现有目录/代码热更 --> Bind[使用 Bind Mount<br>需 SSH 预建目录] File --> EnvQ{是否需要设置环境变量？} EnvQ -- 是 --> Choice{选择策略} Choice -- 推荐：保持一致性 --> UseFile[完全使用 File Mount 挂载 .env] Choice -- 备选：简单变量 --> UsePanel[完全使用控制面板 Env 设置] Choice -- ❌ 禁止 --> Mix["混用两者 (易导致冲突)"] Vol --> Deploy[点击 Deploy 部署] Bind --> Deploy UseFile --> Deploy UsePanel --> Deploy Deploy --> Done[完成]

遵循本指南，您将能够高效、安全地管理 Dokploy 中的应用数据与配置。如有具体报错，请提供日志以便进一步分析。

Dokploy 自动化部署踩坑

在使用 Dokploy 配合 CI/CD（如 GitHub Actions）进行自动化部署时，很多人会踩到两个致命的坑：

时序错乱（抢跑）：刚 git push 完代码，CI/CD 还没把镜像打包推送完，Dokploy 就已经提前开始拉取部署了，导致部署失败或拉到旧镜像。
镜像缓存（死不更新）：等镜像真正推送完，去触发 Dokploy Webhook 时，由于镜像标签都是 latest，Dokploy 直接用了本地缓存，怎么部署都是旧版本！

今天，我们就用 “Raw 模式分离” + “API 改写镜像 SHA” 的终极方案，彻底打通这条全自动流水线！

踩坑一：为什么一 Push 代码 Dokploy 就抢跑？

根本原因：如果你在 Dokploy 中选择了 Git 作为代码源，它的触发器只有 On Push，一旦侦测到代码提交它就会立刻执行。

破局思路：既然镜像已经由 CI/CD 负责打包，Dokploy 就只需要做一个“纯粹的执行器”。

👉 解决方法：

在 Dokploy 的应用设置中，不要选 Git/GitHub。

如果是单容器，数据源选 Docker。
如果是编排部署，数据源选 Raw 模式（直接粘贴你的 docker-compose.yml）。

这样 Dokploy 就彻底脱离了 Git 仓库的束缚，只会安静等待指令。

踩坑二：触发更新时，如何彻底避免 latest 镜像缓存？

很多教程只教你推完镜像后 curl 一下 Webhook，但这不够。为了实现绝对的不可变部署（Immutable Deployment），最佳实践是在 CI/CD 构建完镜像后，提取该镜像唯一的 SHA 摘要（Digest），利用 Dokploy 的 API 动态改写配置，然后再触发部署。

准备工作：获取 API 密钥与 URL

生成 API Key：登录 Dokploy 面板，点击右上角头像 -> Profile -> 找到 API/CLI 区域，生成一串 API Key。
确认 API URL：即你的 Dokploy 访问地址（例如 https://dokploy.your-domain.com）。
获取应用 ID：在 Dokploy 中点开你的应用，看浏览器地址栏，通常能找到你的 applicationId 或 composeId。

终极 CI/CD 流水线实战（以 GitHub Actions 为例）

我们需要在工作流中完成三个步骤：构建推送 -> 改写 Dokploy 配置里的 SHA -> 触发部署。

在你的 .github/workflows/deploy.yml 最后加上这段核心代码：

# 前置步骤：正常拉取代码并登录镜像库...

- name: 构建并推送 Docker 镜像，提取 SHA
 id: build-image
 run: |
 # 1. 正常打包并推送最新镜像
 docker build -t your-namespace/your-image:latest .
 docker push your-namespace/your-image:latest

 # 2. 核心操作：获取刚刚推送在云端生成的唯一 SHA256 摘要
 IMAGE_SHA=$(docker inspect --format='{{index .RepoDigests 0}}' your-namespace/your-image:latest)
 echo "IMAGE_SHA=$IMAGE_SHA" >> $GITHUB_ENV
 echo "最新镜像摘要为: $IMAGE_SHA"

- name: 调用 Dokploy API 改写镜像 SHA
 run: |
 # 3. 将带有 SHA 的完整镜像地址更新到 Dokploy 的配置中
 curl -X POST "https://dokploy.your-domain.com/api/application.update" \
 -H "Authorization: Bearer ${{ secrets.DOKPLOY_API_KEY }}" \
 -H "Content-Type: application/json" \
 -d '{
 "applicationId": "${{ secrets.DOKPLOY_APP_ID }}",
 "dockerImage": "${{ env.IMAGE_SHA }}"
 }'

- name: 调用 Dokploy API 触发真实部署
 run: |
 # 4. 配置修改完毕，正式下达部署指令
 curl -X POST "https://dokploy.your-domain.com/api/application.deploy" \
 -H "Authorization: Bearer ${{ secrets.DOKPLOY_API_KEY }}" \
 -H "Content-Type: application/json" \
 -d '{
 "applicationId": "${{ secrets.DOKPLOY_APP_ID }}"
 }'

(💡 提示：记得在 GitHub 的 Secrets 中配置好 DOKPLOY_API_KEY 和 DOKPLOY_APP_ID)

💡 进阶技巧：如果你用的是 Raw 模式 (Docker Compose) 怎么办？

在 Raw 模式下由于是直接写 YAML 文件，API 更新全文有些繁琐。最佳实践是结合环境变量：

在 Dokploy 的 Raw 配置框中这样写：

services:
 web:
 image: your-namespace/your-image@${IMAGE_SHA} # 引用环境变量

在 GitHub Actions 中，调用 Dokploy 的环境变量更新 API（/api/application.env.set 或相关路由），把新的 SHA 刷进环境变量里。最后再触发 Deploy。

总结

通过上述改造，我们完美分离了“代码构建”与“容器部署”的职责：

CI/CD 专职负责构建镜像，并产出带有唯一指纹的 SHA 摘要。
Dokploy 作为纯粹的容器执行引擎，通过 API 接收最新的 SHA 彻底绕过本地缓存。

时序绝对正确，更新绝对精准，你的全自动 CI/CD 部署流水线现在坚不可摧了！🎉

解决 Traefik 处理大文件上传时的 502 错误 (i/o timeout)

在使用 Traefik 作为反向代理时，如果遇到大文件上传导致 502 Bad Gateway 错误，且日志中出现 i/o timeout 相关信息，通常是因为 Traefik 的默认超时设置过短。

以下是具体的排查思路与解决方案。

1. 问题现象与日志分析

当上传较大文件时，请求在到达后端之前被 Traefik 截断，返回 502 错误。查看 Traefik 容器日志，关键错误信息如下：

vulcand/oxy/buffer: error when reading request body, err: i/o timeout
entryPointName=websecure middlewareName=transmaster-staging-backend-buffering@docker

原因定位：

错误并非由 maxRequestBodyBytes（请求体大小限制）引起。
根本原因是 Traefik 的 buffering 中间件在等待客户端上传数据时发生了 I/O 超时 (i/o timeout)。默认的读取超时时间对于大文件上传来说太短了。

2. 解决方案

需要修改 traefik.yml 配置文件，在对应的 entryPoints（入口点）下增加 respondingTimeouts 配置，延长读取和写入的超时时间。

修改 traefik.yml

找到你的 traefik.yml 文件（通常位于 /etc/dokploy/traefik/traefik.yml 或类似路径），在 entryPoints 部分添加或修改 transport 配置。

配置示例：

entryPoints:
 web:
 address: :80
 transport:
 respondingTimeouts:
 readTimeout: 900s  # 读取请求体超时时间（针对大文件上传，建议设大一点，如 15 分钟）
 writeTimeout: 900s  # 写入响应超时时间
 idleTimeout: 180s  # 空闲连接超时时间
 websecure:
 address: :443
 transport:
 respondingTimeouts:
 readTimeout: 900s
 writeTimeout: 900s
 idleTimeout: 180s
 http:
 tls:
 certResolver: letsencrypt

参数说明：

readTimeout: 最关键参数。决定 Traefik 等待客户端把请求体传完的时间。如果上传文件较大或网速较慢，需适当调大（例如 900s）。
writeTimeout: 决定 Traefik 等待后端服务返回响应的时间。
idleTimeout: 保持连接空闲的超时时间，通常不需要太大。

3. 应用配置

修改保存配置文件后，需要重启 Traefik 容器以使配置生效。

执行重启命令：

docker restart dokploy-traefik
// 或者根据你的容器名称调整，例如：
// docker restart <traefik_container_name>

4. 验证结果

重启完成后，再次尝试上传之前失败的大文件。

观察日志： 确认不再出现 i/o timeout 错误。
业务测试： 文件上传成功，不再返回 502 错误。

通过调整 respondingTimeouts，即可解决因网络波动或文件过大导致的 Traefik 上传超时问题。

部署相同项目的但是不同的环境（staging和production）发现冲突 — trakfik路由重名冲突问题

在 Dokploy 中，路由重名问题（Route Name Collision / Duplicate Route）是一个在部署多个应用或同一应用的多个实例时经常遇到的网络路由冲突问题。

要理解这个问题，首先需要了解 Dokploy 的底层网络架构：Dokploy 依赖 Traefik 作为其反向代理和负载均衡器。Traefik 通过读取 Docker 容器上的标签（Labels）或动态配置文件，来决定如何将外部的 HTTP/HTTPS 请求转发到正确的内部容器。

以下是关于 Dokploy 中路由重名问题的详细解释：

什么是“路由重名”？

在 Traefik 的配置体系中，每个路由规则都需要一个唯一的路由名称（Router Name）。例如，在 Docker Compose 的 labels 中，你可能会看到这样的配置：traefik.http.routers.my-app-router.rule=Host('example.com')。这里的 my-app-router 就是路由名称。如果在 Dokploy 中，有两个不同的服务或应用使用了完全相同的路由名称，Traefik 就会发生冲突。

常见的触发场景

部署同一模板的多个实例（多租户场景）： 假设你使用 Docker Compose 模板在 Dokploy 上部署了一个开源系统（如 ERPNext、WordPress 或你自己的项目）。当你想要为另一个客户部署第二套相同的系统时，如果你直接复制了 Compose 文件而没有修改里面的 Traefik 标签，两个容器都会声明自己叫 my-app-router。
误绑重复的域名： 团队成员在 Dokploy 的控制面板中，不小心为两个不同的应用程序绑定了相同的域名（在 Dokploy 的 GitHub 仓库中，Issue #3036 专门提到了缺少重复域名校验导致的 Traefik 路由崩溃问题）。
服务从其他平台迁移时的硬编码： 直接复制了原本在 Coolify 或纯 Docker 环境下的 Compose 文件，导致不同项目复用了默认的通用路由名称（如 web-router 或 frontend-router）。

路由重名会导致的后果

流量串门 / 覆盖失效： Traefik 无法区分这两个服务。通常情况下，后启动的容器可能会覆盖先启动的容器的路由规则，导致访问应用 A 的域名却打开了应用 B 的页面。
服务不可用（504 或 404 错误）： Traefik 的动态配置加载可能会因为命名冲突而报错，导致该路由规则被整体丢弃，最终访问域名时出现 504 Gateway Timeout 或 404 Not Found。
部署状态假死： Dokploy 面板显示应用已成功部署且正在运行，但外部始终无法通过域名访问。

如何解决和避免？

方法一：确保路由名称的唯一性（最核心） 如果你通过 Templates 或 Docker Compose 部署应用，必须确保 labels 里的 router 和 service 名称是全局唯一的。
- 错误写法（写死名称）：- "traefik.http.routers.web-router.rule=..."
- 正确写法（添加唯一标识/租户 ID）：- "traefik.http.routers.app1-web-router.rule=..." 或 - "traefik.http.routers.app2-web-router.rule=..."
- 或者使用环境变量：- "traefik.http.routers.${TENANT_ID}-router.rule=..."
方法二：明确指定 Traefik 网络 当出现复杂的网络配置时（例如应用同时加入了多个 Docker Network），Traefik 会不知道该把流量发往哪个网络，从而引发 504 错误。在标签中明确指定 Dokploy 的默认网络可以防范此类路由异常：- "traefik.docker.network=dokploy-network"。
方法三：使用 Dokploy 原生 Application 部署 如果你使用的是 Dokploy 的 Applications 功能（基于 Nixpacks, Dockerfile 或 Buildpacks 部署），Dokploy 底层会通过修改 Traefik 的文件系统（File Provider）来自动为你生成带有唯一哈希值的路由名称。这种模式下，只要你不绑定完全重复的域名，通常不会触发路由重名问题。

总结：Dokploy 的路由重名本质上是 Traefik 代理引擎的命名空间冲突。在编写 Compose 文件或打标签时，养成为所有 Traefik 相关的 router、service、middlewares 加上项目名前缀的习惯，就能完美避开这个问题。

参考资料

cherryservers.com
dokploy.com
frappe.io
github.com
lobehub.com
Google Search Suggestions: “dokploy” router name collision, “dokploy” route name, “dokploy” 路由冲突，“dokploy” duplicate route

dokploy 如果因为磁盘爆了而崩溃，怎么解决

# 确认磁盘状态
df -h


# 清除陈旧的系统日志
sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M

# 清理未使用的 Docker 镜像和停止的容器
docker system prune -a -f

配置S3 Destinations

以b2_buckets 为例

将 Backblaze B2 配置到 Dokploy 的 S3 存储指南

将 Backblaze B2 配置到 Dokploy 的 S3 存储中主要分为两步：首先在 Backblaze 获取凭据，然后在 Dokploy 仪表板中完成设置。

第一步：在 Backblaze B2 中获取信息

创建存储桶 (Bucket)
- 登录 Backblaze，进入 B2 Cloud Storage > Buckets。
- 创建一个新存储桶（例如命名为 dokploy-backups）。
- 注意：在存储桶列表中找到刚才创建的桶，复制其显示的 S3 Endpoint（例如 s3.us-west-002.backblazeb2.com）。
创建应用程序密钥 (Application Keys)
- 进入 App Keys 页面。
- 点击 Add a New Application Key。
- 设置名称，并确保权限设置为 Read and Write。
- 创建后，你会得到：
  - keyID（即 Dokploy 中的 Access Key）
  - applicationKey（即 Dokploy 中的 Secret Key）
- 注意：applicationKey 仅显示一次，请务必保存。

第二步：在 Dokploy 中进行配置

进入 Dokploy 面板，点击左侧菜单的 Settings (设置)。
找到 S3 Destinations 选项卡，点击 Add S3 Destination。
根据以下对应关系填写表单：

Dokploy 字段	对应 Backblaze 的信息	示例值
Name	自定义名称	Backblaze-B2
Provider		选择 Amazon Web Services （AWS）S3 ｜
Endpoint	存储桶页面的 S3 Endpoint (需带 https://)	`https://s3.us-west-002.backblazeb2.com`
Region	Endpoint 中的地区部分	`us-west-002`
Bucket	你创建的存储桶名称	`dokploy-backups`
Access Key	刚才生成的 keyID	`002123456789...`
Secret Key	刚才生成的 applicationKey	`K001abcd...`

保存并测试：填写完成后，点击 Test Connection。如果显示成功，则说明配置正确。

第三步：为数据库或应用开启备份

配置好 S3 目的地后，你还需要将其应用到具体的备份任务中：

进入你想备份的 Database (数据库) 或 Service。
点击 Backups 选项卡。
在 Select Destination 下拉菜单中选择刚才创建的 Backblaze-B2。
设置 Cron Schedule（例如 0 0 * * * 表示每天午夜备份）并启用。

** 第四步：恢复备份**

总结恢复步骤清单：

本地已经部署镜像并启动容器，对应需要恢复的卷名是 9cut8x_postgres_data。

命令行查卷(这个卷名换成实际的)：

docker ps -a --filter volume=9cut8x_postgres_data

清理现场： docker rm -f <查到的容器ID>
彻底删除旧卷： docker volume rm 9cut8x_postgres_data
执行恢复：在 Dokploy 的 Volume Backups 页面填入 9cut8x_postgres_data 并点击 Restore。
验证：恢复完成后，执行 docker volume ls 确保该卷已重新创建。
部署应用：回到 Dokploy 对应的服务界面，点击 “Deploy”（这会根据你的 docker-compose.yml 重新挂载刚才恢复好的卷）。

常见问题排查

权限错误：确保创建 Key 时勾选了对应存储桶的 “Read and Write” 权限。
Endpoint 格式：Dokploy 通常需要完整的 URL 格式，请确保包含 https://。
地区 (Region)：Backblaze 的地区代码通常就在 Endpoint URL 中（如 us-west-002），必须准确填写。

Dokploy Swarm 子节点联通性测试指南

这是一份专为 Dokploy 用户准备的 Docker Swarm 子节点（Worker Node）联通性测试教程。在搭建好 Dokploy 多节点集群后，最关键的一步是验证 管理节点（Manager） 是否能通过 Overlay 网络 正常调度并连接到 子节点（Worker） 上的容器。本教程将通过部署一个跨节点的测试应用，验证网络数据平面（Data Plane）是否畅通。

一、核心概念：为什么不能用“默认”网络？

很多教程提到“不要使用默认网络”，这通常指两点：

禁止使用 bridge 网络：这是单机网络。如果你不指定网络，Docker 默认使用 bridge，跨服务器的容器将无法互相访问。
必须使用 Overlay 网络：Swarm 模式下，只有 Overlay 网络能建立跨物理机的虚拟隧道。
Dokploy 的做法：Dokploy 已经预设了一个名为 dokploy-network 的 Overlay 网络。我们的应用必须挂载到这个网络上，才能被 Dokploy 的 Traefik 网关识别并实现跨节点转发。

二、准备工作

确保在 Dokploy 的 Servers 菜单中，子节点显示为 Ready。
（可选）为子节点添加标签：
- 在管理节点终端执行：docker node update --label-add type=worker <子节点主机名>
- 这能确保我们的测试应用准确落在子节点上。

三、编写部署文件 (Compose)

在 Dokploy 中新建一个 Compose，选择 Stack 模式，填入以下配置：

version: '3.8'

services:
 # 服务 A：强制运行在管理节点 (Manager)
 test-manager:
 image: nginxdemos/hello:plain-text
 networks:
 - dokploy-network
 deploy:
 replicas: 1
 placement:
 constraints:
 - node.role == manager

 # 服务 B：强制运行在子节点 (Worker)
 test-worker:
 image: nginxdemos/hello:plain-text
 networks:
 - dokploy-network
 deploy:
 replicas: 1
 placement:
 constraints:
 # 如果没打标签，可用 - node.role == worker
 - node.role == worker 

networks:
 # 使用 Dokploy 预设的 Overlay 网络
 dokploy-network:
 external: true

注意：上述 YAML 中的注释行已保留，但请确保在实际编辑时不要误删关键配置。

四、部署步骤

创建 Stack：在 Dokploy 项目中点击 Create Service -> Compose。
配置：
- Name: swarm-test
- Source: 直接粘贴上述 YAML 代码。
部署：点击 Deploy。
确认位置：
- 部署完成后，在 Dokploy 的容器列表里查看。
- 确认 test-manager 运行在管理节点 IP 上。
- 确认 test-worker 运行在子节点 IP 上。

五、联通性验证（手动测试）

即使两个容器都显示 “Running”，也不代表网络是通的。我们需要执行以下两项压力测试：

1. 容器间内网互访（验证 Overlay 网络）

进入管理节点上的 test-manager 容器，尝试访问子节点上的服务名：

 # 1. 在管理节点终端找到容器 ID
docker ps | grep test-manager

 # 2. 进入容器内部
docker exec -it <容器 ID> sh

 # 3. 通过服务名访问子节点的容器（Swarm 会自动做 VIP 负载均衡）
curl http://test-worker

成功标志：如果返回 Server address: 10.0.x.x 且该 IP 是子节点的内部 IP，说明 Overlay 网络跨机通信正常。

2. 外部网关转发（验证 Traefik 联通）

在 Dokploy 中为 test-worker 服务配置一个域名（Domain）：

在 test-worker 的域名设置里绑定一个测试域名。
通过浏览器访问该域名。

原理：流量会先到达 管理节点的 Traefik -> 通过 dokploy-network -> 转发到 子节点的容器。
成功标志：浏览器正常显示网页。如果出现 502 Bad Gateway，说明管理节点和子节点之间的 4789/UDP 端口被防火墙拦截了。

六、故障排查

如果测试不通，请检查各节点间防火墙是否放行了以下 Swarm 必需端口：

TCP 2377：集群管理通信。
TCP/UDP 7946：节点发现与健康检查。
UDP 4789：关键！ 数据平面 Overlay 网络（UDP 封装）。如果该端口不通，容器能启动但无法互相 ping 通。

检查指令（在任一节点查看网络详情）：

docker network inspect dokploy-network

确认子节点（Worker）的容器 IP 是否出现在 Containers 列表中。

总结

在 Dokploy 中测试子节点，核心就是利用 dokploy-network (External Overlay)。只要能通过管理节点的容器 curl 通子节点的容器名，你的集群网络就是完美的。

Dokploy + Docker Swarm 实战：为什么扩容后看不见容器？(多节点部署避坑指南)

最近在使用 Dokploy 配合 Docker Swarm 进行多节点部署时，遇到了一些非常经典的概念误区。这篇笔记旨在记录从单机迈向集群模式时，容易让人产生“自我怀疑”的几个瞬间，以及如何正确地管理你的 Swarm 集群。

01. 现象：明明扩容了，容器去哪了？

我在 Dokploy 的后台将一个应用（transfileserver）的副本数（Replicas）设置为了 2。

在主节点（Master/Manager）终端输入 docker service ls，状态看起来非常完美：

root@master:~# docker service ls
ID NAME REPLICAS IMAGE
j4pif4la2ox3 smallappforfun-test..._app 2/2 registry.../app:latest

REPLICAS 2/2 告诉我：期望跑 2 个，实际跑了 2 个。一切正常，对吧？

但是，当我习惯性地在主节点输入 docker ps 想看看这两个容器时，却发现：只有一个容器在运行！

root@master:~# docker ps | grep transfileserver
// 只有一行输出，显示其中一个容器 ID

我的第一个反应是： 部署失败了？还是 Dokploy UI 显示 bug 了？为什么丢了一个容器？

02. 原理：上帝视角 vs. 本地视角

其实，部署并没有失败。这是 Docker Swarm 最基本的运行逻辑，也是新手最容易混淆的地方。

为什么 docker ps 看不到？

docker ps 是“本地视角”：这个命令问的是当前这台物理服务器：“你的 CPU 和内存里现在跑着哪些进程？”
Swarm 调度机制：当你设置 replicas: 2 且拥有多个节点时，Swarm 调度器为了负载均衡，大概率会将其中一个容器分配给主节点，另一个分配给子节点（Worker Node）。

所以，你在主节点运行 docker ps，当然只能看到分配给主节点的那个容器。另一个容器正在子节点的肚子里跑得欢呢。

正确的查看方式：上帝视角

要确认所有副本的状态和位置，不能用 docker ps，而要用 Service 级别的命令：

docker service ps <你的服务名称>

输出结果会像这样：

ID	NAME	NODE	DESIRED STATE	CURRENT STATE
x7…	…app.1	racknerd-master	Running	Running
y9…	…app.2	worker-node-01	Running	Running

注意 NODE 这一列。你可以清晰地看到，Swarm 已经把任务分发到了不同的机器上。这证明你的负载均衡集群已经完美工作了。

03. 疑问：子节点需要安装 Dokploy 吗？

既然应用跑在子节点上，我是否需要在子节点上也跑一遍 Dokploy 的安装脚本？

答案是：绝对不需要，千万别装！

为什么？

架构逻辑：Dokploy 是“指挥官”（Brain），它只需要存在于主节点。Worker 节点只需要安装基础的 Docker Engine。主节点通过 Swarm 协议遥控子节点干活。
端口冲突：Dokploy 自带 Traefik（网关），占用 80/443 端口。如果在子节点再装一套，会导致端口冲突，破坏集群的统一路由网络。
资源浪费：子节点会被迫运行一套多余的 Postgres、Redis 和监控服务。

子节点只需要做一件事：安装 Docker，然后运行 docker swarm join ... 命令加入集群即可。

04. 关键避坑：多节点下的文件存储（Volumes）

虽然多节点部署成功了，但如果你的应用涉及到文件上传或持久化存储（比如我的文件传输服务），这里有一个巨大的隐患。

场景重现

假设你的 docker-compose.yml 是这样写的：

volumes:
 - ./uploads:/app/uploads

用户 A 上传文件，请求被分发到了 主节点 的容器。文件保存在主节点的硬盘里。
用户 A 再次刷新，请求被分发到了 子节点 的容器。
结果：子节点容器里是空的！用户发现刚传的文件“丢了”。

解决方案

在 Swarm 模式下，本地目录挂载（Bind Mounts）不再适用于需要数据共享的场景。你需要：

方案一（推荐）：对象存储 修改代码，不要把文件存本地硬盘，而是存到 AWS S3、阿里云 OSS 或自建的 MinIO 中。这是云原生应用的最佳实践。
方案二：NFS（网络文件系统） 搭建一个 NFS 服务器，让所有节点挂载同一个网络硬盘。
方案三：限制节点（临时方案） 如果是单机应用强行上 Swarm，可以通过配置 placement constraints，强制该服务只运行在主节点上，放弃多节点负载均衡，只利用 Swarm 的管理功能。

总结

信任 docker service ls：如果它显示 2/2，那就是成功的。
用对命令：查看集群状态用 docker service ps，而不是 docker ps。
保持子节点纯净：不要在 Worker 节点重复安装 Dokploy。
留意存储：多节点部署必须解决文件共享问题，否则数据会“漂移”。

希望这篇避坑指南能帮你更自信地驾驭 Dokploy 和 Docker Swarm！

Dokploy 安全建议检查与服务器加固操作指南

这张截图显示的是 Dokploy 的 安全建议检查（Security Suggestions）。它并不是让你在 Dokploy 的网页界面里填个表，而是提示你需要登录到 服务器的终端（Terminal） 去修改系统配置文件。这是一份服务器“加固”清单。要把这些红色的叉号（❌）变成绿色的勾号（✅），你需要 SSH 登录到这台服务器，依次执行以下操作。

⚠️ 警告：在操作之前，请务必确保你已经可以通过 SSH 密钥登录服务器！如果你在没有配置好密钥的情况下禁用了密码登录，你将无法进入服务器！

第一步：修复 SSH 设置 (最重要)

截图建议你禁用密码登录（Password Auth）和 PAM，只允许密钥登录。

SSH 登录服务器。
编辑 SSH 配置文件：
```
sudo nano /etc/ssh/sshd_config
```
修改以下配置项（使用键盘上下键找到这些行，修改后的样子如下）：
- 找到 PasswordAuthentication，将其改为 no：
```
PasswordAuthentication no
```
- 找到 UsePAM，建议改为 no (注意：有些系统改为 no 可能会有副作用，通常改 PasswordAuthentication 最关键，但为了满足 Dokploy 的检查，你可以改为 no)：
```
UsePAM no
```
- 确保 PubkeyAuthentication 是 yes（通常默认就是）。
保存并退出：按 Ctrl + O 回车保存，按 Ctrl + X 退出。
重启 SSH 服务使配置生效：
```
sudo systemctl restart ssh
```
操作完这一步，SSH 部分的红色叉号应该会变绿。

第二步：配置 UFW 防火墙

截图显示 UFW 已安装但未激活，且默认策略不是“拒绝”。

设置默认拒绝进入（安全基线）：
```
sudo ufw default deny incoming
```

放行必要的端口（非常重要，否则你会把自己关在外面）：

# 放行 SSH (通常是 22)
sudo ufw allow 22/tcp

# 放行 Web 服务 (HTTP/HTTPS)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 放行 Dokploy 面板端口 (默认是 3000)
sudo ufw allow 3000/tcp

启用防火墙：
```
sudo ufw enable
```
(系统会提示你这可能会断开 SSH 连接，输入 y 确认即可，只要上面 allow 22 执行了就没事)。

第三步：安装并配置 Fail2Ban

截图显示 Fail2Ban 根本没安装，建议安装并开启 SSH 攻击保护（Aggressive 模式）。

安装 Fail2Ban：

sudo apt-get update
sudo apt-get install fail2ban -y

创建配置文件（不要直接改 jail.conf，新建 jail.local）：
```
sudo nano /etc/fail2ban/jail.local
```

粘贴以下内容（开启 SSH 保护并设为激进模式）：

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
# 截图建议 SSH Mode: aggressive
mode = aggressive

保存并退出：Ctrl + O 回车，Ctrl + X。

启动 Fail2Ban 服务：

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

最后一步：验证

回到 Dokploy 网页界面，点击弹窗右上角的 Refresh (刷新) 按钮。如果操作正确，大部分或者全部的红叉 ❌ 应该都会变成绿色的 ✅。

简单总结：

改 /etc/ssh/sshd_config 禁止密码。
运行 ufw 命令开放端口并开启防火墙。
运行 apt install fail2ban 并配置它。

Dokploy 搭配 Nginx Proxy Manager 保姆级实操教程

没问题！既然你习惯了 1Panel 的操作逻辑，那么方案一：使用 Nginx Proxy Manager (NPM) 绝对是你的最佳选择。

这将是一个手把手、保姆级的实操教程，涵盖从网络配置到最终通过域名访问的全过程。

准备工作

一台安装好 Dokploy 的服务器。
一个域名（假设为 example.com）。
确保端口未被占用：确保服务器的 80 和 443 端口没有被其他程序占用（Dokploy 面板默认通常在 3000 端口，所以 80/443 通常是空闲的）。

第一步：规划 Docker 网络（关键点）

在 1Panel 里，系统帮你自动处理了网络。但在 Dokploy（以及原生 Docker）中，为了让“反向代理容器”能找到“应用容器”，它们必须在同一个 Docker 网络中。

我们先创建一个专用的网络，名字叫 proxy-net。

登录你的服务器终端（SSH）。
执行以下命令创建网络：

docker network create proxy-net

这一步做完，以后所有的应用和 NPM 都加入这个网络，它们就能通过“容器名”互相通信了。

第二步：在 Dokploy 中部署 Nginx Proxy Manager

登录 Dokploy 面板。
进入 Project（项目） -> 选择或新建一个项目（例如叫 System）。
点击 Compose -> Add Compose。
- Name: nginx-proxy-manager
- Description: 反向代理服务
在右侧的编辑器中，粘贴以下配置（注意我添加了网络配置）：

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 container_name: nginx-proxy-manager
 restart: unless-stopped
 ports:
 - '80:80'
 - '81:81'
 - '443:443'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt
 networks:
 - proxy-net

networks:
 proxy-net:
 external: true

点击 Deploy（部署）。
等待日志显示 Listening on port 81，表示启动成功。

第三步：初始化 Nginx Proxy Manager

在浏览器访问：http://你的服务器 IP:81
使用默认账号登录：
- Email: admin@example.com
- Password: changeme
登录后，系统会立即要求你修改用户名和密码，请务必修改并记住。

此时，你的“反向代理中心”已经搭建好了！

第四步：部署一个业务应用（以 Alist 为例）

现在我们来部署一个实际的应用，并尝试通过域名访问它。

回到 Dokploy 面板。
进入你的项目，点击 Compose -> Add Compose。
Name: alist
粘贴以下配置（注意看 networks 和 ports 的部分）：

version: '3.3'
services:
 alist:
 image: 'xhofe/alist:latest'
 container_name: alist-app
 restart: always
 volumes:
 - './etc/alist:/opt/alist/data'
 networks:
 - proxy-net

networks:
 proxy-net:
 external: true

点击 Deploy。

重点理解：此时，alist-app 和 nginx-proxy-manager 都在 proxy-net 这个网络里。虽然你在公网通过 IP:5244 访问不到 Alist（因为没暴露端口），但 NPM 可以通过内部网络访问到它。

第五步：域名解析 (DNS)

去你的域名服务商（阿里云、腾讯云、Cloudflare 等）：

添加一条 A 记录。
主机记录 (Name): 例如 pan (即 pan.example.com)。
记录值 (Value): 填写你 Dokploy 服务器的公网 IP。

第六步：在 NPM 中配置反向代理（最后一步！）

回到 NPM 的管理后台 (http://你的服务器 IP:81)。
点击顶部菜单 Hosts -> Proxy Hosts。
点击右上角 Add Proxy Host。

A. Details 标签页 (基本信息)

Domain Names: pan.example.com (你刚才解析的域名)
Scheme: http
Forward Hostname / IP: alist-app
- 这里最关键！填写你在第四步定义的 container_name。不要填 IP，填容器名即可。
Forward Port: 5244
- 填写 Alist 的内部端口。
Cache Assets / Block Common Exploits: 推荐勾选。

B. SSL 标签页 (HTTPS 证书)

SSL Certificate: 选择 Request a new SSL Certificate。
Force SSL: 勾选 (强制跳转 HTTPS)。
HTTP/2 Support: 推荐勾选。
Email Address: 填写你的邮箱。
I Agree to the Terms: 勾选。

点击 Save。

验证成果

现在，在浏览器输入 https://pan.example.com。

如果一切顺利，你应该能看到 Alist 的页面。
并且浏览器地址栏有一把小锁（HTTPS 已启用）。
整个过程你不需要手动去碰 Nginx 的配置文件，也不需要手动上传证书。

进阶小贴士

后续添加新应用：
- 在 Dokploy 部署新应用时，记得在 Compose 文件里加上 networks: - proxy-net。
- 记下容器名 (container_name) 和内部端口。
- 去 NPM 添加一条新的 Proxy Host 即可。
关于端口 81 的安全：
- NPM 的后台（81 端口）直接暴露在公网其实不太安全。
- 高级玩法：你可以在 NPM 里，把自己（nginx-proxy-manager 容器，端口 81）也代理一下！
- 配置一个域名如 npm.example.com -> Forward Hostname: nginx-proxy-manager -> Port: 81。
- 一旦配置成功，去云服务商防火墙把 81 端口封掉，只留 80/443，以后通过 npm.example.com 访问管理后台，更加安全且带有 HTTPS。

通过这套流程，你在 Dokploy 上就完美复刻了 1Panel 的反向代理体验，甚至在多服务器扩展性上比 1Panel 更强（因为基于标准的 Docker 网络）。

Dokploy介绍

Dokploy 是一个新兴的、开源的、基于 Web 的服务器管理和应用程序部署平台，旨在让开发者和中小型团队能够像使用 Heroku 或 Vercel 一样简便地部署和管理应用，但所有服务完全运行在您自己拥有或控制的服务器（如 VPS）上。简单来说，Dokploy 是“自托管/私有化部署的 Heroku”。

它通过一个直观的 Web 控制面板，将复杂的 Docker、Git、Webhook 和反向代理配置过程完全可视化，让您无需记忆冗长的命令行指令，就能完成应用部署、数据库创建、SSL 证书安装等一系列操作。

核心特性

基于 Docker：所有应用和服务都以 Docker 容器形式运行，保证环境的一致性和隔离性。支持上传标准的 docker-compose.yml 文件，或使用内置模板快速创建多容器应用。
可视化部署：
- Git 集成：连接 GitHub、GitLab 或 Bitbucket 仓库，实现持续部署。每次推送代码到指定分支，Dokploy 会自动拉取、构建并重新部署应用。
- Docker 镜像部署：可直接从 Docker Hub 或私有仓库拉取镜像进行部署。
- 环境变量管理：在网页界面中轻松添加、编辑和管理敏感配置信息，无需手动编辑文件。
内置服务支持：一键部署常用数据库（MySQL、PostgreSQL、MongoDB、Redis 等）、缓存服务和反向代理（Nginx），无需手动编写配置文件。
SSL 证书自动管理：集成 Let’s Encrypt，为您的应用域名自动签发和续期免费的 HTTPS 证书，仅需点击几下即可完成配置。
直观的监控与管理：
- 实时查看容器状态（运行/停止）、CPU 与内存使用情况。
- 查看实时日志流，支持在线启动、停止、重启容器。
多服务器管理：一个 Dokploy 控制面板可同时管理多个远程服务器（节点），便于在不同机器上分布和调度应用。
开源与可扩展：完全开源（采用商业源码许可证），代码透明，社区驱动，支持通过插件或模板扩展功能，便于二次开发与定制。

典型工作流程

准备一台 VPS：在 DigitalOcean、Linode、阿里云、腾讯云等服务商购买一台安装了 Ubuntu 或 Debian 的虚拟服务器。
安装 Dokploy：使用官方提供的一键安装脚本，在服务器上部署 Dokploy（其本身也是一个 Docker 容器）。
访问控制面板：通过浏览器访问服务器 IP 和指定端口，进入 Dokploy 的 Web 界面并完成初始设置。
连接 Git 账户：在面板中授权您的 GitHub、GitLab 或 Bitbucket 账号。
创建新项目：点击“部署应用”，选择目标仓库和分支。
配置部署参数：设置端口映射、环境变量、构建命令等。Dokploy 会自动生成 Dockerfile（如项目未提供），或使用您上传的 docker-compose.yml。
执行部署：点击“部署”按钮，Dokploy 会自动拉取代码、构建镜像、启动容器，并通过内置的 Traefik 或 Nginx 配置好域名访问。
持续管理：部署完成后，通过面板监控应用状态、查看日志、添加自定义域名并启用 SSL。

适合谁使用？

前端/全栈开发者：希望快速部署 Next.js、Nuxt.js、React、Vue 或 Node.js 等项目，却不愿花时间处理服务器运维。
初创团队和小公司：需要成本可控、易于维护的部署方案，同时避免被 Heroku、Railway 等 PaaS 平台绑定或高额费用困扰。
注重数据隐私的个人或组织：因合规性、安全或数据主权要求，必须将应用部署在自有基础设施上，但仍希望享受现代云平台的便捷体验。
Docker 初学者：想体验容器化部署的优势，但对命令行、网络配置、存储卷等概念感到困难。

优点与缺点

优点：

成本效益高：仅需支付 VPS 费用，Dokploy 本身免费，长期使用远低于按需付费的云 PaaS。
完全自主可控：数据和基础设施由您掌控，可自由定制服务器配置和安全策略。
开发者体验友好：极大降低了 Docker 和 CI/CD 的入门门槛，部署流程流畅直观。
活跃社区：项目更新频繁，功能持续迭代，社区支持逐步增强。

缺点：

依赖自有服务器：您需具备基本的服务器运维能力（如 SSH 登录、防火墙设置），并自行负责安全更新、备份和底层维护。
非企业级架构：相比 Kubernetes 或商业面板（如 Plesk、cPanel），在集群管理、高可用、自动伸缩等方面功能尚不完善。
新兴项目：作为较新的开源工具，其长期稳定性、大规模生产环境验证和生态成熟度仍需时间检验。

与其他工具的对比

工具	类型	核心特点	适合场景
Dokploy	自托管 PaaS 面板	开源、可视化、Git 集成、轻量级、基于 Docker	个人开发者、小团队自托管应用
Heroku / Vercel	云 PaaS	极致简化、全托管、生态丰富、按需付费	追求效率、不愿管理服务器的用户
Portainer	Docker 管理面板	通用型容器、镜像、网络、卷管理	需要精细管理 Docker 环境的管理员
Coolify / CapRover	自托管 PaaS 面板	与 Dokploy 定位高度重叠，功能相似	可作为 Dokploy 的替代选择进行对比
Kubernetes	容器编排平台	企业级、高扩展性、功能强大但复杂	大型系统、微服务架构、需要弹性伸缩的场景

如何开始？

访问 Dokploy 官方网站获取最新文档和安装指南：https://dokploy.com
查看开源代码和社区贡献：https://github.com/Dokploy/dokploy

总结

Dokploy 填补了“完全托管的云服务”与“手动服务器运维”之间的空白，让开发者能专注于编写代码，而将部署与运维的复杂性封装在一个美观、易用的界面之后。对于追求自主权、控制权和成本效益的开发者而言，Dokploy 是一个极具吸引力的现代部署解决方案。如果您正在寻找一种比手动操作更高效、比大型云平台更自主的部署方式，Dokploy 绝对值得一试。

Coolify

Sat, 21 Feb 2026 17:19:21 +0800

一、产品核心定位 (Product Positioning)

Coolify 是一款开源、可自托管的 PaaS（平台即服务）系统。如果用一句话来向投资人或技术团队推销它：“它是架设在你自有服务器上的 Vercel、Heroku 或 Render，让你用云主机的底层成本，享受顶级云厂商的 DevOps 自动化体验。”

核心商业逻辑：解耦“软件体验”与“硬件基础设施”。它将底层服务器的计算资源池化，在上面套了一层极简的 UI 和自动化脚本。

二、核心功能矩阵 (Core Features)

Coolify 的功能设计紧紧围绕“研发交付生命周期”展开，极大地压缩了 Time-to-Market（上市时间）：

1. 自动化应用部署 (GitOps & CI/CD)

代码即部署：深度集成 GitHub, GitLab, Bitbucket, Gitea。开发人员提交代码（git push）后，Coolify 自动拉取、构建并部署。
PR 预览环境：当提交 Pull Request 时，可自动生成一个带独立域名的临时预览环境，PR 合并后自动销毁，极大方便 QA 和产品验收。
多栈支持（Zero-Config）：无论是 Node.js, Python, Go, Rust 还是 PHP，通常不需要手写 Dockerfile，系统会自动识别语言并打包构建。

2. 数据库与存储管理 (Database as a Service)

一键拉起：支持一键部署 PostgreSQL, MySQL, MariaDB, MongoDB, Redis 等主流数据库。
自动备份：内置备份策略，可配置 Cron 任务，将数据库自动备份至本地或兼容 S3 的云存储（如 AWS S3, Cloudflare R2），解决数据灾备问题。

3. 服务模板市场 (1-Click Services)

内置应用商店：内置了上百种热门开源软件模板（如 WordPress, Ghost, Supabase, MinIO, Metabase 等）。产品或运营团队可绕过开发，一键部署所需工具。

4. 基础设施与网络自动化 (Infra & Networking)

多机管理 (BYOS)：支持“自带服务器”。可以在一台主控机上，通过 SSH 挂载管理位于阿里云、AWS 甚至家里的多台不同节点的服务器。
智能网关与 SSL：自动配置反向代理（Traefik 或 Caddy），全自动申请和续期 Let’s Encrypt 的 HTTPS 证书，无需手动改 Nginx 配置。

三、底层技术架构 (Technical Underpinnings)

理解 Coolify 的底层，有助于评估其技术稳定性和扩展性边界：

容器化核心 (Docker-based)：Coolify 的一切皆容器。它不依赖 Kubernetes 的复杂编排，而是利用底层的 Docker Engine 运行应用，这保证了极低的资源消耗（主控节点 2C2G 即可运行）。
构建引擎 (Nixpacks)：采用目前非常先进的 Nixpacks（由 Railway 团队开源）替代传统的 Dockerfile 构建。它能更智能、更快速地解析代码库，生成极度优化的容器镜像。
控制面与数据面分离：
- Control Plane（控制面）：Coolify 面板本身，负责下发指令。
- Worker Nodes（工作节点）：实际跑应用的服务器。即使 Coolify 面板宕机，由于底层是通过 Docker 运行，部署好的业务应用不受影响，继续提供服务。

四、竞品对比与市场分析 (Competitive Landscape)

比较维度	Coolify (自托管)	Vercel / Netlify	Heroku / Render	Kubernetes (K8s)
成本	极低（仅需支付廉价 VPS 费用）	早期免费，后期扩展成本极高	中等偏高	极高（需专业运维团队和冗余机器）
学习门槛	低（图形化界面）	极低	较低	极高
扩展性	中（单机伸缩，暂无自动水平扩容）	高（Serverless，全球边缘节点）	高	极高
数据隐私	极高（数据全在自己服务器）	低（托管在第三方）	低（托管在第三方）	极高（可私有化部署）
适用场景	独立开发、初创公司、内部系统	纯前端、重 SEO 网站、轻量 API	快速验证商业模式的 MVP	大型企业、高并发、微服务架构

五、产品经理的落地实施建议 (Actionable Strategy)

如果你打算在团队中引入 Coolify，我建议采取以下策略以平衡资源与风险：

切入场景：先内部后外部
- 不要一开始就把核心交易系统放上去。先用 Coolify 部署内部管理后台、测试环境（Staging）、数据分析工具（Metabase）或官网博客。验证团队对其稳定性的掌握度。
架构部署：隔离主控与生产
- 买一台轻量级 VPS 作为“主控节点”专门跑 Coolify 面板。
- 将性能更好的服务器作为“工作节点”通过 SSH 挂载上去跑实际的业务和数据库。这样即便折腾面板，也不会影响线上业务。
风险控制：关注 OS 层面运维
- 劣势预警：Coolify 帮你解决了应用层的运维，但不解决 Linux 操作系统底层的运维。服务器的内核升级、防火墙（UFW/iptables）配置、防 DDoS 攻击依然需要你处理。
- 强推备份：第一时间配置 S3 数据库自动备份策略。只要数据在，无论面板或服务器出什么问题，都能在 30 分钟内用一台新机器拉起所有服务。

总结：Coolify 是一个典型的“用技术杠杆对抗资本”的优秀产品。它非常适合那些需要快速迭代、又希望把控基础设施成本的小型敏捷团队。

PostgreSQL

Tue, 30 Dec 2025 12:27:59 +0800

安装

PG数据库安装

Docker (最快方式):

docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d -p 5432:5432 postgres

Linux (Ubuntu/Debian):

sudo apt update
sudo apt install postgresql postgresql-contrib

Windows/Mac: 推荐直接去官网下载 PostgreSQL Installer。

相关工具的安装

navicat for PG lite

连接 (使用命令行 psql)

PostgreSQL 安装后会创建一个默认的超级用户，叫 postgres。

在 Linux/Mac 终端中登录：

# 切换到 postgres 用户并启动 psql 工具
sudo -u postgres psql

登录成功后： 你会看到提示符变成 postgres=#，这表示你已经是超级管理员了。

基础操作实战 (CRUD)

以下命令请在 psql 命令行或图形化客户端的 SQL 编辑器中执行。**注意：SQL 语句末尾必须加分号 ;**。

数据库操作

-- 创建一个新数据库
CREATE DATABASE my_app;

-- 切换/连接到这个数据库 (psql 专用指令，非 SQL)
\c my_app
-- 提示符会变为 my_app=#

创建表 (Create Table)

PostgreSQL 的数据类型非常丰富。

SERIAL: 相当于 MySQL 的 AUTO_INCREMENT（自增主键）。
TEXT: PG 中推荐使用 TEXT 代替 VARCHAR，性能几乎一样但没有长度限制。

CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 username TEXT NOT NULL,
 email TEXT UNIQUE NOT NULL,
 age INT,
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

插入数据 (Insert)

-- 插入单条数据
INSERT INTO users (username, email, age)
VALUES ('zhang_san', 'zhang@example.com', 25);

-- 插入多条数据
INSERT INTO users (username, email, age)
VALUES
('li_si', 'li@example.com', 30),
('wang_wu', 'wang@example.com', 22);

查询数据 (Select)

-- 查询所有
SELECT * FROM users;

-- 条件查询
SELECT username, email FROM users WHERE age > 24;

-- 排序与限制
SELECT * FROM users ORDER BY age DESC LIMIT 1;

更新与删除 (Update & Delete)

-- 更新
UPDATE users SET age = 26 WHERE username = 'zhang_san';

-- 删除
DELETE FROM users WHERE age < 20;

进阶功能 (PG 的杀手锏)

这是大家选择 PG 而不是 MySQL 的主要原因：对 JSON 的原生支持。你可以把它当成 MongoDB 来用。

创建包含 JSON 的表

假设我们要存用户的“配置信息”，每个人的配置都不一样，且经常变动。

CREATE TABLE user_configs (
 user_id INT,
 config JSONB -- JSONB 是二进制存储的 JSON，查询速度极快
);

插入 JSON 数据

INSERT INTO user_configs (user_id, config)
VALUES (1, '{"theme": "dark", "notifications": true, "tags": ["admin", "editor"]}');

查询 JSON 内部的字段

PG 提供了特殊的运算符 -> 和 ->>。

-- 查询 theme 是 dark 的用户
SELECT * FROM user_configs WHERE config->>'theme' = 'dark';

-- 甚至可以查询 JSON 数组中是否包含某个值
SELECT * FROM user_configs WHERE config->'tags' ? 'admin';

第五步：常用的 psql 快捷指令 (作弊条)

如果你使用命令行工具 psql，这些指令必须背下来（注意这些指令前面是反斜杠 \，且不需要分号）：

指令	作用	对应 MySQL
`\l`	列出所有数据库	`SHOW DATABASES;`
`\c dbname`	切换到指定数据库	`USE dbname;`
`\dt`	列出当前库下的所有表	`SHOW TABLES;`
`\d tablename`	查看表结构详细信息	`DESC tablename;`
`\q`	退出 psql	`EXIT;`
`\timing`	开启/关闭查询计时	(无)

概念

知识点

PostgreSQL（常被简称为 Postgres 或 PG）是一个功能非常强大的开源数据库。对于刚接触它的人来说，最主要的门槛在于它的架构概念和命令行工具与 MySQL 略有不同。

这是一个从 0 到 1 的详细上手教程。

在使用之前，需要理解 PG 的层级结构，这比 MySQL 多了一层：

MySQL: 实例 (Instance) -> 数据库 (Database/Schema) -> 表 (Table)
PostgreSQL: 实例 (Instance) -> 数据库 (Database) -> 模式 (Schema) -> 表 (Table)
注：默认情况下，一切都会放在名为 public 的模式下，所以初学者可以暂时忽略“模式”这一层，当作它不存在。

redis

Fri, 17 Oct 2025 11:26:56 +0800

# Redis 常用命令总结（适用于 apt install redis/redis-server 安装的场景，包括容器内）

```bash
# 1. 最简单直接启动（前台运行，用于测试）
redis-server

# 2. 使用配置文件后台启动（推荐方式）
redis-server /etc/redis/redis.conf

# 3. 带常用参数直接启动（不依赖配置文件）
redis-server --port 6379 --daemonize yes --protected-mode no

# 4. 检查 Redis 是否正常运行
redis-cli ping # 返回 PONG 表示成功
redis-cli -p 6379 ping

# 5. 优雅停止 Redis（强烈推荐，会自动保存数据）
redis-cli shutdown # 默认执行 SAVE
redis-cli -p 6379 shutdown

# 6. 不保存数据直接停止
redis-cli shutdown nosave

# 7. 强制杀死进程（不推荐，可能丢数据）
kill -9 $(pidof redis-server)
pkill -9 redis-server

# 8. 重启 Redis
redis-cli shutdown && redis-server /etc/redis/redis.conf

# 9. 使用 service 管理（你在容器里通过 apt 安装后直接可用！）
service redis-server start # 启动
service redis-server stop # 停止
service redis-server restart # 重启
service redis-server status # 查看状态

# 10. 等价的更短写法（很多系统都支持）
service redis start
service redis stop
service redis restart
service redis status

# 11. 直接调用 init 脚本（永远有效）
/etc/init.d/redis-server start
/etc/init.d/redis-server stop
/etc/init.d/redis-server restart
/etc/init.d/redis-server status

# 12. 查看进程
ps aux | grep redis
pgrep -fl redis

什么是 Redis？

Redis (Remote Dictionary Server) 是一个开源的、使用 C 语言编写的、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。

它通常被称为“数据结构服务器”，因为值（value）可以是字符串 (String)、哈希 (Hash)、列表 (List)、集合 (Set) 和有序集合 (Sorted Set) 等类型。

Redis 的主要特点：

速度快： 数据存储在内存中，读写速度非常快。
数据类型丰富： 支持多种复杂的数据结构。
持久化： 可以将内存中的数据保存到磁盘中，重启时可以再次加载进行使用。
原子性： Redis 的所有操作都是原子性的，要么执行成功，要么执行失败，不会出现中间状态。
丰富的特性： 支持发布/订阅、事务、Lua 脚本等功能。

常见应用场景：

缓存： 这是 Redis 最常见的用途，用于缓存数据库查询结果、网页、或任何可以被缓存的数据，以减轻数据库压力。
计数器： 利用 Redis 原子性的 INCR 命令可以轻松实现高并发的计数功能，例如文章阅读量、点赞数。
会话存储： 存储用户的会话信息（Session），实现分布式系统的会话共享。
排行榜： 使用有序集合（Sorted Set）可以轻松实现实时更新的排行榜。
消息队列： 使用列表（List）的 LPUSH 和 RPOP 命令可以实现简单的消息队列。

第一步：安装 Redis

你可以通过以下几种方式安装 Redis：

1. 在 Linux (Ubuntu/Debian) 上安装

使用包管理器是最简单的方式：

sudo apt update
sudo apt install redis-server

安装完成后，Redis 服务会自动启动。你可以使用以下命令检查服务状态：

sudo systemctl status redis-server

使用 Docker 安装 (推荐，跨平台)

如果你安装了 Docker，这是最简单且最干净的安装方式，适用于任何操作系统。

docker run --name my-redis -p 6379:6379 -d redis

这个命令会从 Docker Hub 下载最新的 Redis 镜像，并在后台运行一个名为 my-redis 的容器，将容器的 6379 端口映射到你主机的 6379 端口。

如果你在一个docker内开发，另一个docker容器安装redis

本地mac上_运行一个redis容器_然后想要在另一个容器中使用这个redis怎么做

第二步：连接到 Redis

安装并启动 Redis 后，你可以使用 redis-cli (Redis Command Line Interface) 连接到它。

如果你是直接在系统上安装的 Redis，直接在终端输入：

redis-cli

如果你是通过 Docker 安装的，你需要进入到容器内部：

docker exec -it my-redis redis-cli

连接成功后，你会看到类似下面的提示符：

127.0.0.1:6379>

现在，你可以开始输入 Redis 命令了。

测试连接：

输入 PING 命令，如果服务器正常运行，它会返回 PONG。

127.0.0.1:6379> PING
PONG

如果你的redis是安装在另外一个容器，使用如下

# 1. 进入你的应用容器
docker exec -it <你的应用容器名> bash # 或者 sh

# 2. 在容器内部，更新包列表并安装
root@<container-id>:/# apt-get update
root@<container-id>:/# apt-get install redis-tools -y

# 3. 现在你可以使用了
root@<container-id>:/# redis-cli -h my-redis
my-redis:6379> PING
PONG

第三步：学习基本命令和数据结构

Redis 是一个 Key-Value 数据库。每个 Key 都有一个与之关联的 Value。下面是 Redis 最核心的五种数据结构及其常用命令。

字符串 (String)

这是最基本的数据类型，一个 key 对应一个 value。

SET key value: 设置一个键值对。

127.0.0.1:6379> SET username "gemini"
OK

GET key: 获取一个键的值。
```
127.0.0.1:6379> GET username
"gemini"
```

DEL key: 删除一个键。

127.0.0.1:6379> DEL username
(integer) 1

INCR key: 将 key 中储存的数字值增一（如果 key 不存在，则初始化为 0 再执行 INCR 操作）。
```
127.0.0.1:6379> SET page_views 100
OK
127.0.0.1:6379> INCR page_views
(integer) 101
```

2. 哈希 (Hash)

Hash 是一个 string 类型的 field 和 value 的映射表，它非常适合用于存储对象。

HSET key field value: 将哈希表 key 中的字段 field 的值设为 value。
```
127.0.0.1:6379> HSET user:1 name "Alice" age 25
(integer) 2
```
HGET key field: 获取哈希表 key 中给定字段 field 的值。
```
127.0.0.1:6379> HGET user:1 name
"Alice"
```

HGETALL key: 获取在哈希表中指定 key 的所有字段和值。

127.0.0.1:6379> HGETALL user:1
1) "name"
2) "Alice"
3) "age"
4) "25"

HDEL key field: 删除哈希表 key 中的一个或多个指定字段。
```
127.0.0.1:6379> HDEL user:1 age
(integer) 1
```

3. 列表 (List)

List 是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

LPUSH key element [element ...]: 将一个或多个值插入到列表头部。
```
127.0.0.1:6379> LPUSH tasks "task1" "task2"
(integer) 2
```
RPUSH key element [element ...]: 将一个或多个值插入到列表尾部。
```
127.0.0.1:6379> RPUSH tasks "task3"
(integer) 3
```
LRANGE key start stop: 获取列表指定范围内的元素。(0 是第一个元素, -1 是最后一个元素)。
```
127.0.0.1:6379> LRANGE tasks 0 -1
1) "task2"
2) "task1"
3) "task3"
```
LPOP key: 移出并获取列表的第一个元素。
```
127.0.0.1:6379> LPOP tasks
"task2"
```
RPOP key: 移出并获取列表的最后一个元素。
```
127.0.0.1:6379> RPOP tasks
"task3"
```

4. 集合 (Set)

Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

SADD key member [member ...]: 向集合添加一个或多个成员。
```
127.0.0.1:6379> SADD tags "database" "nosql" "redis"
(integer) 3
```

SMEMBERS key: 返回集合中的所有成员。

127.0.0.1:6379> SMEMBERS tags
1) "redis"
2) "nosql"
3) "database"

SISMEMBER key member: 判断 member 元素是否是集合 key 的成员。

127.0.0.1:6379> SISMEMBER tags "redis"
(integer) 1
127.0.0.1:6379> SISMEMBER tags "mysql"
(integer) 0

SREM key member [member ...]: 移除集合中一个或多个成员。
```
127.0.0.1:6379> SREM tags "nosql"
(integer) 1
```

5. 有序集合 (Sorted Set / ZSET)

和 Set 一样，Sorted Set 也是 string 类型元素的集合，且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数（score）。Redis 正是通过分数来为集合中的成员进行从小到大的排序。

ZADD key score member [score member ...]: 向有序集合添加一个或多个成员，或者更新已存在成员的分数。
```
127.0.0.1:6379> ZADD leaderboard 100 "player1" 250 "player2" 50 "player3"
(integer) 3
```
ZRANGE key start stop [WITHSCORES]: 通过索引区间返回有序集合成指定区间内的成员（按分数从小到大）。
```
127.0.0.1:6379> ZRANGE leaderboard 0 -1 WITHSCORES
1) "player3"
2) "50"
3) "player1"
4) "100"
5) "player2"
6) "250"
```
ZREVRANGE key start stop [WITHSCORES]: 返回有序集中指定区间内的成员，通过索引，分数从高到低。
```
127.0.0.1:6379> ZREVRANGE leaderboard 0 1 WITHSCORES
1) "player2"
2) "250"
3) "player1"
4) "100"
```
ZREM key member [member ...]: 移除有序集合中的一个或多个成员。
```
127.0.0.1:6379> ZREM leaderboard "player3"
(integer) 1
```

第四步：一些通用的重要命令

KEYS pattern: 查找所有符合给定模式的 key。注意： 在生产环境中要慎用，因为它会遍历所有的键，可能会阻塞服务器。
```
127.0.0.1:6379> KEYS *
1) "tasks"
2) "user:1"
3) "page_views"
...
```
EXPIRE key seconds: 为给定的 key 设置过期时间，以秒计。当 key 过期后，它会被自动删除。这对于实现缓存非常有用。
```
127.0.0.1:6379> SET cache_data "some important data"
OK
127.0.0.1:6379> EXPIRE cache_data 60 // 60秒后过期
(integer) 1
```
TTL key: 以秒为单位，返回给定 key 的剩余生存时间 (Time To Live)。
```
127.0.0.1:6379> TTL cache_data
(integer) 55 // (还剩55秒)
```
FLUSHDB: 删除当前数据库里的所有数据。极度危险，请谨慎使用！
FLUSHALL: 删除所有数据库里的所有数据。极度危险，请谨慎使用！

第五步：在你的代码中使用 Redis

redis-cli 是一个很好的学习和调试工具，但在实际应用中，你需要在你的编程语言中通过 Redis 客户端库来连接和操作 Redis。

几乎所有主流语言都有成熟的 Redis 客户端库。例如：

Python: redis-py
Java: Jedis, Lettuce
Node.js: node-redis, ioredis
Go: go-redis
PHP: phpredis

Python 示例 (redis-py)

安装库:
```
pip install redis
```

连接和使用:

import redis

# 连接到本地 Redis 服务
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

# 使用 String
r.set('foo', 'bar')
print(r.get('foo')) # 输出: bar

# 使用 Hash
r.hset('user-session:123', mapping={
 'name': 'John',
 'surname': 'Smith',
 'company': 'Redis',
 'age': 29
})
print(r.hgetall('user-session:123'))

总结和后续学习

恭喜你！你已经完成了 Redis 的入门。你现在应该知道如何安装、连接 Redis，并使用其核心数据结构进行基本操作。

下一步可以学习：

Redis 持久化： 了解 RDB 和 AOF 两种持久化方式的区别和配置。
Redis 事务： 学习 MULTI 和 EXEC 命令来执行一组原子操作。
发布/订阅 (Pub/Sub)： 探索 Redis 的消息发布和订阅功能。
Redis 安全： 学习如何为 Redis 设置密码和配置安全的网络访问。
Redis 集群： 了解主从复制 (Replication)、哨兵 (Sentinel) 和集群 (Cluster) 模式以实现高可用和扩展性。

一些操作

Redis未授权访问漏洞处理

漏洞描述：Redis 未授权访问漏洞
Redis 未授权访问漏洞是一个非常严重的安全问题，它通常是因为 Redis 服务器直接暴露在公网或内网中，并且**没有配置密码认证**导致的。攻击者可以利用这个漏洞读取、修改甚至删除数据，更严重的情况下，可以利用 Redis 的一些特性（如写入 `authorized_keys` 或计划任务文件）来获取服务器的控制权。

以下是处理和防御 Redis 未授权访问漏洞的主要步骤和措施：

### 1\. 启用密码认证（最重要）

在 Redis 配置文件中设置一个**强密码**，启用认证功能。

 * **修改配置文件：** 找到 `redis.conf` 文件（通常在 `/etc/redis/` 或 `/etc/redis/redis.conf`）。
 * **设置密码：** 找到或添加 `requirepass` 这一行，并设置一个复杂的密码。
 ```conf
 requirepass yourStrongPasswordHere
 ```
 *记得替换 `yourStrongPasswordHere` 为你设置的实际密码。*
 * **重启 Redis：** 更改配置后，需要重启 Redis 服务使其生效。
 ```bash
 # 例如：
 sudo systemctl restart redis
 # 或者
 sudo service redis-server restart
 ```
 * **验证：** 使用 `redis-cli` 连接后，尝试执行命令，会提示需要认证。
 ```bash
 redis-cli
 > PING
 (error) NOAUTH Authentication required.
 > AUTH yourStrongPasswordHere
 OK
 > PING
 PONG
 ```

### 2\. 限制网络访问（网络隔离）

Redis 本身的设计是运行在受信任的环境中，因此不应该直接暴露给公网。

 * **绑定本地或私有 IP：** 仅允许 Redis 监听应用的服务器 IP 或本地回环地址（`127.0.0.1`）。在 `redis.conf` 中修改 `bind` 选项：
 * **仅允许本地访问：**
 ```conf
 bind 127.0.0.1
 ```
 * **允许特定内网 IP 访问：** 绑定内网 IP 地址。
 ```conf
 bind 127.0.0.1 192.168.1.100 # 替换为你的应用服务器IP
 ```
 * **配置防火墙：** 使用防火墙（如 `iptables`, `ufw`, 安全组等）限制对 Redis 端口（默认是 6379）的访问，**只允许**信任的应用服务器 IP 地址连接。
 * **网络分段：** 将 Redis 服务器放在一个独立的、只有应用服务器能访问的私有网络段中。

### 3\. 启用保护模式（Protected Mode）

Redis 3.2.0 及更高版本引入了保护模式（Protected Mode）。

 * **检查配置：** 在 `redis.conf` 中确保 `protected-mode` 设置为 `yes`。
 ```conf
 protected-mode yes
 ```
 *在默认配置下，如果 Redis 没有设置密码且绑定了非本地回环地址，保护模式会自动开启，阻止外部连接，仅响应本地回环地址（`127.0.0.1`）的请求。*

### 4\. 禁用或重命名危险命令

为了防止攻击者利用 Redis 的配置命令进行恶意操作（如写入 `authorized_keys`），可以考虑禁用或重命名一些高风险命令。

 * **禁用或重命名 `CONFIG` 命令：** 在 `redis.conf` 中添加：
 ```conf
 # 禁用 CONFIG 命令
 rename-command CONFIG ""
 # 或者重命名（推荐，防止应用端需要用到）
 rename-command CONFIG aRandomStringForConfig
 ```
 * 其他高危命令如 `FLUSHALL`、`FLUSHDB`、`SAVE`、`BGSAVE` 也可以根据需要进行限制。

### 5\. 使用低权限用户运行 Redis

不要使用 `root` 用户运行 Redis 服务。创建一个专门的低权限用户来运行 Redis 进程，即使被攻击者攻破，也能限制其在系统上的权限。

### 总结加固：

1. **设置强密码（`requirepass`）。**
2. **限制网络访问（`bind` 和防火墙）。**
3. **确保 `protected-mode yes`。**
4. **禁用或重命名高危命令（`CONFIG`）。**
5. **使用低权限用户运行。**

本地mac上_运行一个redis容器_然后想要在另一个容器中使用这个redis怎么做

在 Mac 本地上，要让一个容器（应用容器）连接到另一个容器（Redis 容器），最推荐和最现代的方法是使用自定义的 Docker 网络。

这能确保容器之间可以通过一个稳定且易于记的主机名（即你的 Redis 容器名）进行通信，而不需要关心动态变化的 IP 地址。

这里是详细的步骤，分为两种主要方法：

方法一：使用 Docker CLI 命令（推荐）

这是最基础和最清晰的方法，分为三步：

1. 创建一个自定义的 Docker 网络

首先，创建一个新的“桥接”网络。所有需要相互通信的容器都应该连接到这个网络。

docker network create my-app-network

my-app-network 是你给这个网络起的名字，可以自定义。

2. 启动 Redis 容器并连接到该网络

在运行 Redis 容器时，使用 --network 参数指定它加入你刚创建的网络。同时，使用 --name 给它一个固定的名字（例如 my-redis），这个名字将作为它在网络内部的主机名。

docker run -d \
 --name my-redis \
 --network my-app-network \
 redis

-d：在后台运行。
--name my-redis：将容器命名为 my-redis。
--network my-app-network：将其连接到 my-app-network。
注意：我在这里没有使用 -p 6379:6379。因为你的应用容器在同一个网络中，它可以直接通过 6379 端口访问 Redis。只有当你需要从 Mac 主机（例如通过 redis-cli 或桌面 GUI）访问这个 Redis 时，才需要添加 -p 6379:6379 来将端口暴露给主机。

3. 启动你的应用容器并连接到同一网络

现在，启动你的第二个容器（例如一个 Node.js、Python 或 Java 应用），并同样将它连接到 my-app-network。

docker run -it \
 --network my-app-network \
 <你的应用镜像名>

4. 在应用中连接 Redis

在你的应用代码中，连接 Redis 的主机地址不再是 localhost 或 127.0.0.1，而是你在第二步中为 Redis 容器设置的名字：my-redis。

Redis 连接字符串示例：redis://my-redis:6379

Docker 会自动将 my-redis 这个主机名解析为 Redis 容器在 my-app-network 网络中的内部 IP 地址。

方法二：使用 Docker Compose（更简单的多容器管理）

如果你需要同时管理 Redis 和你的应用两个（或更多）容器，使用 docker-compose 是一个更简单、更可维护的方法。它会自动为你创建和管理网络。

在你的项目根目录创建一个 docker-compose.yml 文件。

在该文件中定义你的两个服务（app 和 redis）：

version: '3.8' # 使用一个较新的版本

services:
 # 你的应用程序服务
 app:
 build: .  # 假设你的 Dockerfile 在当前目录
 # 或者使用 image: <你的应用镜像名>
 ports:
 - "8080:80" # 举例：将你应用的80端口映射到主机的8080
 environment:
 # 关键：在这里注入 Redis 的主机名
 - REDIS_HOST=my-redis
 - REDIS_PORT=6379
 # 确保你的应用在 redis 启动后再启动
 depends_on:
 - my-redis

 # 你的 Redis 服务
 my-redis: # 服务的名字
 image: redis
 # 你可以保留这个名字，也可以不写
 container_name: my-redis-container
 # 如果需要从主机访问，取消下面这行的注释
 # ports:
 # - "6379:6379"

# Docker Compose 会自动创建一个默认网络
# 并将 app 和 my-redis 两个服务都加入其中

在 docker-compose.yml 文件所在的目录中，运行以下命令：
```
docker-compose up -d
```

Docker Compose 会自动完成所有操作：

创建一个名为 项目目录名_default 的网络。
启动名为 my-redis 的 Redis 服务。
启动你的 app 服务。
在 app 容器内部，可以直接使用主机名 my-redis（即 services: 下定义的服务名）来连接到 Redis。

补充：连接到 Mac 主机上的 Redis

如果你的意思是 Redis 没有运行在容器里，而是直接安装在你的 Mac 电脑上，而你想从一个 Docker 容器里去连接它，那么情况有所不同。

在这种情况下，你不能使用 localhost（因为 localhost 在容器内部指的是容器自己）。你需要使用一个特殊的 DNS 名称：host.docker.internal。

连接地址：host.docker.internal:6379

host.docker.internal 是 Docker for Mac 提供的一个特殊地址，它会解析为你 Mac 主机的 IP 地址。

Server Probe

Thu, 25 Sep 2025 11:52:44 +0800

这是一种在IT运维和网站管理中非常常见的工具，对于了解和维护服务器的健康状态至关重要。

一、什么是服务器探针？

服务器探针，可以理解为安装在服务器上的一个“眼睛”或“健康监测器”。它本质上是一个软件程序或脚本，部署在你的服务器上，用于实时地、自动化地收集服务器的各种状态信息和性能数据。

这些探针收集到的数据，通常会以一个直观的、可视化的网页界面呈现出来，让服务器管理员（即使是不懂复杂命令行的用户）也能一目了然地了解服务器的当前运行状况。

你可以把它想象成汽车的仪表盘。仪表盘显示了车速、油量、发动机转速、水温等关键信息，让你知道汽车是否在正常运行。服务器探针就扮演着同样的角色，只不过它监测的是服务器的CPU、内存、硬盘、网络等核心资源。

二、为什么需要服务器探针？

如果没有探针，管理员想要了解服务器状态，就必须登录到服务器后台，手动敲击各种Linux或Windows命令（如 top, free, df, netstat 等）来查看零散的信息。这个过程非常繁琐、低效，而且不直观。

服务器探针解决了以下几个核心痛点：

数据可视化与集中管理：将复杂、抽象的命令行数据转换成图表、百分比等易于理解的图形界面，方便快速诊断问题。如果你有多台服务器，探针可以将它们的状态集中到一个面板上进行监控。
实时监控与性能分析：7x24小时不间断地监控服务器的各项指标。通过观察数据的历史趋势，可以分析服务器的性能瓶颈，例如，是在每天的某个固定时间段CPU负载过高，还是内存占用持续不下。
故障预警与快速定位：可以设置阈值报警。例如，当CPU使用率连续5分钟超过90%时，或者当硬盘空间低于10%时，探针可以通过邮件、短信或即时通讯工具（如钉钉、Telegram）发送警报。这使得管理员能在问题恶化、影响业务之前就介入处理。
降低技术门槛：让不熟悉服务器命令的网站开发者或初级运维人员也能轻松掌握服务器的运行状态，进行一些基础的判断。

三、服务器探针主要监测哪些核心指标？

一个功能完善的服务器探针通常会监测以下几类关键数据：

1. 系统核心资源 (Hardware & OS)

CPU 使用率 (CPU Usage)：显示当前CPU的负载情况，包括单核和多核的使用率、用户使用、系统使用、空闲比例等。CPU负载过高是导致服务器响应缓慢的最常见原因。
内存使用情况 (Memory Usage)：显示物理内存（RAM）和交换内存（Swap）的总量、已用量、剩余量。内存耗尽会导致系统运行缓慢甚至崩溃。
硬盘空间与I/O (Disk Space & I/O)：监测硬盘的分区、总容量、已用空间和可用空间。同时，也会监测硬盘的读写速度（I/O），这是衡量数据存取性能的关键。
系统负载 (System Load)：通常用 Load Average 表示，它是一个衡量系统繁忙程度的指标，分别显示过去1分钟、5分钟和15分钟的平均负载。如果这个数值持续高于CPU核心数，说明系统处于超负荷状态。
在线时长 (Uptime)：服务器从上次开机或重启后，连续运行了多长时间。这是衡量服务器稳定性的一个重要指标。

2. 网络状态 (Network Status)

实时网速 (Real-time Network Speed)：显示服务器当前的上行和下行带宽速度，单位通常是 Mbps 或 MB/s。
总流量统计 (Total Traffic Data)：统计自开机以来或过去一段时间内（如月度）的总流出和流入流量。这对于管理服务器的带宽成本非常重要。
网络连接信息 (Network Connections)：显示当前服务器上有哪些网络连接（TCP/UDP），以及它们的来源IP和端口，有助于排查网络攻击或异常连接。

3. 软件与服务环境 (Software & Services)

操作系统信息：显示操作系统的名称、版本、内核版本等。
服务器软件：显示Web服务器软件（如 Nginx, Apache）、数据库（如 MySQL, PostgreSQL）和编程语言环境（如 PHP, Python, Java）的版本信息。
进程管理 (Process Management)：可以列出当前正在运行的进程，以及它们对CPU和内存的占用情况，方便找出消耗资源最多的“罪魁祸首”。

四、常见的服务器探针类型与产品

服务器探针主要分为两类：

1. 开源轻量级探针 (脚本类)

这类探针通常是一个或一组脚本文件（如PHP、Python、Shell脚本），部署简单，资源占用极小，功能聚焦于核心指标的展示。非常适合个人开发者和中小型网站使用。

代表产品：
- ServerStatus (服盘)：一个优秀的开源项目，采用客户端/服务器模式，可以在一个主控端网页上集中监控多台服务器的状态，界面美观，支持状态预警。
- 雅黑探针 / an Eris Prober：非常经典的PHP探针，界面简洁，上传一个PHP文件即可使用，流传甚广。
- 哪吒监控 (Nezha Monitor)：功能强大的开源监控面板，同样支持多服务器、多地点监控，并且集成了报警和后台管理功能，是目前非常受欢迎的选项。

2. 商业化/企业级监控系统

这类系统功能极为强大和全面，不仅限于基础的探针监测，还包括了日志分析、应用性能监控（APM）、故障告警、自动化运维等复杂功能，适用于大型企业和对稳定性要求极高的业务。

代表产品：
- Zabbix：非常强大和灵活的开源企业级监控解决方案，但配置和部署相对复杂。
- Prometheus + Grafana：这是一对黄金组合。Prometheus负责收集和存储时序数据，Grafana负责将数据进行可视化展示。这是云原生时代最主流的监控方案之一。
- Datadog / New Relic：商业SaaS监控服务，开箱即用，功能强大，UI精美，但价格昂贵。
- 云厂商自带监控：阿里云的“云监控”、腾讯云的“云监控”等，如果你使用它们的云服务器，这些自带的监控工具通常是首选，因为它们与云平台生态结合得最好。

总结

总而言之，服务器探针是一个连接“服务器物理状态”与“管理员”之间的桥梁。它将冰冷、复杂的后台数据，翻译成直观、易懂的图文信息，极大地简化了服务器的管理和维护工作。

对于个人站长或开发者来说，一个轻量级的开源探针（如哪吒监控、ServerStatus）就足以满足日常需求。
对于中大型企业来说，则需要部署更专业、更全面的监控系统（如Zabbix, Prometheus），以确保业务的高可用性和稳定性。

选择合适的服务器探针，是保障线上服务稳定运行的第一步，也是运维工作中不可或缺的一环。

bash命令使用教程

Fri, 18 Jul 2025 17:41:56 +0800

# ==================================
# 常用 BASH 命令精简版
# ==================================

export all_proxy=socks5h://127.0.0.1:7898 # 设置全局代理，包括 wget, curl 等

# --- 文件和目录管理 (File & Directory Management) ---
ls -l # 以长格式列出文件和目录
cd /path/to/dir # 切换目录
pwd # 显示当前工作目录路径
mkdir new_dir # 创建新目录
rm file.txt # 删除文件
rm -r old_dir # 递归删除目录及其内容
cp source dest # 复制文件或目录
mv old_name new_name # 移动或重命名文件/目录
touch file.txt # 创建空文件或更新时间戳
find . -name "*.log" # 在当前目录及子目录中查找.log文件
cat file.txt # 查看整个文件内容
less file.log # 分页查看文件内容 (按 'q' 退出)
head -n 20 file.txt # 查看文件前20行
tail -n 20 file.txt # 查看文件后20行
tail -f file.log # 实时跟踪文件更新

# --- 文本处理 (Text Processing) ---
grep "pattern" file.log # 在文件中搜索模式
ps aux | grep "nginx" # 管道示例：查找nginx进程
sed 's/old/new/g' file.txt # 替换文件中的文本
awk '{print $1, $3}' data.txt # 提取并打印指定列
sort file.txt | uniq -c # 排序并统计不重复的行
wc -l file.txt # 计算文件的行数

# --- 系统监控与进程管理 (System & Process Management) ---
ps aux # 显示所有用户的详细进程信
top # 动态显示进程活动 (按 'q' 退出)
htop # 交互式进程查看器 (top的增强版)
kill 12345 # 终止指定PID的进程
pkill "process_name" # 根据名称终止进程
df -h # 显示磁盘空间使用情况 (人类可读格式)
du -sh /path/to/dir # 显示指定目录的总大小
free -m # 显示内存使用情况 (以MB为单位)
uptime # 显示系统运行时间

# --- 网络 (Networking) ---
ping google.com # 测试网络连通性
ip addr show # 显示网络接口信息 (ifconfig的替代品)
ss -tuln # 显示监听中的TCP/UDP端口 (netstat的替代品)
curl -I http://example.com # 获取URL的HTTP头部信息
wget http://example.com/file.zip # 下载文件

# --- 权限管理 (Permissions) ---
chmod +x script.sh # 为脚本添加执行权限
chown user:group file.txt # 更改文件所有者和组
sudo command # 以超级用户身份执行命令

# --- 重定向 (Redirection) ---
command > file.txt # 将输出重定向到文件 (覆盖)
command >> file.txt # 将输出追加到文件末尾
command < file.txt # 将文件内容作为命令的输入
command 2> error.log # 将标准错误重定向到文件

如何把文件夹里的所有文件移动到同级目录

有时候我们想把一个文件夹（比如文件夹A）里的所有文件，移动到它的同级目录（也就是它的上一级目录）。可以按照下面的步骤操作：

打开终端。

进入文件夹A的上一级目录：

cd /路径/到/文件夹A的上一级目录

执行下面的命令，把文件夹A里的所有文件移动到当前目录：
```
mv 文件夹A/* .
```
这里，文件夹A/* 表示文件夹A里的所有文件，. 表示当前目录。

注意：

这个命令只会移动文件夹A里的文件，不会移动隐藏文件（以.开头的文件）和子文件夹。
如果有同名文件，可能会被覆盖，请提前检查。
移动完成后，文件夹A会变空，可以用 rmdir 文件夹A 删除它。

rustdesk安装使用

Mon, 19 May 2025 01:41:21 +0800

rustdesk：一款开源的远程控制软件

docker编排一次性部署好rustdesk-server和rustdesk-api

开放端口 TCP：21114-21119 UDP：21116

docker编排如下代码

 networks:
 rustdesk-net:
 external: false
 services:
 rustdesk:
 ports:
 - 21114:21114
 - 21115:21115
 - 21116:21116
 - 21116:21116/udp
 - 21117:21117
 - 21118:21118
 - 21119:21119
 image: lejianwen/rustdesk-server-s6:latest
 environment:
 - RELAY=<relay_server[:port]>
 - ENCRYPTED_ONLY=1
 - MUST_LOGIN=Y
 - TZ=Asia/Shanghai
 - RUSTDESK_API_RUSTDESK_ID_SERVER=<id_server[:21116]>  # 需要修改<>表示必填，[]表示选填，不过这里也填上，例如如改成 RUSTDESK_API_RUSTDESK_ID_SERVER = 182.168.198.1:21116
 - RUSTDESK_API_RUSTDESK_RELAY_SERVER=<relay_server[:21117]>
 - RUSTDESK_API_RUSTDESK_API_SERVER=http://<api_server[:21114]>
 - RUSTDESK_API_KEY_FILE=/data/id_ed25519.pub
 - RUSTDESK_API_JWT_KEY=xxxxxx # 
 volumes:
 - /data/rustdesk/server:/data
 - /data/rustdesk/api:/app/data #将数据库挂载
 networks:
 - rustdesk-net
 restart: unless-stopped

下面是一个示例

 networks:
 rustdesk-net:
 external: false
 services:
 rustdesk:
 ports:
 - 21114:21114
 - 21115:21115
 - 21116:21116
 - 21116:21116/udp
 - 21117:21117
 - 21118:21118
 - 21119:21119
 image: lejianwen/rustdesk-server-s6:latest
 environment:
 - RELAY=147.56.53.13:21117
 - ENCRYPTED_ONLY=1
 - MUST_LOGIN=N
 - TZ=Asia/Shanghai
 - RUSTDESK_API_RUSTDESK_ID_SERVER=147.56.53.13:21116
 - RUSTDESK_API_RUSTDESK_RELAY_SERVER=147.56.53.13:21117
 - RUSTDESK_API_RUSTDESK_API_SERVER=http://147.56.53.13:21114
 - RUSTDESK_API_KEY_FILE=/data/id_ed25519.pub
 - RUSTDESK_API_JWT_KEY=  # 设置MUST_LOGIN=Y填，不然可以不填
 volumes:
 - /data/rustdesk/server:/data
 - /data/rustdesk/api:/app/data #将数据库挂载
 networks:
 - rustdesk-net
 restart: unless-stopped

参数提示

RELAY=<relay_server[:port]> #中继服务器:21117 MUST_LOGIN=N #默认为N，设置为Y 则必须登录才能链接 RUSTDESK_API_RUSTDESK_ID_SERVER=<id_server[:21116]> #ID服务器 RUSTDESK_API_RUSTDESK_RELAY_SERVER=<relay_server[:21117]> #中继服务器 RUSTDESK_API_RUSTDESK_API_SERVER=http://<api_server[:21114]> #API服务器 RUSTDESK_API_JWT_KEY=xxxxxx #随便设置个字符串 cat /data/id_ed25519.pub #进入到容器里面查看 key

api服务的访问地址在<ip或域名>:21114, 默认管理员账户为admin,密码进入容器通过以下命令修改 ./apimain reset-admin-pwd

下面的教程是很久之前写的，可能存在失效的情况

docker编排 (可以安装宝塔linux或者ipanel)

1. 如果服务器上面没东西，可以选择安装宝塔linux，一般云服务器厂商都提供了相应的镜像可以选择安装

2. 安装ipanel

sudo -s


#根据自己的系统选择脚本
#RedHat / CentOS
curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && sh quick_start.sh

#Ubuntu
curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && sudo bash quick_start.sh

#Debian
curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && bash quick_start.sh

# 随后根据提示安装

搭建中继服务器

如果安装了宝塔面板的话，直接进入如下位置，然后再商店里面搜索就有，点击安装，然后查看日志，就可以看见key，记得把ke复制下来
如果是ipanel的话，可以使用编排进行，在编排日志里面可以看见key

services:
 rustdesk_Y662:
 image: rustdesk/rustdesk-server-s6:${VERSION}
 # container_name: ${CONTAINER_NAME}
 deploy:
 resources:
 limits:
 cpus: ${CPUS}
 memory: ${MEMORY_LIMIT}
 environment:
 - RELAY=${RUSTDESK_HOST_ADDR}:${RUSTDESK_PORT_HBBR}
 - ENCRYPTED_ONLY=1
 ports:
 - ${HOST_IP}:${RUSTDESK_PORT_NAT}:21115
 - ${HOST_IP}:${RUSTDESK_PORT_HBBS}:21116
 - ${HOST_IP}:${RUSTDESK_PORT_HBBS}:21116/udp
 - ${HOST_IP}:${RUSTDESK_PORT_HBBR}:21117
 - ${HOST_IP}:${RUSTDESK_PORT_WEB_CLIENT_1}:21118
 - ${HOST_IP}:${RUSTDESK_PORT_WEB_CLIENT_2}:21119
 restart: always
 volumes:
 - ${APP_PATH}/data:/data
 labels:
 createdBy: "bt_apps"
 networks:
 - baota_net

networks:
 baota_net:
 external: true

到这一步就可以了，搭建api服务器会很麻烦

搭建api服务器

networks:
 rustdesk-net:
 external: false

services:
 rustdesk:
 image: lejianwen/rustdesk-api:full-s6
 ports:
 - "【所开发的端口，如：29288】:21114" # 添加引号确保端口格式正确第一个是服务器开放的端口，是需要改的
 environment:
 RELAY: "【server_ip】:21117"
 ENCRYPTED_ONLY: "1"
 TZ: "Asia/Shanghai"
 RUSTDESK_API_RUSTDESK_ID_SERVER: "【server_ip】:21116"
 RUSTDESK_API_RUSTDESK_RELAY_SERVER: "【server_ip】:21117"
 RUSTDESK_API_RUSTDESK_API_SERVER: "http://【server_ip】:【所开发的端口，如：29288】"
 volumes:
 - /data/rustdesk/server:/data
 - /data/rustdesk/server:/app/conf/data
 - /data/rustdesk/api:/app/data
 networks:
 - rustdesk-net
 restart: unless-stopped

关于PC端链接超时或者链接不上的问题以及解决方案 | About the problem of timeout or connection failure on PC and how to solve it

https://github.com/lejianwen/rustdesk-api/issues/92

参考:

https://www.smianao.com/1323.html https://www.smianao.com/1340.html https://github.com/lejianwen/rustdesk-api/issues/92

国外服务器扶墙

Thu, 24 Apr 2025 00:19:47 +0800

两个实际上都没成功。。。还是很难的，所以以后国外服务器还是别买。。。 参考 https://ry.huaji.store/2020/08/Linux-magic-network/

V2ray

安装客户端参考： https://v2raya.org/docs/prologue/installation/debian/

# Ubuntu、Debian 
wget -qO - https://apt.v2raya.org/key/public-key.asc | sudo tee /etc/apt/keyrings/v2raya.asc
echo "deb [signed-by=/etc/apt/keyrings/v2raya.asc] https://apt.v2raya.org/ v2raya main" | sudo tee /etc/apt/sources.list.d/v2raya.list
sudo apt update
sudo apt install v2raya v2ray ## 也可以使用 xray 包
sudo systemctl start v2raya.service # 启动

然后访问 ip:2017 参考 https://v2raya.org/docs/prologue/quick-start/ 在第一次进入页面时，你需要创建一个管理员账号，请妥善保管你的用户名密码，如果遗忘，使用sudo v2raya –reset-password命令重置。

Shadowsocks

安装conda

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh
cd ~
source .bashrc

安装shadowsocks组件

sudo pip3 install https://github.com/shadowsocks/shadowsocks/archive/master.zip -U
或
sudo pip3 install shadowsocks

此外，如果你需要使用 Shadowsocks 新的加密方式的话，比如 Chacha20-Ietf-Poly1305，你还需要装下面这个东西

# ubuntu
sudo apt install libsodium-dev

# centos
sudo yum -y install epel-release
sudo yum -y install libsodium

配置新建配置文件夹和配置文件

sudo mkdir /etc/shadowsocks
sudo vi /etc/shadowsocks/shadowsocks.json

配置如下，具体内容自行修改（没有梯子请自行联系工信部申请）

{
 "server": "your_server_url",
 "server_port": 23333,
 "local_address": "127.0.0.1",
 "local_port": 1080,
 "password": "your_server_password",
 "timeout": 60,
 "method": "chacha20-ietf-poly1305",
 "workers": 1,
 "fast_open": false
}

其中

server：科学上网代理提供商的 Shadowsocks 服务器地址
server_port：科学上网代理提供商的 Shadowsocks 服务器端口
local_address：本地 Sock5 代理地址
local_port：本地 Sock5 代理端口
password：科学上网代理提供商的 Shadowsocks 连接密码
timeout：超时等待时间（秒）
method：加密方式
workers：工作线程数
fast_open：TCP Fast Open，按需开启

配置完成，之后就可以通过 local_address 和 local_port 走 Sock5 代理了

启动脚本创建启动脚本 /etc/systemd/system/shadowsocks.service

这里请确认你的 sslocal 的所在位置，自行修改脚本文件中的 /usr/local/bin/sslocal，位置不对启动服务时会报 203 错误

[Unit]
Description=Shadowsocks

[Service]
TimeoutStartSec=0
ExecStart=/usr/local/bin/sslocal -c /etc/shadowsocks/shadowsocks.json

[Install]
WantedBy=multi-user.target

GO! GO! GO! 启动服务或者配置开机自启动

开机自启动

sudo systemctl enable shadowsocks.service

启动服务

sudo systemctl start shadowsocks.service

查看状态

sudo systemctl status shadowsocks.service

停止服务

sudo systemctl stop shadowsocks.service

测试一下，看看你的 ip 地址是否符合预期

curl --socks5 127.0.0.1:1080 https://httpbin.org/ip

到这里 Shadowsocks 部分就结束了，可以直接跳转后面的 Sock5 代理部分接着搞

linux使用教程

Sun, 16 Mar 2025 17:16:02 +0800

服务器配置

Ubuntu 初始化配置


## 1.设置密码并更新软件包
sudo passwd
sudo apt update && sudo apt upgrade -y

## 2. 安装ssh-server
sudo apt install openssh-server

## 3.配置ssh
vim /etc/ssh/sshd_config

# 常见配置项示例
Port 22 # SSH 端口
PermitRootLogin no # 禁止 root 登录
PasswordAuthentication yes # 允许密码认证
AllowUsers myuser # 允许特顶用户登录
Port 2222 #修改端口，减少扫描攻击

## 4.重启ssh服务
sudo systemctl restart ssh

## 5.创建用户(避免直接使用root账号)
adduser myuser
usermod -aG sudo myuser


## 6. 连接服务器
ssh root@服务器IP地址 -p [你自己设置的端口]

一些问题和解决方案

Linux 下更改当前文件夹及所有内容所有者为 zata 用户

目标
将当前文件夹及其下所有文件和子文件夹的所有者更改为 zata 用户。

步骤

打开终端：按 Ctrl + Alt + T，使用 cd /path/to/your/folder 进入目标文件夹，确认路径：pwd。
更改所有者：
```
sudo chown -R zata .
```
- . 表示当前文件夹，-R 递归更改所有内容。
（可选）设置权限：只给 zata 读写权限：
```
sudo chmod -R 700 .
```
验证更改：检查所有者和权限：
```
ls -la
```

注意事项

确认 zata 用户存在：id zata。若不存在，创建：sudo adduser zata。
备份数据，避免误操作。
（可选）分配组：sudo chown -R zata:groupname .。

bash: ping: command not found 问题

apt-get update
apt install iputils-ping
apt install net-tools

SSH使用教程

Fri, 14 Mar 2025 00:23:43 +0800

☆ SSH常用命令

# 连接远程服务器 
ssh username@hostname [-p port] [-i private_key]


#远程服务器上跑了 PostgreSQL（默认端口 5432），但不允许外网直接连接。用这条命令后，你可以在本地用数据库客户端连接：
ssh -L 5433:127.0.0.1:5432 root@远程IP

# 复制公钥到远程服务器
ssh-copy-id username@hostname [-p port] [-i private_key]

# Generate ED25519 key (recommended)
ssh-keygen -t ed25519 -C "your_email@example.com"
# 删除已知主机记录
ssh-keygen -R <IP address>

# Edit SSH config file
nano ~/.ssh/config


# Copy file from local to remote
scp localfile.txt username@hostname:/path/to/destination/
# Copy file from remote to local
scp username@hostname:/path/to/file /var/www/local_dir/destination/
# Copy directory recursively
scp -r localdir/ username@hostname:/path/to/destination/
# Copy with specific port
scp -P 2222 localfile.txt username@hostname:/path/to/destination/

SSH安装

ubuntu

sudo apt update # 更新仓库
sudo apt install openssh-server # 安装openssh
vi /etc/ssh/sshd_config # 进入配置文件，找到port=22那行，取消注释 ，如果想要root登陆，可以取消PermitRootLogin注释并修改为yes
sudo service ssh restart # 重启服务，然后就可以连接了，有时候为了安全，上一步的root登陆是不允许的，root用户连不上，可以用普通用户登录再切换到root

1. SSH 连接命令

# 基本连接
ssh username@hostname

# 通过代理连接
ssh -o "ProxyCommand nc -X 5 -x 127.0.0.1:7897 %h %p" root@107.172.234.205

# 指定端口连接
ssh -p 2222 username@hostname

# 使用密钥连接
ssh -i /path/to/private_key username@hostname

2. SSH 密钥管理

# 生成 SSH 密钥对
ssh-keygen -t rsa -b 4096

# 复制公钥到远程服务器
ssh-copy-id username@hostname # 如果是windows可以看问题：在Windows客户机上实现类似ssh-copy-id功能即下次不需要输入密码
# 或者， （有些时候上吗会出错）ssh-keygen -R <IP address> to delete history record
cat ~/.ssh/id_ed25519.pub | ssh root@<IP address> "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

# 查看已知主机
cat ~/.ssh/known_hosts

(在Windows客户机上实现类似ssh-copy-id功能即下次不需要输入密码)[#在Windows客户机上实现类似ssh-copy-id功能即下次不需要输入密码]

3.SSH传输文件

# 1、从服务器上下载文件
scp username@servername:/path/filename /var/www/local_dir（本地目录）
 # 例如scp root@192.168.0.101:/var/www/test.txt 把192.168.0.101上的/var/www/test.txt 的文件下载到/var/www/local_dir（本地目录）

# 2、上传本地文件到服务器
scp /path/filename username@servername:/path
# 例如scp /var/www/test.php root@192.168.0.101:/var/www/ 把本机/var/www/目录下的test.php文件上传到192.168.0.101这台服务器上的/var/www/目录中

# 3、从服务器下载整个目录
scp -r username@servername:/var/www/remote_dir/（远程目录） /var/www/local_dir（本地目录）
# 例如:scp -r root@192.168.0.101:/var/www/test /var/www/ 

# 4、上传目录到服务器
scp -r local_dir username@servername:remote_dir
# 例如：scp -r test root@192.168.0.101:/var/www/ 把当前目录下的test目录上传到服务器的/var/www/ 目录

4. SSH 端口转发

注意必须要提前配置公网服务器的ssh配置文件可见ssh问题中的“通过 SSH 反向隧道将本地前后端暴露到公网”

# 本地端口转发
ssh -L local_port:target_host:target_port username@hostname

# 远程端口转发
ssh -R remote_port:target_host:target_port username@hostname
#不发送任何命令，只用来建立连接。没有这个参数，会在 SSH 服务器打开一个 Shell。会在前台打开
ssh -R <服务器端口>:localhost:22 -N root@<服务器地址>
# 将SSH命令放到后台，如果想要停止需要杀死进程 （ 比较常用 ）
ssh -R <服务器端口>:localhost:22 -Nf root@<服务器地址>

# 动态端口转发（SOCKS代理）
ssh -D local_port username@hostname






# 基本格式
ssh [选项] username@hostname

# 常用选项说明
-L [本地IP:]本地端口:目标IP:目标端口 # 本地端口转发
-R [远程IP:]远程端口:目标IP:目标端口 # 远程端口转发
-D [本地IP:]本地端口 # 动态端口转发(SOCKS代理)

# 重要的辅助选项
-N # 不执行远程命令，仅用于端口转发
-f # 后台运行
-C # 压缩数据传输
-q # 安静模式，减少日志输出
-v # 详细模式，用于调试
-vv # 更详细的模式
-4 # 仅使用 IPv4
-6 # 仅使用 IPv6
# 连接相关选项
-p 端口 # 指定 SSH 服务器端口
-i 密钥 # 指定私钥文件路径

5. SSH 配置管理

# 编辑 SSH 配置文件
vim ~/.ssh/config

# 配置文件示例
Host myserver
 HostName hostname
 User username
 Port 2222
 IdentityFile ~/.ssh/id_rsa

常见用途对比：

安全性

密码登录：便捷但相对不安全
密钥登录：更安全，推荐使用

传输方式

scp：简单直接，适合临时传输
rsync：支持增量传输，适合大量文件同步

端口转发

本地转发：访问远程内网服务
远程转发：让远程访问本地服务
动态转发：创建 SOCKS 代理

连接管理

普通连接：一次性使用
配置文件：适合经常连接的服务器

使用建议：

优先使用密钥认证
重要服务器建议修改默认 22 端口
经常连接的服务器建议配置 ~/.ssh/config
大文件传输建议使用 rsync 而不是 scp
注意保护好私钥文件的安全

这些命令和用法覆盖了日常 SSH 使用的大部分场景，建议根据实际需求选择合适的命令使用。

Ubuntu 下 SSH 服务的启动、停止和管理方法：

安装 SSH 服务

# 安装 OpenSSH 服务器
sudo apt update
sudo apt install openssh-server

service 命令（传统方式）

# 启动
sudo service ssh start

# 停止
sudo service ssh stop

# 重启
sudo service ssh restart

# 查看状态
sudo service ssh status

/etc/init.d 脚本方式

# 启动
sudo /etc/init.d/ssh start

# 停止
sudo /etc/init.d/ssh stop

# 重启
sudo /etc/init.d/ssh restart

# 查看状态
sudo /etc/init.d/ssh status

systemctl 命令（现代 systemd 方式）

# 启动
sudo systemctl start sshd

# 停止
sudo systemctl stop sshd

# 重启
sudo systemctl restart sshd

# 查看状态
sudo systemctl status sshd

直接启动 sshd 进程

# 直接启动 sshd
sudo /usr/sbin/sshd

# 使用特定配置文件启动
sudo /usr/sbin/sshd -f /path/to/sshd_config

不同系统的区别：

Ubuntu/Debian 系统中服务名通常是 ssh

sudo service ssh start

CentOS/RHEL 系统中服务名通常是 sshd

sudo service sshd start

注意事项：

现代 Linux 系统推荐使用 systemctl 命令
service 命令在新系统中实际上是 systemctl 的封装
/etc/init.d 脚本方式是最传统的方法，但仍被支持
直接启动 sshd 进程通常用于调试目的

选择哪种方式主要取决于：

系统版本
个人习惯
具体需求（如调试）

所有这些方法都能达到相同的目的，只是使用的方式不同。

SSH 配置文件位置

# 主配置文件
sudo vim /etc/ssh/sshd_config

# 常见配置项示例
Port 22 # SSH 端口
PermitRootLogin no # 禁止 root 登录
PasswordAuthentication yes # 允许密码认证

检查 SSH 服务

# 检查 SSH 是否正在运行
ps aux | grep ssh

# 检查 SSH 端口是否开放
sudo netstat -tulpn | grep ssh

# 检查防火墙是否允许 SSH
sudo ufw status

防火墙设置

# 允许 SSH 连接
sudo ufw allow ssh

# 允许特定端口（如果修改了默认端口）
sudo ufw allow 2222/tcp

常见问题解决：

服务无法启动

# 查看详细日志
sudo journalctl -u ssh

# 检查配置文件语法
sudo sshd -t

权限问题

# 修复 SSH 目录权限
sudo chmod 755 /etc/ssh
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub

安全建议：

基本安全配置

# 编辑 SSH 配置文件
sudo vim /etc/ssh/sshd_config

# 推荐的安全设置
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
Protocol 2

使用密钥认证

# 在客户端生成密钥对
ssh-keygen -t rsa -b 4096

# 将公钥复制到服务器
ssh-copy-id username@server_ip

常用维护命令：

查看连接状态

# 查看当前 SSH 连接
who
w

# 查看 SSH 登录日志
sudo cat /var/log/auth.log | grep ssh

配置文件备份

# 备份 SSH 配置
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

记住，每次修改 SSH 配置文件后，都需要重启 SSH 服务才能生效：

sudo systemctl restart ssh

这些是 Ubuntu 下管理 SSH 服务的基本操作，建议在修改配置时先备份，并保持一个可用的连接会话，以防配置错误导致无法连接。

SSH 使用指南

使用公网Linux服务器为Windows电脑做内网穿透

方法一：使用FRP（推荐，稳定可靠）

FRP (Fast Reverse Proxy) 是一款专为此类场景设计的工具，功能强大，支持断线重连，适合长期稳定使用。

服务端配置 (Linux公网服务器)

下载并解压FRP:

# 前往 https://github.com/fatedier/frp/releases 找最新版Linux amd64链接

wget [最新版frp的linux_amd64.tar.gz链接]

tar -zxvf frp_*.tar.gzcd frp_*/

配置 frps.ini:

# frps.ini[common]bind_port = 7000 # 用于和客户端通信的端口token = your_secure_password # 连接凭证，请务必修改dashboard_port = 7500 # [可选] 状态仪表盘端口dashboard_user = admin # [可选] 仪表盘用户名dashboard_pwd = admin_password # [可选] 仪表盘密码

开放服务器防火墙:

确保开放 7000 端口以及你计划用于转发的端口（如下文的 7001）和仪表盘端口 7500。




# firewalld示例

sudo firewall-cmd --add-port=7000/tcp --permanent

sudo firewall-cmd --add-port=7001/tcp --permanent

sudo firewall-cmd --reload

运行服务端:




./frps -c ./frps.ini

建议设置为 systemd 服务以实现开机自启和后台运行。

客户端配置 (Windows内网电脑)

下载并解压FRP: 前往FRP的GitHub Releases页面，下载对应的 windows_amd64.zip 版本并解压。

配置 frpc.ini (以穿透远程桌面为例):




# frpc.ini[common]server_addr = 你的服务器公网IPserver_port = 7000token = your_secure_password # 必须和服务端一致[rdp]type = tcplocal_ip = 127.0.0.1local_port = 3389 # Windows远程桌面默认端口remote_port = 7001 # 从公网访问的端口

运行客户端: 打开CMD或PowerShell运行：


# 进入frp目录

.\frpc.exe -c .\frpc.ini

建议使用 nssm 等工具将其注册为Windows服务，实现开机自启。

如何连接

在任何电脑上打开“远程桌面连接”(mstsc)，计算机名处输入：你的服务器公网IP:7001。

方法二：使用SSH反向隧道（轻便快捷）

利用SSH内置功能，无需额外软件，适合临时、快速的连接。

服务端配置 (Linux公网服务器)

编辑SSH配置文件，允许公网访问隧道端口：




sudo vim /etc/ssh/sshd_config

# 找到或添加 GatewayPorts 并设置为 yes：
GatewayPorts yes

重启SSH服务：

sudo systemctl restart sshd

客户端操作 (Windows内网电脑)

打开PowerShell或CMD，执行以下命令：

# -fN 表示后台运行且不执行远程命令，只做隧道# 格式: ssh -fN -R [服务器端口]:[本地IP]:[本地端口] [用户名]@[服务器IP]

ssh -fN -R 7001:127.0.0.1:3389 your_user@你的服务器公网IP

该命令会建立一个长连接隧道，关闭窗口则隧道断开。

如何连接

与FRP方式相同，在“远程桌面连接”中输入你的服务器公网IP:7001。

常见问题：localhost 不行但 127.0.0.1 可以？

这是一个由于IPv6/IPv4解析优先级导致的问题。

原因: localhost 可能被系统优先解析为IPv6的 ::1 地址，但你的目标服务（如远程桌面）仅在IPv4的 127.0.0.1 上监听。

最佳解决方案: 无需排查，在所有配置（无论是FRP还是SSH）中，请始终使用 127.0.0.1 而不是 localhost。127.0.0.1 明确指向IPv4本地环回地址，能保证连接的准确性，是最简单、最可靠的做法。

通过 SSH 反向隧道将本地前后端暴露到公网

准备公网服务器
- 获取公网服务器（如阿里云），记录 IP（如 203.0.113.1）。
- 确保安装 SSH 服务（OpenSSH）。

配置公网服务器

编辑 /etc/ssh/sshd_config，启用：

AllowTcpForwarding yes
GatewayPorts yes

重启 SSH：
```
sudo systemctl restart sshd
```

开放端口（如 3000、8000）：

sudo ufw allow 3000
sudo ufw allow 8000

确保本地服务运行
- 前端：运行在 localhost:3000（如 React）。
- 后端：运行在 localhost:8000（如 Flask）。
- 确认本地可通过浏览器访问。

配置 SSH 反向隧道

在本地运行：

ssh -R 3000:localhost:3000 -R 8000:localhost:8000 user@203.0.113.1

使用 autossh 保持连接：

autossh -M 0 -R 3000:localhost:3000 -R 8000:localhost:8000 user@203.0.113.1

测试访问
- 访问 http://203.0.113.1:3000（前端）和 http://203.0.113.1:8000（后端）。
- 确保前端 API 请求指向公网 IP（如 http://203.0.113.1:8000）。

可选：Nginx 优化

安装 Nginx：
```
sudo apt install nginx
```

配置 /etc/nginx/sites-available/default：

server {
 listen 80;
 server_name 203.0.113.1;
 location / { proxy_pass http://localhost:3000; }
 location /api/ { proxy_pass http://localhost:8000/; }
}

重启 Nginx：
```
sudo systemctl restart nginx
```

注意事项
- 保持本地电脑开机和网络稳定。
- 配置 SSH 密钥认证提高安全性。
- 检查防火墙和 CORS 设置。

解决 ssh 连接远程主机超时未使用自动断开

参考：https://blog.csdn.net/Gelomen/article/details/109121069

这个问题可以通过配置 SSH 客户端来保持连接活跃。有以下几种解决方案：

1. 修改 SSH 客户端配置文件（推荐方案）：
编辑 ~/.ssh/config 文件（如果没有则创建），添加以下配置：

 Host *
 ServerAliveInterval 60
 ServerAliveCountMax 3

这个配置的含义是：
- ServerAliveInterval 60: 每60秒发送一次心跳包
- ServerAliveCountMax 3: 如果连续3次心跳包没有响应，则断开连接

2. 在建立 SSH 连接时直接指定参数：

 ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@remote-server

3. 如果是在使用 SSH 隧道，可以这样：

 ssh -N -f -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -L local-port:remote-host:remote-port user@remote-server

4. 如果你是服务器管理员，也可以通过修改服务器端的 SSH 配置（/etc/ssh/sshd_config）来实现：

 ClientAliveInterval 60
 ClientAliveCountMax 3

修改服务器配置后需要重启 SSH 服务：

 sudo systemctl restart sshd

推荐使用第一种方案（修改客户端配置文件），因为：
1. 只需配置一次，永久生效
2. 对所有 SSH 连接都有效
3. 不需要每次手动输入参数

注意：设置的时间间隔不要太短（比如小于30秒），否则可能会增加不必要的网络开销。60秒通常是一个比较好的选择。

服务器安装ssh服务 (linux & windows)

linux

sudo apt update # 更新仓库
sudo apt install openssh-server # 安装openssh
sudo service ssh restart # 重启服务，然后就可以连接了，有时候root用户连不上，可以用普通用户登录再切换到root

windows 参考： https://blog.csdn.net/weixin_72910567/article/details/132414264

# 1. 在设置-应用和功能里安装openssh服务

# 2. 查看是否安装成功
Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

# 3. 开启服务
net start sshd

# 4. 设置开机自启动
Set-Service -Name sshd -StartupType 'Automatic'

在Windows客户机上实现类似ssh-copy-id功能即下次不需要输入密码

问题背景

Windows 的 CMD 或 PowerShell 默认不支持 ssh-copy-id 命令。本教程介绍如何在 Windows 上将 SSH 公钥复制到远程服务器（IP: 192.168.110.150，端口: 6001）以实现无密码登录。

方法 1：手动复制 SSH 公钥

检查本地 SSH 密钥：
- 查看公钥：type %USERPROFILE%\.ssh\id_rsa.pub
- 如无密钥，生成：ssh-keygen -t rsa -b 4096
登录远程服务器：
- 运行：ssh -p 6001 root@192.168.110.150
- 确保 ~/.ssh 目录存在：mkdir -p ~/.ssh && chmod 700 ~/.ssh
复制公钥：
- 在 Windows 复制公钥内容：type %USERPROFILE%\.ssh\id_rsa.pub
- 在远程服务器编辑：vi ~/.ssh/authorized_keys，粘贴公钥，保存。
- 设置权限：chmod 600 ~/.ssh/authorized_keys
测试无密码登录：
- 运行：ssh -p 6001 root@192.168.110.150

方法 2：使用 PowerShell 模拟 ssh-copy-id

确保 OpenSSH 客户端已安装：
- 检查：ssh -V
- 未安装则在“设置 > 应用 > 可选功能”中添加 OpenSSH 客户端。
复制公钥：
- 运行：Get-Content $env:USERPROFILE\.ssh\id_rsa.pub | ssh -p 6001 root@192.168.110.150 "cat >> ~/.ssh/authorized_keys"
验证权限：
- 登录服务器：ssh -p 6001 root@192.168.110.150
- 运行：chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
测试无密码登录：
- 运行：ssh -p 6001 root@192.168.110.150

方法 3：安装 Git Bash 或 WSL

使用 Git Bash：
- 安装 Git for Windows，打开 Git Bash。
- 运行：ssh-copy-id -p 6001 root@192.168.110.150
使用 WSL：
- 安装 WSL：wsl --install
- 在 Ubuntu 中安装 openssh-client：sudo apt update && sudo apt install openssh-client
- 运行：ssh-copy-id -p 6001 root@192.168.110.150

注意事项

确保远程服务器允许密码登录或已配置 root 密码。
公钥复制后，检查 ~/.ssh/authorized_keys 文件内容和权限。
测试无密码登录是否成功，如失败，检查 SSH 配置文件 /etc/ssh/sshd_config 和服务器防火墙设置。

本地机器生成密钥并复制到远程服务器（下次ssh连接就不需要输入密码）

注意： ssh-copy-id 是专门为linux系统适配的，windows系统不好用，需要手动复制公钥到.ssh文件夹下面的authorized_keys文件中

linux

# 生成 SSH 密钥对
ssh-keygen -t rsa -b 4096

# 复制公钥到远程服务器
ssh-copy-id username@hostname

# 查看已知主机
cat ~/.ssh/known_hosts

如果是windows服务器，使用如下方式将公钥内容追加

echo "你的公钥内容" >> 你的用户目录/.ssh/authorized_keys

Windows 下关闭 SSH 后台连接的方法（在使用端口转发设置参数为-f时）

使用任务管理器：

# 打开任务管理器的方法：
# 1. Ctrl + Shift + Esc
# 2. 右键任务栏 -> 任务管理器
# 3. Ctrl + Alt + Delete -> 任务管理器

# 在"详细信息"或"进程"标签下找到 ssh.exe 进程并结束

使用命令行查找和终止进程：

# PowerShell 命令
# 查看 SSH 进程
Get-Process ssh

# 终止所有 SSH 进程
Get-Process ssh | Stop-Process

# 或者使用 CMD 命令
# 查看 SSH 进程
tasklist | findstr "ssh"

# 通过 PID 终止进程
taskkill /PID <进程ID> /F

# 终止所有 SSH 进程
taskkill /F /IM ssh.exe

如果使用 Git Bash：

# 查看 SSH 进程
ps aux | grep ssh

# 终止进程
kill <进程ID>

建议：

在使用 -Nf 启动 SSH 连接时，可以记录下进程 ID：

# 将进程 ID 保存到文件
ssh -Nf ... & echo $! > ssh_pid.txt

创建一个批处理文件来管理连接：

@echo off
REM start_ssh.bat
ssh -Nf ... & echo %ERRORLEVEL% > ssh_pid.txt

REM stop_ssh.bat
for /f %%i in (ssh_pid.txt) do taskkill /PID %%i /F
del ssh_pid.txt

1panel使用教程｜云服务器使用教程

Sun, 09 Mar 2025 16:14:31 +0800

1panel安装

官网：
https://1panel.cn/docs/installation/online_installation/

# ubuntu
apt install curl # 如果下面一行提示curl没有
curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && sudo bash quick_start.sh
1pctl --help # 查看是否安装成功

实战 — 问题和解决方案

腾讯云的windows服务器做远程hugo的dev服务器的时候出的问题（之前用过华为云的服务器做dev服务器，明显腾讯做的不如华为）

使用腾讯云自带的snv连接，卡的要死，所以用了windows自带的，mac上面又windows app作为远程连接
使用openssh作为ssh作为服务器之后，存在总是断联问题，增加conf文件解决 config文件解决ssh断联
git可以使用便携包，然后添加一下环境变量（里面的cmd文件夹），再重启服务器
使用windows远程服务器进行git pull总是卡死，最终给出的解决方案就是：使用github的http地址拉取项目，然后使用ssh地址同步

云服务器，修改时区设置

首先查看服务器时间，明显是错误的

# 检查时区
date

# 通过手动链接时区文件来更改时区：
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

# 如果有/etc/timezone 文件，可以更新它以确保一致性，当然不更新也可以
cat /etc/timezone
echo "Asia/Shanghai" > /etc/timezone

我自己使用1panel和云服务器的一些感悟

在云服务器部署碰到的麻烦事：

1panel 的运行环境模式，会自动执行脚本，虽然它创建了一个docker容器，但是如果你进去想要把它的脚本关掉，它会自启动，而如果你把它的这个环境停掉，docker容器就消失了，所以不要用它的环境容器做什么事情
1panel的docker连接之后要先执行一下su，不然的话命令是不好操作的，比如就没有补全功能
要去/ect/hosts去设置一下github的ip地址解析，不然会很慢
云服务器如果是国内厂商的，最好设置一下镜像源，不然的话会下载非常慢，比如pip install的时候

1panel的反向代理

clash 教程

Thu, 06 Mar 2025 10:51:58 +0800

clash

项目地址：

https://github.com/zzzgydi/clash-verge/tree/main

clash 基础知识 - clash 介绍

参考

Clash for Windows 使用教程快速入门篇

Clash for Windows是代理工具Clash在Windows系统的图形客户端，同时还支持Windows、Linux、macOS三大系统，功能强大且支持多种代理协议，如Shadowsocks(SS)、ShadowsocksR(SSR)、Socks、Snell、V2Ray、Trojan等代理协议。通过本文2025最新Clash for Windows使用教程快速入门篇所掌握的技巧，能快速方便配置代理协议进行代理访问。

官方的clash现在已经删库跑路了，不过还是有很多其他人在做，下面是其中一些

clash verge - github

clash verge rev - github

界面介绍

General（常规）：

Port、Socks Port；分别为 HTTP、SOCKS 代理端口，点击终端图案可以打开一个配置了代理的命令行窗口，点击端口数字可以复制该命令；

Allow LAN：启用局域网共享代理功能；

Log Level：日志等级；

Home Directory：点击下方路径直达 C:\Users\用户名.config\clash 文件夹；

GeoIP Database：点击下方日期可更新 GeoIP 数据库；

UWP Loopback ：可以用来使 UWP 应用解除回环代理限制；

Tap Device ：安装 cfw-tap 网卡，可用于处理不遵循系统代理的软件（实际启动 tap 模式需要更改配置文件）；

General YML：编辑 config.yml 文件，可用于配置部分 General 页面内容；

Dark Theme：控制暗色模式；

System Proxy：启用系统代理；

Start with Windows：设置开机自启；

Proxies（代理）：选择代理方式（Global - 全局、Rule - 规则、Direct - 直连）及策略组节点选择；
Profiles（配置管理）：

用来下载远端配置文件和创建本地副本，且可在多个配置文件间切换；对配置进行节点、策略组和规则的管理（添加节点、策略组和规则在各自编辑界面选择 Add, 调整策略组顺序、节点顺序及策略组节点使用拖拽的方式）；

Logs（日志）：显示当前请求命中规则类型和策略；
Connections (连接): 显示当前的 TCP 连接，可对某个具体连接执行关闭操作；
Settings（设置）：软件详细设置；
Feedback（反馈）：显示软件、作者相关信息。

如何添加订阅

远程订阅地址订阅

远程订阅地址即通过 URL 链接导入，一般的服务商都会直接提供Clash节点地址，直接复制服务商提供的节点订阅地址即可，如下图所示：

然后点击界面左侧菜单配置，在顶部输入框填入刚才复制的 URL 连接地址并点击下载即可，下载完成后点击对应的配置文件即可添加配置文件，如下图所示。

本地配置文件

本地配置文件即通过本地文件拖拽导入，一般为无法通过远程订阅地址导入的情况下使用，可尝试在浏览器中下载配置文件后直接通过拖拽方式导入或点击 Import 导入，如下图所示。

选择代理节点

在添加完订阅地址之后，需要选择一个代理节点使用，点击软件主界面左侧的代理选项卡，软件右上角代理规则处默认保持规则即可，代理模式主要有以下四种：

规则：所有请求根据配置文件规则进行分流
全局：所有请求直接发往代理服务器
直连：所有请求直接发往目的地，即不使用代理
脚本：所有请求根据脚本文件规则进行分流

全局模式可能会导致国内流量也走代理访问，除了网络会变慢外，还会消耗套餐流量。规则模式的好处就是区分国内国外的流量只有在规则内的国外网站才会走代理，这样即不影响国内访问速度，又节省套餐流量，所以如果没有什么特别的需求，一般选择规则即可。

有一点值得注意，选择了全局模式，而全局模式中的节点挂掉了，会导致无法访问国内的网站

然后在展开的节点组之中任意单击鼠标左键选择一个节点即可，如下图所示：

启用代理

启用代理，需要点击界面左侧菜单主页选项卡，找到系统代理并开启开关即可，开启状态下按钮状态为绿色，如下图所示为开启状态。

启动代理后系统托盘的图标会变色金色猫咪，以下是系统托盘图标颜色说明。

设置开机启动

设置开机自启动，需要点击界面左侧菜单主页选项卡，找到开机自启动并开启开关即可，开启状态下按钮状态为绿色，如下图所示为开启状态。

有一点值得注意，如果未选择开机启动，而关机的时候直接未退出clash就关机了，会导致下次开机的时候无法连接网络，解决方式是重新打开clash，然后正常退出或者不退出clash都可能

更新配置文件

点击界面左侧菜单配置，点击更新全部即可更新所有配置文件，如下图所示。

这个更新只针对远程导入的订阅

修改clash中的规则信息

改过配置之后不要刷新订阅，不然就没了，不过不更新又不会加载规则，可以通过切换订阅文件的方式加载规则

配置是按照顺序来的，如果说你都用了域名过滤，写在前面的会优先级更高，此外还有DOMAIN-SUFFIX 和DOMAIN的区别，看下面单独的讲解

可以复制一个你原有的规则，然后修改里面的内容，然后保存。通过加载本地文件的方式加载

1. 获取代理服务器信息

你需要从你的代理服务提供商（比如 V2Ray、Shadowsocks、Trojan 等）那里拿到服务器信息，通常包括：

服务器地址（IP 或域名）
端口号
加密方式
密码或 UUID
协议类型（如 vmess、vless、ss 等）

例如，一个简单的 Shadowsocks 服务器信息可能是：

服务器地址: example.com
端口: 8388
加密: aes-256-gcm
密码: yourpassword

2. 创建基础配置文件

创建一个 config.yaml 文件，然后用文本编辑器（如 Notepad++、VS Code）打开。以下是一个简单的配置文件模板：

# 基本设置
port: 7890 # 本地 HTTP 代理端口
socks-port: 7891 # 本地 SOCKS5 代理端口
allow-lan: false # 是否允许局域网连接，false 表示仅本地使用
mode: rule  # 工作模式：rule（规则分流）、global（全局代理）、direct（直连）
log-level: info  # 日志级别，可选 silent/info/warning/error/debug

# 代理节点列表
proxies:
 - name: "ss1" # 节点名称，自定义即可
 type: ss  # 协议类型，这里是 Shadowsocks
 server: example.com  # 服务器地址
 port: 8388 # 端口
 cipher: aes-256-gcm  # 加密方式
 password: "yourpassword" # 密码

# 代理组（用于选择节点）
proxy-groups:
 - name: "auto" # 组名称
 type: select  # 类型：select 表示手动选择
 proxies:
 - "ss1" # 这里引用上面定义的节点

# 规则
rules:
 - DOMAIN-SUFFIX,google.com,auto  # 匹配 google.com 的流量走 auto 组
 - DOMAIN-SUFFIX,baidu.com,DIRECT  # 百度直连
 - MATCH,auto  # 其他未匹配的流量走 auto 组

3. 解释配置文件的主要部分

端口设置：port 和 socks-port 是 Clash 在本地监听的端口，应用程序通过这些端口连接代理。
proxies：这里列出你的所有代理节点。可以添加多个，比如 ss1、ss2 等。
proxy-groups：代理组用来组织节点，可以手动选择或设置自动选择（如 url-test）。
rules：规则决定哪些流量走代理，哪些直连。可以用域名、IP 等条件匹配。

4. 保存并加载配置文件

将文件保存为 config.yaml。
打开 Clash 客户端，把文件拖进去，或者在设置中指定文件路径。
启动 Clash，检查是否能正常连接。

5. 测试

打开浏览器，设置代理为 127.0.0.1:7890（HTTP）或 127.0.0.1:7891（SOCKS5）。
访问一个被代理的网站（比如 google.com），看看是否成功。

进阶

使用api切换节点

在clash的设置中打开外部控制

import urllib.parse # 顶部添加
import random
import time
import requests

API_URL = "http://127.0.0.1:9097"
SECRET = "clashapikeyXXXX" # 如果设置了
GROUP_NAME = "🇺🇸 美国" # 你的proxy-group名字，必须是type: select的组
clash_api_headers = {
 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36',
 'Accept': 'application/json, text/plain, */*',
 'Accept-Language': 'en-US,en;q=0.9',
 'Authorization': f'Bearer {SECRET}' # <--- 必须加上这一行
}
# 在 get_proxies() 后，添加一个 encoded 版本
ENCODED_GROUP_NAME = urllib.parse.quote(GROUP_NAME)
# 先获取所有可用节点
def get_proxies():
 global GROUP_NAME
 resp = requests.get(f"{API_URL}/proxies", headers={"Authorization": f"Bearer {SECRET}"} if SECRET else {})
 proxies_data = resp.json()["proxies"]
 print("Available proxy groups:")
 # print(proxies_data)
 for group_name in proxies_data:
 if proxies_data[group_name].get("type") == "select":
 try:
 print(f" - {group_name}")
 except UnicodeEncodeError:
 print(f" - [包含特殊字符的组名] ({len(group_name)} chars)")
 if GROUP_NAME not in proxies_data:
 print(f"Warning: Group '{GROUP_NAME}' not found. Using first available select group.")
 for group_name in proxies_data:
 if proxies_data[group_name].get("type") == "select":
 GROUP_NAME = group_name
 break
 return list(proxies_data[GROUP_NAME]["all"]) # 返回节点名列表

proxies_list = get_proxies()
print(proxies_list)

# 修改 switch_proxy 函数
def switch_proxy():
 try:
 new_proxy = random.choice(proxies_list)
 print(f"尝试切换到节点: {new_proxy}")

 # 使用 encoded 的组名在 URL 中
 resp = requests.put(
 f"{API_URL}/proxies/{ENCODED_GROUP_NAME}", #如果grounp Name里面有emoji，不用encoded会出错
 json={"name": new_proxy},
 headers=clash_api_headers
 )
 print(resp)

 # 关键：检查响应！Clash 切换成功返回 204 No Content
 if resp.status_code == 204:
 print(f"成功切换到节点: {new_proxy}")
 else:
 print(f"切换失败！状态码: {resp.status_code}, 响应: {resp.text}")
 # 可选：打印当前实际选中的节点
 current = requests.get(f"{API_URL}/proxies/{ENCODED_GROUP_NAME}", headers=clash_api_headers).json()
 print(f"当前实际节点: {current.get('now')}")

 time.sleep(5) # 等待切换生效（有些节点需要几秒）

 except Exception as e:
 print(f"切换异常: {e}")



# 示例爬虫循环
for i in range(10): # 减少循环次数用于测试

 switch_proxy()
 headers = {
 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36',
 'Accept': 'application/json, text/plain, */*',
 'Accept-Language': 'en-US,en;q=0.9',
 }
# 你的爬虫请求
 try:
 resp = requests.get(headers=headers, url="https://httpbin.org/ip", timeout=5,proxies={"http": "http://127.0.0.1:7897", "https": "http://127.0.0.1:7897"})
 print("当前IP:", resp.text.strip())
 except requests.exceptions.RequestException as e:
 print(f"请求失败 (Clash代理未运行?): {e}")
 # 尝试不使用代理
 try:
 resp = requests.get(headers=headers, url="https://httpbin.org/ip", timeout=5,proxies={"http": "http://127.0.0.1:7897", "https": "http://127.0.0.1:7897"})
 print("直连IP:", resp.text.strip())
 except requests.exceptions.RequestException as e2:
 print(f"直连也失败: {e2}")
 time.sleep(5)

DOMAIN-SUFFIX 和 DOMAIN （顺序影响行为）

区别

DOMAIN-SUFFIX 匹配的是域名后缀，覆盖范围更广（包括所有子域名）。
DOMAIN 匹配的是精确域名，覆盖范围更窄（仅限指定域名）。

行为

大多数软件的规则解析顺序: 许多工具（如 Surge、Clash、Adblock、uBlock Origin）按配置文件中规则的从上到下顺序进行匹配。也就是说，先出现的规则会优先被检查和应用。如果匹配成功，后续规则可能被忽略（除非软件支持多重匹配）。

哪个在前？

通用实践: 在大多数配置文件中，建议将更具体的规则（如 DOMAIN）写在前面，将更宽泛的规则（如 DOMAIN-SUFFIX）写在后面。原因如下：
- 精确匹配（DOMAIN）通常表示用户希望对特定域名进行特殊处理，优先级更高。
- 后缀匹配（DOMAIN-SUFFIX）覆盖范围广，适合作为“兜底”规则，处理未被精确匹配的子域名。
- 示例（推荐写法）：
```
DOMAIN,youtube.bo,YouTube
DOMAIN-SUFFIX,youtube.bo,YouTube
```
  这样可以确保 youtube.bo 被精确匹配的规则优先处理，而子域名（如 www.youtube.bo）由后缀规则处理。
例外情况: 如果软件明确要求按某种顺序（例如 Clash 或 Surge 的文档可能指定），需要遵循其规则。有些软件可能要求 DOMAIN-SUFFIX 优先，因为它覆盖范围更大。

进阶配置示例

如果你有多个节点，想自动选择延迟最低的，或者需要更复杂的规则，可以参考以下示例：

port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

proxies:
 - name: "ss1"
 type: ss
 server: example1.com
 port: 8388
 cipher: aes-256-gcm
 password: "yourpassword1"
 - name: "ss2"
 type: ss
 server: example2.com
 port: 8388
 cipher: aes-256-gcm
 password: "yourpassword2"

proxy-groups:
 - name: "auto"
 type: url-test  # 自动选择延迟最低的节点
 proxies:
 - "ss1"
 - "ss2"
 url: "http://www.gstatic.com/generate_204" # 测试延迟的 URL
 interval: 300 # 每 300 秒测试一次

rules:
 - DOMAIN-SUFFIX,google.com,auto
 - DOMAIN-SUFFIX,baidu.com,DIRECT
 - GEOIP,CN,DIRECT  # 中国 IP 直连
 - MATCH,auto  # 其他走 auto 组

常见问题

配置文件报错怎么办？
- 检查 YAML 格式是否正确，比如缩进必须是 2 个空格，不能用 Tab。
- 确保节点信息无误。
想添加更多规则怎么办？
- 可以参考 Clash 的官方文档，或者告诉我你的需求，我帮你写。
哪里找现成的规则？
- 网上有很多开源规则集，比如 GitHub 上，可以通过 Clash 的订阅功能导入。

一个clash配置的信息如下

port: 7890
socks-port: 7891
allow-lan: true
mode: Rule
log-level: info
external-controller: :9090
proxies:
 - {name: "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*", server: pfxwhz.cscsgsg.xyz, port: 16007, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: "🇬🇧 CN2-V229-英国-1x-NF&BBC*", server: epueyo.gxcvbmj.xyz, port: 58559, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇳🇱 CN2-V238-荷兰-1x-NF*, server: cyjsnl.ghskgvb.xyz, port: 20020, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇨🇦 CN2-V237-加拿大-1x, server: pfxwhz.cscsgsg.xyz, port: 12010, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*", server: fdksxn.kghkjasfh.xyz, port: 12232, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇳🇿 CN2-V339-新西兰-1x-NF*, server: fdksxn.kghkjasfh.xyz, port: 12233, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇸🇬 福利-V345-新加坡-0.1x-15M-NF, server: vdiogsnf.kghkjasfh.xyz, port: 12543, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇭🇰 福利-V234-香港-0.1x-15M-NF, server: vdiogsnf.kghkjasfh.xyz, port: 12544, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
 - {name: 🇭🇰 福利-V114-香港-0.1x-仅限emby, server: vdiogsnf.kghkjasfh.xyz, port: 12545, type: vmess, uuid: 4ed1483a-8bd9-3380-8d28-fa68243292ba, alterId: 0, cipher: auto, tls: false, skip-cert-verify: true, udp: true}
proxy-groups:
 - name: 🎞️ Prime Video
 type: select
 proxies:
 - 🇭🇰 香港
 - 🇺🇸 美国
 - 🇯🇵 日本
 - 🇸🇬 新加坡
 - 🇹🇼 台湾
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🎮👑👑 HBO MAX
 type: select
 proxies:
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 📹️ HBOGO Asia
 type: select
 proxies:
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 💿 AbemaTV
 type: select
 proxies:
 - "🇯🇵 IPLC-V316-日本-0.5x-50M-NF&Abema*"
 - "🇯🇵 IPLC-V315-日本-1x-NF&Abema*（ChatGPT动态解锁测试）"
 - "🇯🇵 IPLC-V353-日本-1x-NF&Abema*"
 - "🇯🇵 IPLC-V356-日本-4x-家宽-NF&Abema*"
 - "🇯🇵 IPLC-V364-日本-0.5x-50M-NF&Abema*"
 - "🇯🇵 IPLC-V365-日本-1x-NF&Abema*（ChatGPT动态解锁测试）"
 - "🇯🇵 IPLC-V366-日本-1x-NF&Abema*（ChatGPT动态解锁测试）"
 - "🇯🇵 IPLC-V240-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - name: 🔞 Pornhub
 type: select
 proxies:
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🎶 TikTok
 type: select
 proxies:
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - 🇭🇰 CN2-V241-香港-1x
 - "🇸🇬 CN2-V330-新加坡-1x-NF&Disney+*"
 - "🇸🇬 CN2-V347-新加坡-0.5x-NF&Disney+*"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🎧 Spotify
 type: select
 proxies:
 - 🚀 手动切换
 - 🎯 全球直连
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 CN2-V327-香港-1x-HKBN-NF&Disney*"
 - 🇭🇰 CN2-V346-香港-0.6x-HGC-NF*
 - 🇭🇰 CN2-V241-香港-1x
 - "🇸🇬 CN2-V330-新加坡-1x-NF&Disney+*"
 - "🇸🇬 CN2-V347-新加坡-0.5x-NF&Disney+*"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🎮️ 游戏平台
 type: select
 proxies:
 - 🎯 全球直连
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🤖 ChatGPT、Claude、Gemini、微软AI
 type: select
 proxies:
 - 🚀 手动切换
 - 🇺🇸 美国
 - 🇯🇵 日本
 - 🇸🇬 新加坡
 - 🇹🇼 台湾
 - 🎯 全球直连
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 CN2-V327-香港-1x-HKBN-NF&Disney*"
 - 🇭🇰 CN2-V346-香港-0.6x-HGC-NF*
 - 🇭🇰 CN2-V241-香港-1x
 - "🇸🇬 CN2-V330-新加坡-1x-NF&Disney+*"
 - "🇸🇬 CN2-V347-新加坡-0.5x-NF&Disney+*"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: Ⓜ️ 微软服务
 type: select
 proxies:
 - 🎯 全球直连
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - 🇭🇰 CN2-V321-香港-0.6x-NF
 - 🇭🇰 CN2-V322-香港-0.6x-NF
 - 🇭🇰 CN2-V325-香港-0.6x-NF
 - "🇭🇰 CN2-V326-香港-1x-HKBN-NF&Disney*"
 - "🇭🇰 CN2-V327-香港-1x-HKBN-NF&Disney*"
 - 🇭🇰 CN2-V346-香港-0.6x-HGC-NF*
 - 🇭🇰 CN2-V241-香港-1x
 - "🇸🇬 CN2-V330-新加坡-1x-NF&Disney+*"
 - "🇸🇬 CN2-V347-新加坡-0.5x-NF&Disney+*"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 📲 电报信息
 type: select
 proxies:
 - 🚀 手动切换
 - ♻️ 自动选择
 - 🎯 全球直连
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - 🇭🇰 CN2-V346-香港-0.6x-HGC-NF*
 - 🇭🇰 CN2-V241-香港-1x
 - "🇸🇬 CN2-V330-新加坡-1x-NF&Disney+*"
 - "🇸🇬 CN2-V347-新加坡-0.5x-NF&Disney+*"
 - 🇺🇸 CN2-V216-美国-1x-NF
 - 🇺🇸 CN2-V215-美国-2x-NF
 - "🇺🇸 CN2-V213-美国-1x-NF&HBO&Hulu&Disney*"
 - "🇺🇸 CN2-V212-美国-1x-NF&HBO&Hulu*"
 - "🇺🇸 CN2-V217-美国-1x-NF&Disney"
 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🍎 苹果服务
 type: select
 proxies:
 - 🎯 全球直连
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V305-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V306-香港-1x-NF&Disney*"
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 📢 谷歌FCM
 type: select
 proxies:
 - 🚀 手动切换
 - 🎯 全球直连
 - ♻️ 自动选择
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🎯 全球直连
 type: select
 proxies:
 - DIRECT
 - 🚀 手动切换
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V305-香港-1x-NF&Disney*"
 - 🇸🇬 IPLC-V101-新加坡-1x
 - 🇸🇬 IPLC-V102-新加坡-1x
 - 🇰🇷 IPLC-V320-韩国-1x-NF
 - 🇰🇷 IPLC-V230-韩国家宽-1x-NF*
 - "🇺🇸 IPLC-V350-美国-1x-NF&HBO&Disney*"
 - "🇺🇸 IPLC-V351-美国-2x-夏威夷-NF&HBO"
 - "🇺🇸 IPLC-V355-美国-4x-家宽-NF&HBO&Disney*"
 - "🇺🇸 IPLC-V371-美国-1x-NF&HBO&Disney*"
 - "🇺🇸 IPLC-V372-美国-1x-NF&HBO&Disney*"
 - "🇺🇸 IPLC-V373-美国Starlink-8x-NF&HBO&Disney*"
 - "🇺🇸 IPLC-V374-美国家宽-4x-NF&HBO&Disney*"

 - 🇺🇸 CN2-V211-美国-1x-NF*
 - "🇯🇵 CN2-V227-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V228-日本-1x-NF&Abema*"
 - "🇯🇵 CN2-V328-日本-0.5x-NF&Abema*"
 - "🇯🇵 CN2-V329-日本-0.5x-NF&Abema*"
 - "🇬🇧 CN2-V229-英国-1x-NF&BBC*"
 - 🇳🇱 CN2-V238-荷兰-1x-NF*
 - 🇨🇦 CN2-V237-加拿大-1x
 - "🇦🇺 CN2-V338-澳大利亚-1x-NF&7plus*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
 - name: 🐟 漏网之鱼
 type: select
 proxies:
 - 🚀 手动切换
 - 🎯 全球直连
 - "🇭🇰 IPLC-V301-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V302-香港-1x-NF&Disney"
 - "🇭🇰 IPLC-V303-香港-1x-NF&Disney*"
 - "🇭🇰 IPLC-V304-香港-1x-NF&Disney*"
 - 🇳🇿 CN2-V339-新西兰-1x-NF*
 - 🇸🇬 福利-V345-新加坡-0.1x-15M-NF
 - 🇭🇰 福利-V234-香港-0.1x-15M-NF
 - 🇭🇰 福利-V114-香港-0.1x-仅限emby
rules:
 - DOMAIN,apple.comscoreresearch.com,🍎 苹果服务
 - DOMAIN-SUFFIX,aaplimg.com,🍎 苹果服务
 - DOMAIN-SUFFIX,akadns.net,🍎 苹果服务
 - DOMAIN-SUFFIX,apple-cloudkit.com,🍎 苹果服务
 - DOMAIN-SUFFIX,apple-dns.net,🍎 苹果服务
 - DOMAIN-SUFFIX,apple-mapkit.com,🍎 苹果服务
 - DOMAIN-SUFFIX,apple.co,🍎 苹果服务
 - DOMAIN-SUFFIX,apple.com,🍎 苹果服务
 - DOMAIN-SUFFIX,apple.com.cn,🍎 苹果服务
 - DOMAIN-SUFFIX,apple.news,🍎 苹果服务
 - DOMAIN-SUFFIX,appstore.com,🍎 苹果服务
 - DOMAIN-SUFFIX,cdn-apple.com,🍎 苹果服务
 - DOMAIN-SUFFIX,crashlytics.com,🍎 苹果服务
 - DOMAIN-SUFFIX,icloud-content.com,🍎 苹果服务
 - DOMAIN-SUFFIX,icloud.com,🍎 苹果服务
 - DOMAIN-SUFFIX,icloud.com.cn,🍎 苹果服务
 - DOMAIN-SUFFIX,itunes.com,🍎 苹果服务
 - IP-CIDR,13.245.112.0/23,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.114.0/24,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.127.232/30,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.155.128/27,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.155.224/27,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.166.128/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.245.166.176/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.248.224.0/21,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.248.232.0/23,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.250.186.0/28,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.250.186.16/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.250.186.128/26,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.250.186.192/28,🎥 NETFLIX,no-resolve
 - IP-CIDR,13.250.186.208/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.152.10.0/24,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.152.24.0/26,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.152.24.128/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.160.55.112/29,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.161.66.0/25,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.161.66.128/26,🎥 NETFLIX,no-resolve
 - IP-CIDR,15.161.135.64/26,🎥 NETFLIX,no-resolve
 - DOMAIN-SUFFIX,dlandroid.rcv.sandai.net,🚀 手动切换
 - DOMAIN-SUFFIX,hub5idx.v6.shub.sandai.net,🚀 手动切换
 - DOMAIN-SUFFIX,hub5pn.wap.sandai.net,🚀 手动切换
 - DOMAIN-SUFFIX,hub5pnc.sandai.net,🚀 手动切换
 - DOMAIN-SUFFIX,hub5pr.v6.phub.sandai.net,🚀 手动切换
 - DOMAIN-SUFFIX,hubciddata.sandai.net,🚀 手动切换
 - DOMAIN-KEYWORD,mypikpak,🚀 手动切换
 - DOMAIN-SUFFIX,acl4.ssr,🎯 全球直连
 - DOMAIN-SUFFIX,ip6-localhost,🎯 全球直连
 - IP-CIDR6,::1/128,🎯 全球直连,no-resolve
 - IP-CIDR6,fc00::/7,🎯 全球直连,no-resolve
 - DOMAIN,instant.arubanetworks.com,🎯 全球直连
 - DOMAIN,setmeup.arubanetworks.com,🎯 全球直连
 - DOMAIN,router.asus.com,🎯 全球直连
 - DOMAIN,www.asusrouter.com,🎯 全球直连
 - DOMAIN-SUFFIX,hiwifi.com,🎯 全球直连
 - DOMAIN-SUFFIX,leike.cc,🎯 全球直连
 - DOMAIN-SUFFIX,cm.steampowered.com,🎯 全球直连
 - DOMAIN-SUFFIX,steamchina.com,🎯 全球直连
 - IP-CIDR,8.128.0.0/10,🎯 全球直连,no-resolve
 - DOMAIN-SUFFIX,smtp,🎯 全球直连
 - DOMAIN-KEYWORD,aria2,🎯 全球直连
 - PROCESS-NAME,Weiyun.exe,🎯 全球直连
 - PROCESS-NAME,baidunetdisk.exe,🎯 全球直连
 - DOMAIN,alt1-mtalk.google.com,📢 谷歌FCM
 - DOMAIN,alt8-mtalk.google.com,📢 谷歌FCM
 - DOMAIN,mtalk.google.com,📢 谷歌FCM
 - IP-CIDR,64.233.177.188/32,📢 谷歌FCM,no-resolve
 - IP-CIDR,64.233.186.188/32,📢 谷歌FCM,no-resolve
 - GEOIP,CN,🎯 全球直连
 - MATCH,🐟 漏网之鱼

Nginx

Mon, 24 Feb 2025 00:00:00 +0000

Nginx 详细使用教程

引言：Nginx 核心概念与架构概览

Nginx 作为一款高性能的开源 Web 服务器和反向代理服务器，自 2002 年由 Igor Sysoev 创建以来，其设计初衷便是为了解决著名的“C10K 问题”——即如何在单台服务器上同时处理上万个并发连接 [1]。与传统的 Web 服务器相比，Nginx 的核心优势在于其轻量级、高稳定性、低资源占用和强大的高并发处理能力 [1]。它所扮演的角色远不止于 Web 服务器，还广泛应用于反向代理、负载均衡、HTTP 缓存等关键领域 [1]。Nginx 能够实现如此卓越性能的根本原因，在于其底层架构的独特设计，即异步非阻塞事件驱动模型和主/工作进程模型。

1.1 异步非阻塞事件驱动模型深度解析

传统的 Web 服务器通常采用“多进程/多线程阻塞 I/O”模型，即每一个客户端连接都由一个独立的进程或线程来处理 [3]。这种模型在并发连接数较低时工作良好，但当面对海量并发连接时，服务器会因创建和销毁大量进程/线程、以及频繁的上下文切换而导致 CPU 资源被大量消耗在调度而非实际工作上 [3]。

Nginx 彻底颠覆了这种模式。它采用了一种事件驱动模型，其核心思想是“将等待责任交由应用层”，即服务器不会阻塞等待 I/O 操作（例如从网络套接字读取数据或向磁盘写入文件），而是在 I/O 就绪时，通过操作系统提供的事件通知机制（如 Linux 上的 epoll、BSD 上的 kqueue）来被唤醒并处理 [3]。这意味着 Nginx 的少数几个工作进程（Worker Process）就能够高效地处理成千上万个并发连接。其高性能的本质并非源于单个进程的超高计算能力，而是其架构从根本上避免了传统模型在高并发下必然出现的瓶颈，从而在有限的系统资源下实现了高度的并行处理 [3]。

1.2 主/工作进程（Master/Worker）架构模型

Nginx 的运行模型由一个主进程（Master Process）和多个工作进程（Worker Process）组成 [4]。主进程的主要职责是管理工作进程、读取和解析配置文件、处理外部信号（如 reload、stop）以及进行无停机升级 [4]。它本身不直接处理任何网络请求，而是作为整个 Nginx 服务的“指挥中心”存在 [4]。

工作进程则是 Nginx 的“执行者”，每个工作进程都是独立运行的，负责处理来自客户端的所有连接和请求 [4]。由于工作进程之间相互独立，它们在处理请求时无需依赖复杂的加锁机制，这不仅减少了锁带来的开销，也极大地简化了编程和问题排查 [5]。当一个工作进程因某个请求而崩溃时，并不会影响到其他工作进程的正常运行，主进程能够迅速感知到异常并拉起一个新的工作进程来顶替 [5]。这种优雅的进程管理模式不仅提升了服务的稳定性和容错能力，也使得 无中断配置重载（nginx -s reload）和 平滑升级 成为可能，极大地保障了线上服务的可用性 [5]。

第一部分：Nginx 的安装与基础管理

本节将提供在不同主流操作系统上部署 Nginx 的详细指南，并介绍其基础管理命令。

2.1 基于包管理器的快速部署

对于大多数 Linux 发行版，使用其自带的包管理器是安装 Nginx 最便捷的方式。

在 Ubuntu/Debian 上： 首先，更新本地的软件包索引以确保获取最新的软件列表，然后通过 apt 命令安装 Nginx [8]。

sudo apt update
sudo apt install nginx

安装完成后，如果服务器启用了防火墙（如 ufw），需要允许 HTTP 和 HTTPS 流量通过。Nginx 在安装时会注册相应的防火墙配置文件，可以使用 sudo ufw allow 'Nginx Full' 来同时开启 80 和 443 端口 [8]。

在 CentOS/RHEL 上： Nginx 在 CentOS 的默认仓库中可能不是最新版本，因此通常建议先添加 EPEL（Extra Packages for Enterprise Linux）软件仓库 [9]。

sudo yum install epel-release
sudo yum install nginx

对于使用了 firewalld 的系统，需要手动添加 HTTP/HTTPS 服务的永久规则并重新加载防火墙 [10]。

2.2 从源码编译安装：定制化与模块化

源码编译是另一种常见的安装方式，它提供了高度的灵活性和可定制性，能够根据具体需求选择和编译特定的功能模块 [9]。

在编译前，需要安装一系列依赖库。Nginx 是用 C 语言开发的，因此需要 gcc 编译环境 [9]。此外，一些核心功能也依赖于外部库：

PCRE (Perl Compatible Regular Expressions)：Nginx 的 http 模块使用 PCRE 库来解析正则表达式，例如在 location 匹配和 rewrite 规则中 [9]。
zlib：用于支持 HTTP 数据包的 Gzip 压缩功能 [9]。
OpenSSL：Nginx 支持 https 协议，因此需要 OpenSSL 库来提供加密算法和 SSL 协议支持 [9]。

在 CentOS 下，可以使用 yum 命令一次性安装所有依赖 [9]：

sudo yum install -y gcc pcre pcre-devel zlib zlib-devel openssl openssl-devel

在 Ubuntu 下，则使用 apt [11]。

安装依赖后，可以从 Nginx 官网下载源码包，然后进行配置、编译和安装 [9]。在 ./configure 阶段，可以根据需要添加或删除模块。例如，要启用 HTTPS 支持，必须在配置参数中包含 --with-http_ssl_module [11]。如果编译时缺少该模块，即使在配置文件中正确设置了 HTTPS，Nginx 在启动时也会报错 https protocol requires SSL support [12]。这揭示了一个重要的事实：仅仅修改配置文件是不够的，理解 Nginx 的模块化设计及其编译依赖关系是解决许多深层次问题的关键 [11]。

2.3 Nginx 服务基础操作与管理

Nginx 服务可以通过多种方式进行管理。

使用 systemctl： 这是现代 Linux 系统管理服务的主流方式。

启动： sudo systemctl start nginx [8]
停止： sudo systemctl stop nginx [8]
重启： sudo systemctl restart nginx [8]
重载： sudo systemctl reload nginx，此命令会在不中断现有连接的情况下，重新加载配置文件并使之生效 [8]。

使用 Nginx 自身命令：

nginx -s stop：快速停止服务 [14]。
nginx -s reload：重载配置文件 [7]。

在进行任何服务重载或重启之前，务必使用 nginx -t 命令来测试配置文件的语法正确性。该命令不仅会检查语法，还会尝试打开配置文件中引用到的文件 [7]。这是避免因配置错误导致服务中断的关键步骤。

第二部分：精通 Nginx 配置文件（nginx.conf）

Nginx 的核心在于其配置文件 nginx.conf，它决定了 Nginx 的所有行为。该文件采用 Nginx 自定的语法，以 # 声明单行注释，每条指令以 ; 结尾 [17]。

3.1 配置文件层级结构深度解析

nginx.conf 的结构是分层嵌套的，主要分为以下几个区块 [17]：

main（全局块）： 位于配置文件的最外层，用于设置影响 Nginx 服务器整体运行的指令，例如定义运行 Nginx 的用户和用户组（user），以及工作进程数（worker_processes）[18]。
events： 此区块的指令主要影响 Nginx 服务器与用户的网络连接，例如设置每个工作进程可以支持的最大连接数（worker_connections）和选择事件驱动模型（use epoll）[18]。
http： 用于配置 HTTP 协议相关的指令，例如设定 MIME 类型、日志格式、文件编码以及启用 Gzip 压缩等 [19]。http 块内部可以包含多个 server 块。
server： 用于定义一个虚拟主机，它可以监听特定的端口和域名，处理相应的 HTTP 请求 [17]。http 块中至少需要定义一个 server 块才能处理请求 [17]。
location： server 块中的核心指令，用于根据请求的 URI 对请求进行路由处理 [17]。一个 server 块中可以包含多个 location 块 [17]。

3.2 location 匹配规则与优先级

location 指令是 Nginx 配置的精髓，它负责根据请求 URI 来决定如何处理请求。Nginx 的 location 匹配遵循一套严格的优先级规则，这对于避免配置冲突至关重要。理解这套规则，能够将配置从简单的指令堆砌提升为一种精巧的“路由艺术” [19]。

Nginx 优先选择精确匹配，其次是前缀匹配，最后是正则表达式匹配。不同前缀的匹配规则和优先级如下：

匹配前缀	匹配规则	优先级	典型应用场景
`=`	精确匹配。如果 URI 严格匹配，则停止搜索。	1	快速处理根路径（`/`）的请求，例如 `location = /`。
`^~`	普通字符串前缀匹配。如果匹配成功，则停止搜索。	2	强制匹配特定目录，例如 `location ^~ /images/`，以避免被优先级更低的正则匹配覆盖。
`~`	区分大小写的正则表达式匹配。	3	处理特定的文件类型或包含特定模式的 URI。
`~*`	不区分大小写的正则表达式匹配。	4	匹配文件扩展名，例如 `location ~* .(jpg
无前缀	普通字符串前缀匹配。	5	默认匹配规则，例如 `location /documents/`，但会继续查找更精确的匹配。
`/`	通用匹配。任何请求都会匹配到该规则，作为最后的“捕获”规则。	6	通常用于将所有未被其他规则匹配到的请求转发给后端应用服务器。

需要注意的是，location 优先级是初学者最容易犯错的地方。例如，一个看似合理的正则匹配规则（location ~ \.html$）可能会被一个优先级更高的普通匹配规则（location ^~ /documents/）覆盖，导致期望的配置无法生效 [22]。而 ^~ 的引入正是为了提供这种强制停止匹配的能力，确保某些路径（如静态资源路径）能够被确定性地处理 [19]。

3.3 Nginx 内置变量与自定义变量

Nginx 提供了丰富的内置变量，可以用来获取和操作请求、响应、服务器环境等信息 [14]。这些变量以 $ 符号开头。

变量名	描述	应用示例
`$request_uri`	包含请求参数的原始 URI，如 “/foo/bar.php?arg=baz”	`return 200 '$request_uri';`
`$uri`	不带请求参数的当前 URI，如 “/foo/bar.html”	`return 200 '$uri';`
`$remote_addr`	客户端的 IP 地址	`proxy_set_header X-Real-IP $remote_addr;`
`$remote_port`	客户端的端口号	`return 200 '$remote_port';`
`$server_name`	服务器的名称，取决于 `server{}` 模块中配置的 `server_name`	`proxy_set_header Host $server_name;`
`$server_addr`	服务器的 IP 地址	`return 200 '$server_addr';`
`$server_port`	请求到达服务器的端口号	`return 200 '$server_port';`
`$request_method`	客户端请求的动作，通常为 GET 或 POST	`if ($request_method = POST) {... }`
`$host`	请求头中的 Host 字段	`proxy_set_header Host $host;`

除了内置变量，Nginx 也支持使用 set 指令来自定义变量，例如 set $port_type 8x; [17]。需要注意的是，set 指令不能用于给 Nginx 的内置变量赋值 [17]。

第三部分：Nginx 核心功能详解与实战

本节将详细阐述 Nginx 最核心的三大功能，并提供可直接使用的配置示例。

4.1 作为 Web 服务器：静态文件托管与虚拟主机

Nginx 凭借其高效的静态文件服务能力，被广泛用作 Web 服务器。

静态文件托管： 使用 root 或 alias 指令可以轻松配置静态文件服务。例如，location /images/ { root /data; } 将 /images/ 路径下的请求映射到服务器文件系统中的 /data/images/ 目录 [14]。这种 动静分离 的策略是 Nginx 的重要应用，它将动态请求（如 *.php）交给后端应用服务器处理，而由 Nginx 直接处理静态资源（如图片、CSS、JS），从而显著减轻后端服务器的负载 [1]。
虚拟主机配置： Nginx 允许在同一台物理服务器上托管多个网站。通过在 http 块中定义多个 server 块，每个 server 块通过 server_name 和 listen 指令监听不同的域名或端口，从而实现虚拟主机功能 [21]。

4.2 作为反向代理服务器

反向代理是 Nginx 最强大、最常用的功能之一 [2]。与正向代理（隐藏客户端信息）不同，反向代理（Reverse Proxy） 将客户端的请求转发给其背后的一个或多个后端服务器，从而隐藏了后端服务器的真实信息，并作为客户端与后端服务器之间的“中间人” [2]。

核心指令 proxy_pass： 该指令用于将请求转发到指定的后端服务器 URL [21]。例如，将 www.123.com 的请求代理到本地运行在 8080 端口的 Tomcat 服务器 [21]：
```
server {
 listen 80;
 server_name www.123.com;
 location / {
 proxy_pass http://127.0.0.1:8080;
 }
}
```
代理请求头配置： 在进行反向代理时，为了确保后端服务器能正确获取客户端的真实信息，通常需要配置代理请求头 [14]。例如，proxy_set_header Host $host; 和 proxy_set_header X-Real-IP $remote_addr; 分别用于将原始的 Host 头和客户端真实 IP 传递给后端服务器 [14]。

4.3 作为负载均衡器

在服务器集群环境中，Nginx 的负载均衡功能可以将请求分发到集群中的不同服务器，以实现流量的均衡和高可用性 [2]。

核心模块 upstream： upstream 指令用于定义后端服务器集群，并可以配置服务器的 IP 地址、端口和权重等参数 [14]。
```
upstream dramatic-offical-website {
 server 10.192.106.133;
 server 10.192.106.134;
}
server {
 server_name test-openai.com;
 listen 80;
 location / {
 proxy_pass http://dramatic-offical-website;
 }
}
```
上述配置将 test-openai.com 的请求代理到 dramatic-offical-website 集群，由 Nginx 根据负载均衡算法分发到 10.192.106.133 或 10.192.106.134 [14]。

负载均衡算法： Nginx 内置了多种负载均衡算法 [6]：

算法名称	工作原理	优缺点	典型应用场景
轮询 (round-robin)	默认算法。按时间顺序依次将请求分配给后端服务器，如果某个服务器宕机，会自动剔除。	优点：简单、无需配置。缺点：无法处理每台服务器的性能差异，容易导致性能较弱的服务器过载。	适用于后端服务器性能相同、并发量较小的场景。
加权轮询 (weight)	在轮询的基础上，为每个服务器设置一个权重（`weight`）。权重越高的服务器，被分配到请求的几率越大。	优点：能够根据服务器的性能差异进行流量分配。缺点：如果权重设置不合理，仍可能导致流量分配不均。	适用于后端服务器性能存在差异，需要手动调整流量分配的场景。
IP 哈希 (ip_hash)	根据客户端的 IP 地址进行哈希计算，将同一 IP 的所有请求固定地分发到同一台后端服务器。	优点：完美解决了 session 会话持久化问题。缺点：如果某些 IP 的请求量特别大，可能导致特定服务器的负载过高，造成负载不均衡。	适用于需要保持用户会话状态，且流量分布相对均匀的业务场景，如电商网站的购物车功能。

第四部分：高级功能与性能调优

5.1 HTTPS 安全配置

为网站启用 HTTPS 是保护数据传输安全和提升用户信任度的关键步骤 [25]。

手动部署 SSL/TLS 证书： 首先，需要获取 SSL/TLS 证书文件（.crt 或 .pem）和私钥文件（.key）[11]。然后，在 Nginx 的配置文件中进行如下配置 [11]：
```
server {
 listen 443 ssl;
 server_name your_domain.com;
 ssl_certificate /path/to/your/certificate.crt;
 ssl_certificate_key /path/to/your/private.key;
 ...
}
```
此配置指示 Nginx 在 443 端口上监听 HTTPS 流量，并使用指定的证书和私钥。
使用 Certbot 自动化配置： 对于个人网站或小型项目，Let’s Encrypt 提供了免费的 SSL/TLS 证书，并且可以通过 Certbot 工具实现自动化申请和续期 [25]。在 Ubuntu 上，可以安装 Certbot 及其 Nginx 插件 [25]：
```
sudo apt install certbot python3-certbot-nginx
```
然后运行以下命令，Certbot 将自动获取证书并配置 Nginx：
```
sudo certbot --nginx -d example.com -d www.example.com
```
Certbot 还会自动设置一个定时任务来在证书过期前自动续期，极大地简化了维护工作 [25]。

5.2 Nginx 缓存机制（proxy_cache）

Nginx 的缓存机制是作为反向代理提升性能最有效的手段之一，其核心思想是“用空间换时间” [24]。通过将后端服务器的响应缓存到 Nginx 的磁盘上，可以显著减少对后端服务器的请求次数，从而减轻其负载并缩短响应时间 [24]。

核心指令： proxy_cache_path 用于定义缓存目录的路径和配置参数，例如缓存级别（levels）、共享内存区大小（keys_zone）、最大缓存空间（max_size）和缓存项的非活动时间（inactive）[24]。proxy_cache 则用于在 http、server 或 location 块中启用缓存 [24]。
缓存策略： 通过 proxy_cache_valid、proxy_no_cache、proxy_cache_bypass 等指令，可以精细地控制缓存行为，例如设置特定响应码的缓存时间，或者不缓存包含特定 Cookie 的请求 [24]。

5.3 性能优化：Gzip 压缩

Gzip 压缩可以显著减少网络传输的数据量，从而加快页面加载速度 [19]。Nginx 提供了 gzip on 指令来开启此功能 [19]。然而，大多数教程只简单地教导开启 Gzip，而忽略了其在高并发场景下的潜在性能开销。

对于静态文件，Nginx 默认采用 动态 Gzip 压缩，即在每次请求时实时压缩文件 [28]。当面对海量并发请求时，这种实时压缩会消耗大量的 CPU 资源，从而成为性能瓶颈 [28]。

一个真实的案例表明，通过将动态 Gzip 压缩改为 静态 Gzip 压缩，可以获得巨大的性能提升 [28]。其核心思想是：在部署时，预先将静态文件压缩成 .gz 格式，然后配置 Nginx 使用 gzip_static on 指令 [28]。这样，Nginx 在处理请求时会直接提供预先压缩好的文件，完全避免了实时的压缩计算开销 [28]。这种优化手段可以将 CPU 利用率从 90% 降至 7%，同时将吞吐量（QPS）提升 5 倍以上，是一种极为重要的性能调优手段 [28]。

第五部分：常见问题排查与故障诊断

6.1 日志分析：故障排查的起点

Nginx 的日志文件是排查故障的首要工具。默认情况下，Nginx 的日志文件位于 /var/log/nginx/ 目录下，其中 access.log 记录所有访问请求，error.log 记录所有错误和警告信息 [16]。如果日志路径被修改，可以通过 cat /etc/nginx/nginx.conf | grep 'access_log' 命令来查找 [29]。

在查看日志时，可以使用不同的命令来满足不同的需求 [16]：

cat：用于查看整个文件的内容。
less：用于分页查看大型日志文件。
tail -f：用于实时监控日志文件的更新，这在故障复现和问题诊断时非常有用。

6.2 常见错误代码与解决方案

当 Nginx 出现问题时，错误代码是重要的诊断线索。一个结构化的诊断流程能够帮助用户从根本上解决问题，而不是治标不治本。

错误代码	常见原因	诊断与解决方案
403 Forbidden	Nginx 进程没有权限访问请求的资源文件或目录。	检查 Nginx 配置文件中的 `user` 指令是否正确配置，并确保 Nginx 启动用户拥有目标目录的读写权限。如果权限不足，可以使用 `sudo chown -R nginx:nginx /path/to/directory` 修改文件或目录的所有者 [12]。
413 Request Entity Too Large	客户端上传文件的大小超过了 Nginx 的默认限制。	这个错误直接指向 Nginx 的配置问题。需要在 `http`、`server` 或 `location` 块中，增加 `client_max_body_size` 指令的值，例如 `client_max_body_size 100m;` [13]。
502 Bad Gateway	Nginx 作为反向代理，无法从后端服务器获取有效响应。这通常是后端服务器故障的信号，而不是 Nginx 本身的问题。	这类问题可能由多种原因引起： 1. 后端服务器宕机：检查后端应用服务是否正常运行。 2. 磁盘空间不足：后端服务器磁盘空间不足可能导致写缓存失败，使用 `df -h` 命令检查磁盘空间 [31]。 3. php-cgi 进程数不够：对于 PHP 网站，后端进程池数量可能不足以处理请求。需要增加 `php-fpm.conf` 文件中的 `pm.max_children` 参数值 [31]。 4. 后端执行超时：如果后端应用处理时间过长，可能导致 Nginx 超时。可以在 Nginx 配置文件中适当增加 `proxy_read_timeout` 和 `proxy_send_timeout` 等超时时间 [31]。
504 Gateway Timeout	Nginx 在指定时间内未从后端服务器获得响应，通常由后端应用执行缓慢或超时引起。	检查后端应用的性能和日志。如果后端确实执行缓慢，可以考虑优化应用代码或增加服务器资源。同时，可以在 Nginx 配置文件中增加 `proxy_connect_timeout`、`proxy_send_timeout` 和 `proxy_read_timeout` 等超时时间 [8]。

腾讯云修改为root登录

Mon, 24 Feb 2025 00:00:00 +0000

sudo passwd root
sudo vim /etc/ssh/sshd_config
# 修改 PermitRootLogin yes
sudo systemctl restart ssh

如果需要通过密钥登录root,最好使用ssh-copy-id, 我试过自己粘贴,很麻烦