在云服务器上部署宝塔面板后，很多新手用户会遇到一个看似矛盾的现象：

• 宝塔面板中显示系统防火墙处于关闭状态。
• 但每次开放新端口时，仍然必须前往云控制台的安全组中添加规则。
• 如果只在宝塔中操作，端口始终无法访问。

这引出一个常见疑问：宝塔面板的防火墙能否替代云安全组？

答案是：不能。二者处于不同层级，职责独立，无法互相替代。

两层防火墙的层级关系

云服务器的网络访问控制实际上分为两层：

1. 云平台层：安全组（Security Group）
   由云服务商（如腾讯云、阿里云）提供，运行在服务器外部的网络层。它在流量到达服务器之前进行过滤，不由服务器操作系统或宝塔面板控制。

2. 操作系统层：系统防火墙
   运行在服务器内部，常见实现为 firewalld 或 iptables。宝塔面板的“安全”页面管理的正是这一层。它只处理已经通过云平台安全组、到达服务器的流量。

流量进入服务器的实际顺序如下：

用户请求
   ↓
云平台安全组（第一层）
   ↓
服务器操作系统
   ↓
系统防火墙 / 宝塔防火墙（第二层）
   ↓
Web 服务（Nginx / Apache 等）

为什么宝塔防火墙无法替代安全组

关键点在于流量经过的先后顺序：

• 如果云平台安全组未放行某个端口，流量根本到不了服务器，系统防火墙无论是否放行都无意义。
• 如果安全组已放行，但系统防火墙开启且未放行该端口，流量仍会被拦截。
• 只有当两层都放行（或系统防火墙关闭）时，端口才能真正可访问。

因此，宝塔面板的防火墙只能控制第二层，对第一层的安全组没有任何操作权限。

为什么宝塔显示防火墙关闭，反而简化了操作

当宝塔面板显示系统防火墙未开启时，意味着第二层没有进行拦截。此时只需在腾讯云安全组中放行端口，即可实现访问。

这也是许多用户选择保持系统防火墙关闭的原因：操作路径更短，只需维护一层规则。

但从安全角度看，这种配置缺少纵深防御。一旦安全组规则出现疏漏，服务器将直接暴露。

推荐的配置方式

更稳妥的做法是两层同时启用，并保持规则一致：

这样做的好处是形成纵深防御：即使某一层配置出现疏漏，另一层仍能提供保护。

代价是每开放一个新端口，需要在两个位置分别操作，维护成本略高。

对比总结

结论

• 腾讯云安全组与宝塔防火墙是两层独立、职责不同的访问控制机制，不能互相替代。
• 流量先经过安全组，再经过系统防火墙；任一层未放行，端口均不可访问。
• 宝塔显示防火墙关闭，仅表示第二层未启用，并不意味着服务器没有防火墙保护。
• 追求操作简便可只维护安全组；追求安全性建议两层同时启用并保持规则一致。

理解这两层的关系，可以避免在端口开放问题上反复排查，也有助于建立更清晰的云服务器安全模型。

最近在 GitHub 上看到一个不错的开源项目，想自己改着玩玩，顺便把代码托管到国内的 Gitee 上。作为一个 Git 小白，这一路遇到了不少坑，特此记录成文，希望能帮到同样刚接触 Git 的朋友。

二、准备工作

在开始之前，你需要准备好以下三样东西：

三、完整操作步骤

第 1 步：在 Gitee 上创建远程仓库

1. 登录 Gitee，点击右上角的 "+" 号，选择 "新建仓库"。
2. 填写仓库名称（比如 test_myfirst），建议用英文，不要用中文。
3. 建议先不要勾选"使用 Readme 文件初始化这个仓库"，保持仓库为空，避免后续推送时产生冲突。
4. 如果账号要求 2FA（两步验证），可以先选"私有"创建，创建成功后去仓库设置里改成"公开"。
5. 点击"创建"，保存好仓库地址（类似 https://gitee.com/你的用户名/仓库名.git），后面要用。

💡 为什么起英文名？ Gitee 的仓库名只支持字母、数字、下划线和连字符，不支持中文和空格。

第 2 步：初始化本地 Git 仓库

在你的项目文件夹里，右键空白处，选择 Git Bash Here（或使用 Windows PowerShell 终端）。

依次执行以下命令：

# 1. 初始化 Git 仓库（在本地建立版本管理）
git init

# 2. 配置用户身份（这一步必须做，否则无法提交）
git config --global user.name "你的Gitee用户名"
git config --global user.email "你的邮箱@qq.com"

💡 这一步的作用： git init 会在当前文件夹创建一个 .git 隐藏文件夹，Git 的所有版本记录都存放在这里。

第 3 步：添加文件并提交到本地仓库

# 1. 把所有文件添加到暂存区
git add .

# 2. 提交到本地仓库
git commit -m "首次提交"

💡 命令解释：

• git add . ：. 代表当前文件夹下的所有文件，会把所有改动都放到暂存区。
• git commit -m "xxx" ：-m 是 message（备注）的缩写，后面跟的是本次提交的说明。

可能遇到的问题：

如果执行 git commit 时报错：

Author identity unknown
*** Please tell me who you are.

说明你没有设置用户身份，执行第 2 步的 git config 命令即可解决。

第 4 步：关联远程仓库并推送

# 1. 添加远程仓库地址
git remote add origin https://gitee.com/你的用户名/你的仓库名.git

# 2. 推送到远程仓库
git push -u origin master

💡 为什么叫 origin？ origin 是 Git 默认的远程仓库别名，"源头"，你也可以理解成给远程地址起了一个昵称。

第 5 步：解决推送过程中可能遇到的报错

报错 1：remote origin already exists

原因： 之前已经关联过远程仓库（比如项目是从 GitHub 克隆下来的，默认指向 GitHub）。

解决方法： 先查看当前关联的地址：

git remote -v

如果地址不对，修改为新的 Gitee 地址：

git remote set-url origin https://gitee.com/你的用户名/你的仓库名.git

报错 2：error: src refspec master does not match any

原因： 本地分支名不是 master，主流平台的默认分支名是 main。

解决方法： 把 master 改成 main：

git push -u origin main

报错 3：failed to push some refs

原因： 远程仓库有文件（比如创建时勾选了 Readme 初始化），和本地冲突。

解决方法： 先拉取远程内容再推送：

git pull --rebase origin main
git push -u origin main

四、常用命令速查表

五、总结

回顾整个流程，其实就三步核心操作：

git add .
git commit -m "说明"
git push

理解这三条命令的含义，你就能应对绝大多数日常代码托管需求。遇到报错不要慌，看清错误提示，再结合 git remote -v 等命令检查当前状态，基本都能解决。

希望这篇文章能帮到你。如有其他问题，欢迎在评论区交流讨论！

一次 5GB 数据的跨服务器迁移，在源端带宽仅 5Mbps 的限制下，通过分片并发将传输效率推到带宽上限。

一、背景与约束

我维护了一个自托管的 RustFS 服务（兼容 S3 API / MinIO），主要用于存储学习教育相关的音频文件（单词/例句 MP3，约 5GB），支撑着一个小型在线教育应用。
由于旧服务器即将下线，需要将全部数据迁移到新服务器。但面临两个硬约束：

如果使用最直接的 scp 单连接传输，理论极限速度约 625KB/s，3.5GB 压缩包需要 1.5~2 小时。在真实的公网环境下，TCP 拥塞控制、丢包重传等因素会进一步拖慢速度，且一旦 SSH 断开，传输即中断，需要从头再来。

这意味着：需要一种能跑满 5Mbps 带宽、且具备中断可恢复能力的传输方案。

二、方案选型

2.1 备选方案

2.2 选择理由

split + 并发 scp 的核心思路是：将大文件切分为多个分片，每个分片通过独立的 SSH 连接并行传输。

这样做有两个收益：

1. 多连接并发：通过建立多个 TCP 连接，减小单连接受 BDP（带宽延迟积）限制的影响，将带宽利用率从约 60% 提升到 95% 以上；
2. 可观测性：每个分片独立传输，可以清晰看到各分片的进度，方便排查慢连接。

三、关键设计决策

3.1 为什么先打包再分片？

原始数据是 5GB 的目录树，包含数千个 MP3 小文件。如果直接分片目录，会产生两个问题：

• 每个小文件都需要建立 SSH 连接，握手开销远大于传输本身；
• 文件分配不均衡，无法控制每个分片的大小。

因此选择 先 tar 打包成单文件，再 split 切分，将小文件的元数据开销摊销到一次打包中。

3.2 分片大小为什么选 500MB？

这是一个需要权衡的参数：

500MB 是在并发度和管理成本之间的一个平衡点。 7 个并发连接足以将 5Mbps 带宽跑满，同时进程数在 ps 和 jobs 的视野内清晰可查。

3.3 为什么用 SCP 而不是 HTTPS？

• 新服务器预装了 SSH 服务，无需额外部署；
• 通过 ssh-copy-id 配置免密登录后，所有 scp 命令自动复用同一个密钥，无需处理 Token 过期或签名计算。

四、实现与踩坑

4.1 打包

tar -czf /tmp/rustfs_data_backup.tar.gz -C /www/wwwroot/rustfs data

打包后大小：3.5GB（MP3 本身已压缩，gzip 压缩率有限）。

4.2 切分与并发传输

# 切分为每个 500MB 的分片
split -b 500M -d --suffix-length=2 rustfs_data_backup.tar.gz rustfs_part_

split 命令各参数含义：

• -b 500M：每个分片大小为 500MB；
• -d：使用数字后缀（00、01…），而非字母后缀；
• --suffix-length=2：后缀长度为 2 位，支持最多 99 个分片；
• rustfspart：分片文件的前缀。

执行后生成分片文件

# 配置免密登录（避免多次密码输入）
ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
ssh-copy-id root@目标服务器ip

验证免密登录是否生效：

ssh root@目标服务器ip "echo 'OK'"

# 并发传输
for part in rustfs_part_*; do
    scp "$part" root@目标服务器ip:/tmp/ &
done
wait

这段脚本的执行逻辑：

• for part in rustfspart*：遍历所有分片文件；
• scp ... &：每个分片通过 & 放入后台执行，不阻塞下一个分片的启动；
• wait：等待所有后台 scp 进程完成，再继续后续操作。

实际传输效果：多个分片同时传输，单分片速度约 80~90KB/s，总带宽稳定在 620KB/s 左右，接近 5Mbps 的理论上限。

4.3 目标端合并

# 合并分片
cat rustfs_part_* > rustfs_data_backup.tar.gz

# 验证合并结果
ls -lh rustfs_data_backup.tar.gz
tar -tzf rustfs_data_backup.tar.gz | head -20

踩坑记录：在执行合并操作时遇到 No space left on device 报错。检查磁盘后发现根分区 / 已满，而 /www 数据分区还有充足空间。解决方案是将分片移动到 /www/temp 目录后再合并，避免写入系统分区。

4.4 解压与启动

# 创建数据目录
mkdir -p /www/wwwroot/rustfs

# 解压数据
tar -xzvf rustfs_data_backup.tar.gz -C /www/wwwroot/rustfs

# 启动 RustFS 容器
docker run -d \
  --name rustfs \
  --restart always \
  -p 9000:9000 \
  -p 9001:9001 \
  -e RUSTFS_ROOT_USER='<用户名>' \
  -e RUSTFS_ROOT_PASSWORD='<你的密码>' \
  -e MINIO_SERVER_URL='http://<你的存储域名>' \
  -e MINIO_BROWSER_REDIRECT_URL='http://<你的控制台域名>' \
  -v /<你的宿主机路径>/data:/data \
  -v /<你的宿主机路径>/config:/config \
  rustfs/rustfs

验证容器运行状态：

docker ps | grep rustfs
docker logs rustfs --tail 20

五、延伸思考：方案的局限性

这套方案适用于：

• 数据量在 10GB 以内
• 源端带宽在 50Mbps 以下
• 目标端无需预先部署任何服务

但如果数据量增长到 500GB，这套方案将不再适用。更合适的选择包括：

• 使用 rclone 的多线程上传到对象存储中转（如 AWS S3 / 腾讯云 COS）；
• 使用专业工具如 bbcp（专为高速网络设计）或 fpart（并行文件传输）；
• 若两台服务器同属一个云厂商，可使用内网高速通道 + 快照迁移。

六、命令速查

# 打包
tar -czf backup.tar.gz -C /source data

# 验证压缩包
tar -tzf backup.tar.gz | head -20

# 分片
split -b 500M -d --suffix-length=2 backup.tar.gz part_

# 免密登录
ssh-keygen -t rsa -b 4096
ssh-copy-id root@target_ip

# 并发传输
for f in part_*; do scp "$f" root@target:/path/ & done; wait

# 合并
cat part_* > backup.tar.gz

# 查看磁盘空间
df -h

📌 本文所有操作在 CentOS 7/8 环境下验证通过，RustFS 版本为 v1.0+。

复制粘贴？格式全乱套。一个个敲？那是程序员最痛恨的体力活。

今天带来一个小技巧，利用浏览器自带的"隐身"功能，3步把网页表格"连根拔起"。

核心技术：copy() 大法

操作步骤（全程无需安装任何软件）

1. 选中表格

在网页上，鼠标右键点击那个表格，选择 "检查"（或者按 F12，点左上角的小箭头选中表格）。

2. 定位代码

在开发者工具（Elements 面板）中，确保高亮的那行代码是 <table ...> 开头的那一串。

3. 输入魔法咒语

切换到 Console（控制台） 标签，粘贴下面这行代码，然后敲回车：

copy(document.querySelector('table').outerHTML);

4. 粘贴到 Excel

打开你的 Excel，直接按 Ctrl + V 粘贴。

5. 见证奇迹

你会看到，表格的结构（行、列、颜色）被完美保留下来了！

进阶小贴士

如果页面里有多个表格，上面的代码只会抓第一个。

想抓第二个？把括号里的 'table' 换成下面这样就行（数字从 0 开始数）：

document.querySelectorAll('table')[1]

完整代码：

copy(document.querySelectorAll('table')[1].outerHTML);

小提示

这个方法只对正经的 HTML 表格有效。如果遇到那种 PDF 转图片的"假表格"，这个方法就失灵了——那你就只能老老实实截图，或者用 OCR 文字识别了。

你平时遇到这种数据，都是怎么处理的？欢迎在评论区聊聊 👇

一直以来想拥有一个完全属于自己的内容发布平台。对比了市面上主流方案后，我决定从云服务器层面开始，独立完成整个博客站点的部署，以此作为个人技术实践的一个小小起点。

这篇文章记录了从选型到上线的主要过程，也是一次完整的技术复盘。

成本明细

选择轻量服务器的原因是性价比高、配置灵活，满足个人站点的性能需求。

技术选型

实践过程

第一阶段：环境准备

• 完成域名注册与 ICP 备案（备案周期约 30 天）
• 完成云服务器购买与系统初始化
• 通过 SSH 连接服务器，完成宝塔面板的安装
• 通过宝塔面板一键部署 LNMP 环境

第二阶段：站点创建与程序部署

• 在宝塔面板左侧菜单点击"网站"，选择"添加站点"，填入已绑定的域名，其余选项保持默认，点击提交完成站点创建
• 从 EMLOG 官网下载 Pro 版本安装包（版本 2.6.23），得到一个 .zip 压缩文件
• 在宝塔面板的"文件"管理中找到站点根目录（路径为 /www/wwwroot/域名/），将压缩包直接拖拽上传至该目录，右键选择"解压"，解压后将所有文件从子目录剪切至根目录
• 在宝塔面板的"文件"管理中，右键站点根目录，选择"权限"，将权限设置为 755，确保程序在安装过程中拥有足够的写入权限

第三阶段：应用安装与上线

• 浏览器访问域名，系统自动跳转至 EMLOG 安装向导页面
• 在宝塔面板左侧菜单点击"数据库"→"添加数据库"，填写数据库名称、用户名、密码并提交，完成数据库创建
• 将数据库信息（数据库名、用户名、密码、数据库地址）逐一填入安装向导对应输入框，点击"下一步"
• 设置站点名称、管理员账号及登录密码，点击"完成安装"
• 在宝塔面板的站点设置中，点击"SSL"→"Let's Encrypt"→"申请"，等待约1分钟证书自动签发，勾选"强制HTTPS"并保存，站点地址栏显示小锁图标

遇到的技术问题与解决

问题： 域名解析完成后，站点无法立即访问。

排查过程： 检查了服务器安全组放行端口、宝塔面板站点配置，均无异常。最终确认是 DNS 解析生效存在延迟（通常需要数分钟至数小时）。

解决方案： 等待解析生效后，站点恢复正常访问。

这个过程让我对 DNS 解析机制有了更直观的认识。

后续方向

站点已稳定运行，后续计划：

• 根据实际需求对主题进行二次调整
• 持续输出技术笔记与项目复盘
• 探索服务器层面的运维优化

小结

整个实践过程涵盖了域名注册、环境部署、应用发布等核心环节，让我对 Web 服务的完整链路有了第一手的认知。这次经历也是一次有价值的能力拓展。