别让 DDoS 刷爆你的钱包：为你的VPS加一个保险丝 0x01 前言 作为一名 VPS 用户，最担心的不是服务器宕机，而是半夜醒来发现服务器被 DDoS 攻击，导致流量包耗尽甚至产生巨额扣费。虽然我们可以通过隐藏 IP、设置 404 等方式规避攻击，但面对大流量冲击，这些手段往往力不从心。如果黑客针对你的 IP 发起 DDoS 攻击，即便你设置了 404 或空响应，你的流量依然会飞速消耗。1.为什么 404 挡不住流量消耗？流量计费通常是在机房的出口路由器上统计的。• 下行流量（入站）： 黑客发给你的 10GB 数据，即使你的服务器选择“丢弃”或“拒绝”，这些数据也已经跑过了机房的网线，算进了你的入站流量。• 上行流量（出站）： 虽然 404 返回的数据很小，但在大规模攻击下（每秒几万次请求），成千上万个 404 响应累积起来也是一笔可观的流量。2.针对 服务器流量 的“保命”建议为了防止流量被刷光，我们可以采取以下几阶策略： 第一阶：利用防火墙（内核级拦截） 不要让请求到达 你的各种面板 直接在系统底层把它杀掉。• 设置 IP 白名单： 如果你只有自己用，且有固定 IP 或者能通过 DDNS 获得 IP，直接封死端口。 第二阶：套用 CDN（隐藏真实 IP） 这是防止流量被刷的终极手段。使用 Cloudflare 等服务，将域名指向 CF，然后在服务器防火墙上只允许 Cloudflare 的 IP 访问。效果： 黑客只能攻击到 Cloudflare 的节点，打不到你的 VPS。Cloudflare 免费版提供无上限的 DDoS 防护，你不用担心流量被刷。第三阶：就是今天的“断路器”方案脚本自动关机（止损） 通过脚本监控实时流量，一旦超标立即触发 Formspree 邮件告警并自动关机。 0x02 核心原理 该方案基于 Linux 的轻量级流量监控工具vnstat。监控：每 2 分钟检查一次过去 1 小时的入站+出站总流量。判断：如果流量超过预设阈值（如 50GB/小时），判定为异常攻击。告警：利用 Formspree 的 HTTPS 接口绕过机房对 SMTP 端口的封锁，发送邮件通知。自保：执行 shutdown 关机指令，切断流量计费。 0x03 准备工作 在开始之前，我们需要安装必要的依赖工具。以 Debian/Ubuntu 为例： 你需要安装 vnstat。 # Ubuntu/Debian sudo apt update && sudo apt install vnstat -y然后确认网卡名称你需要告诉脚本监控哪张网卡。执行以下命令：ip add你会看到类似 eth0、ens3 或者 venet0 的名字。记住这个名字。Debian 系统需要安装 bc 来处理数字计算，安装 jq 来解析 vnstat 的数据：apt update && apt install bc jq -y安装后，请确保它正在运行：systemctl enable --now vnstatvnstat 安装后需要一点时间来记录流量。如果提示 Not enough data available yet，不用担心，等 5 分钟数据就出来了。这会儿你可以先运行： vnstat -i eth0 # 把 eth0 换成你刚才查到的网卡名 0x04 思考一下我们需不需要一个流量告警关机的推送 在正式开始创建熔断脚本时候，需要思考你需要在熔断的时候让vps给你一个推送吗？由于这两天折腾了自己的个人简历，使用了Formspree（实际就是一个表单链接，有人给这个链接发消息，他就帮你转到你邮箱去），我问了下Gemini，实际上我目前能想到的方法有几种1.用自己的微信公众号推送2.用telegram推3.用邮箱推4.反正方法挺多，大家可以自行发散我当时去问Gemini一开始让我用电报，然后用邮箱，我给他提的用 Formspree，结果Gemini说Formspree 是一个非常聪明的办法！它完全绕过了 VPS 服务商对 SMTP（25/465/587 端口）的封锁，因为它使用的是标准的 HTTPS (443 端口) 发送数据。这种方式本质上是把服务器的告警信息当作一个“表单提交”发给 Formspree，然后由 Formspree 转发到你的邮箱。OK，那我这一次就用Formspree。 准备 Formspree前往 Formspree.io 注册个账号。创建一个新表单 (New Form)，命名为“VPS Guard”。复制它给你的 Endpoint URL，这个URL再这儿https://formspree.io/forms/xbddrngq/integration（看起来像 https://formspree.io/f/xoqyzabc）。这个xoqyzabc就是你的ID。正式开始写脚本，我们把脚本放在 /root/guard.sh：nano /root/guard.sh“邮件/Formspree版”脚本我们利用 curl 来提交表单。编辑 /root/guard.sh： 0x05 正式开始编写这套保险丝脚本 #!/bin/bash # --- 配置区 --- INTERFACE="eth0" LIMIT_GB=50 FORMSPREE_URL="https://formspree.io/f/你的id" HOSTNAME=$(hostname) # --- 核心逻辑 --- # 获取过去一小时流量 (JSON 格式提取) DATA=$(vnstat -i $INTERFACE --json h 1) RX=$(echo $DATA | jq '.interfaces[0].traffic.hour[0].rx // 0') TX=$(echo $DATA | jq '.interfaces[0].traffic.hour[0].tx // 0') TOTAL_BYTES=$((RX + TX)) TOTAL_GB=$(echo "scale=2; $TOTAL_BYTES / 1024 / 1024 / 1024" | bc) # 打印状态到日志 echo "$(date): 当前一小时已用 $TOTAL_GB GB" >> /tmp/guard.log # 触发判断 if (( $(echo "$TOTAL_GB > $LIMIT_GB" | bc -l) )); then MSG="🚨【流量熔断】服务器 $HOSTNAME 流量已达 ${TOTAL_GB}GB，超过阈值，正在强制关机！" # 发送告警 curl -s -X POST "$FORMSPREE_URL" -d message="$MSG" sleep 3 /sbin/shutdown -h now fiOK,脚本编写完毕在脚本正式部署前，手动跑一行测试，看看邮箱能不能收到：curl -X POST "https://formspree.io/f/你的ID" -d "message=测试：Formspree告警通道正常"到这一步，如果你的邮箱能够正确的接收到推送。 再等几分钟验证日志运行几分钟后，你可以输入以下命令查看你的VPS保镖是否在正常记录：cat /tmp/guard.log 0x06 自动化部署 赋予权限与计划任务 # 赋予执行权限 chmod +x /root/guard.sh # 写入计划任务 (每2分钟检查一次) (crontab -l 2>/dev/null; echo "*/2 * * * * /bin/bash /root/guard.sh") | crontab -至此你的VPS 现在已经具备了“自动保险丝”。⚠️ 特别提醒（如果你和我一样用的 Racknerd）流量额度计算： Racknerd 的套餐流量通常是单向计费（入站或出站取大值），但攻击发生时，入站流量会远大于出站。脚本中计算的是 RX+TX（总流量），这比官方统计更严格，能更早触发保护。手动开机： 一旦脚本执行了 shutdown，你必须登录 Racknerd 的 SolusVM 面板 点击 "Start" 才能重新启动。重置计数： 开机后如果攻击停了，记得运行 vnstat -i eth0 --xml --clear，否则在当前这个小时结束前，它可能还会把你关掉。

利用Nginx给3X-UI穿上防弹衣，再给Nginx穿一件顺滑的"透明钢板衣"（上） 🛡️ 拒绝裸奔：我是如何利用 NPM 给 3X-UI 穿上“防弹衣”的 在运维自己的域名的过程中，很多人（包括我自己）习惯于直接通过 IP:端口 访问面板。虽然方便，但这种做法无异于在荒郊野外开着门睡觉。今天，我们就来复盘一次实战：如何利用 Nginx Proxy Manager (NPM) 配合 2FA，把我们的面板彻底隐藏在安全迷雾之中。🔍 为什么要折腾这一套？ 在正式操作前，我们先思考一个问题：如果你的面板地址是 http://1.2.3.4:3854，这意味着什么？流量全透明：你的密码在公网上是裸奔的。坐标全公开：全球的扫描器每秒钟都在爆破你的 3854 端口。脆弱的防线：一旦密码被破解，你的服务器控制权就拱手让人。在深入细节之前，我们先来看看这台服务器的架构是如何从“简陋”走向“安全”的。1.原始架构：直接暴露 (Direct Access) 最初，我们的流量是点对点的。这种架构下，面板就像一个没有围墙的房子，任何知道 IP 的人都可以来敲门。路径：用户 -> 公网 IP -> XXXX 端口 (3X-UI)风险：流量明文传输、端口完全暴露、易受暴力破解。2.进化架构：反向代理 + 安全闭环 (NPM + 2FA) 这是我们今天最终实现的架构。我们引入了 NPM (Nginx Proxy Manager) 作为唯一的“安保门卫”，并将面板深藏在 Docker 内部。路径：用户 -> 443 端口 (NPM 加密入口) -> 内部网桥 -> 2083 端口 (3X-UI)防御层级：1.SSL 层：强制 HTTPS，解决数据窃听。2.路径层：非公开的 Base Path（如 /Secret123/），阻断盲目扫描。3.防火墙层：UFW 封锁公网 XXXX 端口，仅允许内部流量。4.应用层：2FA（谷歌验证器）提供最终的动态校验。所以我们的目标是：让原本暴露在外的 http://148.ip:端口/3xui根路径/ 彻底消失，取而代之的是一个经过 SSL 加密、物理端口封锁、并拥有两步验证保护的堡垒机。下面，我们就从架构的拆解开始，一步步完成这场安全进阶。”🛠️ 三步走：打造“隐身”架构 第一步：让面板隐藏在 HTTPS 之后我们不再直接访问端口，而是通过 NPM 设置一个反向代理。我们这样做的好处是：面板流量被 SSL 加密，即便在公共 Wi-Fi 下也无法被窃听。我们可以利用 NPM 的 Advanced 配置，为面板设置一个复杂的“隐藏路径”（Base Path）。# 在 NPM 的高级配置中实现精准转发 location /加一个你喜欢的跟目录比如Secret123/ { proxy_pass http://172.17.0.1:你的端口号; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 开启 WebSocket 支持，这是节点连接的关键 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }如果你是dock部署的NPM那的一定要填172.17.0.1,必须是这个，默认情况下，Docker 会在你的 VPS 内部创建一个虚拟网桥 172.17.0.1 NPM 容器：它运行在 Docker 内部，它看不见 外网 IP ，但它能看见 172.17.0.1为了配合防火墙封锁公网端口这是最关键的安全逻辑：如果填公网 IP ： 流量会跑出服务器绕一圈再回来。如果你为了安全用 ufw 关掉了 你3xui端口的 端口，NPM 自己也就访问不到了，会导致 502 Bad Gateway。如果填 Docker IP (172.17.0.1:3xui端口号)： 流量走的是内部私有通道。即使你把公网 3xui端口 端口完全封死，NPM 依然能从“后门”进到 3X-UI 面板。第二步：物理断开，关闭公网端口 既然已经有了 NPM 转发，我们就不再需要 3xui 端口对全球开放。我们通过 ufw 筑起一道高墙：# 禁止所有公网 IP 访问 3xui端口 ufw deny 3xui端口/tcp # 仅允许 Docker 内部网段访问该端口（确保 NPM 能转进去） ufw allow from 172.17.0.0/16 to any port 2083这一步至关重要：现在，黑客扫描你的 IP 时，2083 端口是“关闭”状态，他们甚至不知道你运行了 3X-UI。第三步：最后的防线——谷歌验证器 (2FA)即便有人猜中了你的3xui的域名，撞见了你的隐藏路径，甚至破解了你的强密码，我们还有最后一张王牌：Google Authenticator。通过开启两步验证，每次登录都需要手机上的动态验证码。这种“物理隔离”的验证方式，让安全级别直接从“个人博客”提升到了“金融级”。两步验证开启步骤开启步骤登录面板：通过你的域名地址进入 3X-UI 面板。进入设置：点击左侧菜单栏的 “面板设置” (Panel Settings)。安全设定：在安全设定中找到 “双重验证” (启用2FA)。保存并重启：点击“保存设置”并按照提示重启面板服务。

记录第一次部署VPS，docker环境下部署Nginx Proxy Manager+Typecho+3x-ui+UFW 状态防火墙 + SSL 证书自动续签 🏗️ 架构概览前端网关：Nginx Proxy Manager (Docker 容器)内容管理：Typecho (Docker 容器)代理核心：3x-ui (原生安装) + Xray 内核安全防护：UFW 状态防火墙 + SSL 证书自动续签第一步：环境初始化与 Docker 部署首先更新系统并安装 Docker 基础环境。apt update && apt upgrade -y apt install -y curl git socat ufw curl -fsSL https://get.docker.com | sh遇到问题 1：Docker 内部转发 504 Gateway Timeout表现： 部署 NPM 后，访问域名能看到欢迎页，但转发到后台服务时提示 504 错误。解决方法： 这是因为防火墙拦截了 Docker 网桥的内部通信。需要放行本地和 Docker 网段的流量。# 解决 504 的关键命令 ufw allow from 127.0.0.1 ufw allow from 172.17.0.1 ufw reload第二步：部署 Nginx Proxy Manager 与 Typecho 容器使用 docker-compose 在 /root/web_stack 目录下统一部署。YAMLversion: '3' services: npm: image: 'jc21/nginx-proxy-manager:latest' container_name: npm restart: always ports: - '80:80' - '443:443' - '81:81' volumes: - ./npm_data:/data - ./letsencrypt:/etc/letsencrypt typecho: image: 'joyqi/typecho:latest' container_name: typecho restart: always environment: - TYPECHO_SITE_URL=https://blog.9698424.xyz volumes: - ./typecho_data:/data` 第三步：安装 3x-ui 与 Xray 内核执行一键脚本并进入面板配置：bash <(curl -Ls https://raw.githubusercontent.com/mack-a/v2ray-agent/master/install.sh)遇到问题 2：Xray 状态为 "Not Running" (exit status 23)表现：开启 XHTTP 或 TLS 后，内核频繁崩溃重启。原因： 在 NPM 架构下，Xray 这一端绝不能开启 TLS 安全设置。解决方法： 将入站设置中的 Security 设为 none，把加密任务交给 NPM。第四步：NPM 反向代理配置 (XHTTP 专项)为了让代理节点通过 443 端口伪装成博客流量，需要在 NPM 中设置 Custom Location。Define Location: /khalil-video/Forward Hostname: 172.17.0.1 (宿主机 IP)Forward Port: 3001 (Xray 监听端口)Advanced 配置 (解决 XHTTP 断流)：Nginxproxy_buffering off; proxy_request_buffering off; proxy_http_version 1.1;第五步：Typecho 主题美化 (Joe)遇到问题 3：无法找到宿主机挂载目录表现： cd /root/typecho 提示目录不存在。解决方法： 使用 docker inspect 确认路径，并利用 docker cp 强制安装。#1. 查找路径 docker inspect typecho | grep -A 5 "Mounts"2. 拉取并强制安装 Joe 主题cd ~ && git clone https://github.com/HaoOuBa/Joe.git Joe docker cp Joe typecho:/app/usr/themes/3. 修正权限 (解决后台无法保存设置的问题)docker exec -it typecho chown -R www-data:www-data /app/usr/themes/Joe第六步：进阶功能 (WARP 与流媒体解锁)由于 RackNerd IP 可能被奈飞封锁，我们引入 Cloudflare WARP 提升 IP 纯净度。Bash# 安装 WARP-Gowget-N https://gitlab.com/fscarmen/warp/-/raw/main/menu.sh && bash menu.sh配置逻辑：入站：你 → 443 端口 (NPM) → 3001 端口 (Xray)出站分流：普通流量 → VPS 原生出口Netflix/Disney+ → WARP 虚拟网卡接口🛠️ 日常维护常用命令查看服务状态：x-ui status && docker ps查看博客日志：docker logs -f typecho查看 NPM 错误：docker logs -f npm重置 Xray 配置：若面板打不开，可手动编辑 /usr/local/x-ui/bin/config.json。

欢迎使用 Typecho 如果您看到这篇文章,表示您的 blog 已经安装成功.