[{"content":"这篇文章记录的是一次比较完整的节点配置与排障过程。\n最开始的问题很简单：FlClash 里的节点订阅更新失败。后来我发现，这个问题并不是“节点本体坏了”，而是订阅入口、Nginx、Cloudflare 和脚本生成配置之间混在了一起。最终我把整个结构重新梳理成：\n个人网站： estevancyber.net → 主页 blog.estevancyber.net → 博客 tools.estevancyber.net → 工具页 节点服务： node.estevancyber.net:2096 → VLESS + WS + TLS + Cloudflare VPS_IP:19690 → VLESS + Reality + Vision 订阅： 54321 或自维护 YAML 文件 → FlClash 订阅入口 这次最大的收获是：网站、节点、订阅不是一回事，不能全都交给一键脚本混在一起管理。\n一、最初的问题：订阅更新失败 一开始 FlClash 里更新订阅失败，提示类似“网络异常”。\n排查后发现旧订阅链接大概长这样：\nhttp://VPS_IP:443/s/clashMetaProfiles/... 问题就在这里：443 是 HTTPS 端口，但链接却是 http://。\n浏览器打开后出现：\n400 Bad Request The plain HTTP request was sent to HTTPS port 这说明普通 HTTP 请求被发到了 HTTPS 端口，协议本身就错了。\n后来改成 https:// 又出现 404，说明请求进入了 Nginx，但没有命中原来的订阅路径。这个时候我才意识到：后续搭建网站时改过 Nginx，可能已经影响到 v2ray-agent 原本生成的订阅服务。\n二、不要把个人网站和节点订阅混在一起 我的个人网站已经由 Nginx 管理：\n80/443 → Nginx 同时 Cloudflare 上还有：\nestevancyber.net blog.estevancyber.net tools.estevancyber.net 这些都属于网站服务。\n而节点订阅本质上只是一个文本配置文件，给客户端拉取 YAML / ClashMeta 配置使用。它不应该和主页、博客、工具页的 Nginx server block 混在一起。\n所以后来我决定：\n网站继续走 80/443 节点单独用自己的端口 订阅单独维护 Cloudflare 只代理适合代理的 WebSocket 节点 三、重新配置 CDN 测试节点 为了测试 Cloudflare CDN 路线，我新建了一个子域名：\nnode.estevancyber.net 最开始我把它开成橙云：\n但脚本安装时检测域名解析，发现：\n当前 VPS IP：165.227.180.152 DNS 解析 IP：104.21.x.x 这是因为橙云开启后，DNS 返回的是 Cloudflare 边缘 IP，而不是源站 VPS IP。\n所以正确流程是：\n安装阶段：node.estevancyber.net 先改灰云，让脚本看到真实 VPS IP 安装完成：再改回橙云，测试 Cloudflare CDN 节点 四、协议选择：为什么选 VLESS + WS + TLS 脚本里有很多协议选项：\n如果目标是“套 Cloudflare”，应该选：\nVLESS + TLS + WS 而不是：\nVLESS + Reality HY2 / Hysteria2 原因很简单：\nReality 更适合直连，不适合走 Cloudflare 橙云。 HY2 主要走 UDP/QUIC，也不适合普通 Cloudflare CDN。 WebSocket 是 Cloudflare 支持的 Web 流量形态，最适合用来做 CDN 测试节点。 因此最终我配置了：\n域名：node.estevancyber.net 端口：2096 协议：VLESS + WS + TLS Cloudflare：橙云 安装完成后脚本输出了 vless:// 节点链接。由于里面包含 UUID、路径和连接信息，这里截图已经打码。\n五、FlClash 里的“URL”不是 vless:// FlClash 添加配置时有几个入口：\n其中：\nURL → 拉取 Clash/Mihomo YAML 配置文件 文件 → 导入本地 YAML 配置文件 二维码 → 扫描配置二维码 vless:// 是单节点分享链接，不是订阅 URL。\n所以直接把 vless://... 粘到 URL 里会提示格式不对。\n解决方式有两种：\n把 vless:// 转成 Clash/Mihomo YAML，然后通过“文件”导入。 自己在 VPS 上维护一个 YAML 文件，再通过 URL 订阅。 我最终选择第二种思路，因为这样更可控，不再依赖脚本的订阅生成器。\n六、手动添加 Reality 节点 后来我不想只有一个 WS CDN 节点，于是又手动添加了一个 Reality 节点。\n目标结构是：\n2096 → VLESS + WS + TLS + Cloudflare 19690 → VLESS + Reality + Vision 这两个节点可以共存，只要端口不冲突。\n1. 找到 sing-box 配置位置 通过 systemd 查看 sing-box 启动命令：\nsudo systemctl cat sing-box 发现配置文件是：\n/etc/v2ray-agent/sing-box/conf/config.json 先备份：\nsudo cp /etc/v2ray-agent/sing-box/conf/config.json \\ /etc/v2ray-agent/sing-box/conf/config.json.bak-before-reality-$(date +%F-%H%M) 2. 生成 Reality 参数 /etc/v2ray-agent/sing-box/sing-box generate uuid /etc/v2ray-agent/sing-box/sing-box generate reality-keypair openssl rand -hex 8 分别得到：\nUUID Reality Private Key Reality Public Key Short ID 注意：\n服务端配置写 private_key 客户端配置写 public-key UUID 和 short-id 两边必须完全一致 3. 添加 Reality inbound 在 sing-box 的 inbounds 中新增一个 VLESS Reality inbound，端口使用：\n19690 关键字段是：\n{ \u0026#34;type\u0026#34;: \u0026#34;vless\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;VLESSReality\u0026#34;, \u0026#34;listen\u0026#34;: \u0026#34;::\u0026#34;, \u0026#34;listen_port\u0026#34;: 19690, \u0026#34;users\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;Estevan-Reality\u0026#34;, \u0026#34;uuid\u0026#34;: \u0026#34;你的UUID\u0026#34;, \u0026#34;flow\u0026#34;: \u0026#34;xtls-rprx-vision\u0026#34; } ], \u0026#34;tls\u0026#34;: { \u0026#34;enabled\u0026#34;: true, \u0026#34;server_name\u0026#34;: \u0026#34;www.microsoft.com\u0026#34;, \u0026#34;reality\u0026#34;: { \u0026#34;enabled\u0026#34;: true, \u0026#34;handshake\u0026#34;: { \u0026#34;server\u0026#34;: \u0026#34;www.microsoft.com\u0026#34;, \u0026#34;server_port\u0026#34;: 443 }, \u0026#34;private_key\u0026#34;: \u0026#34;你的PrivateKey\u0026#34;, \u0026#34;short_id\u0026#34;: [\u0026#34;你的ShortID\u0026#34;] } } } 检查配置：\nsudo /etc/v2ray-agent/sing-box/sing-box check \\ -c /etc/v2ray-agent/sing-box/conf/config.json 重启：\nsudo systemctl restart sing-box 确认端口：\nsudo ss -tulpen | grep -E \u0026#34;:2096|:19690|sing-box\u0026#34; 七、自维护 FlClash YAML 订阅 为了不再依赖脚本生成订阅，我直接维护一个 YAML 文件，例如：\n/var/www/sub/estevan.yaml 里面同时放两个节点：\nproxies: - name: Estevan-VLESS_WS type: vless server: node.estevancyber.net port: 2096 uuid: 你的WS节点UUID network: ws tls: true udp: true servername: node.estevancyber.net client-fingerprint: chrome ws-opts: path: /你的WS路径 headers: Host: node.estevancyber.net - name: Estevan-VLESS-Reality type: vless server: 你的VPS_IP port: 19690 uuid: 你的Reality节点UUID network: tcp tls: true udp: true flow: xtls-rprx-vision servername: www.microsoft.com client-fingerprint: chrome reality-opts: public-key: 你的RealityPublicKey short-id: 你的RealityShortID 再加上分组：\nproxy-groups: - name: PROXY type: select proxies: - Estevan-VLESS-Reality - Estevan-VLESS_WS - DIRECT rules: - MATCH,PROXY 如果想让 FlClash 通过 URL 更新，可以用 Nginx 单独开一个订阅端口，比如：\n54321 Nginx 配置示例：\nserver { listen 54321; listen [::]:54321; server_name _; root /var/www/sub; location / { try_files $uri =404; default_type text/plain; add_header Cache-Control \u0026#34;no-store\u0026#34;; } } 测试：\ncurl -I http://127.0.0.1:54321/estevan.yaml 返回 200 OK 后，FlClash 里填：\nhttp://VPS_IP:54321/estevan.yaml 八、Reality 为什么比 WS CDN 延迟低 最后测试时，Reality 的延迟明显低于 WS CDN：\n这其实符合预期。\nReality 的链路是：\n客户端 → VPS WS CDN 的链路是：\n客户端 → Cloudflare 边缘节点 → VPS Cloudflare 对网站有加速意义，因为它可以缓存图片、CSS、JS 等资源。但代理节点流量不能像网页资源一样被缓存，所以 CDN 节点不一定更快。\n因此两个节点的定位应该是：\nReality： 主力直连节点，延迟更低 VLESS WS CDN： 备用路径，适合直连不稳定时使用 九、最终结构 目前比较合理的结构是：\n80/443 → Nginx：个人网站、博客、工具页 2096 → VLESS + WS + TLS：Cloudflare CDN 测试节点 19690 → VLESS + Reality + Vision：主力直连节点 54321 → 自维护 YAML 订阅 Cloudflare 中：\nestevancyber.net 橙云，用于主页 blog.estevancyber.net 橙云，用于博客 tools.estevancyber.net 橙云，用于工具页 node.estevancyber.net 橙云，仅用于 VLESS WS CDN 节点 Reality 节点不要使用橙云域名，直接用 VPS IP 或灰云域名。\n总结 这次最大的经验不是“哪个协议最快”，而是理解了几个边界：\n网站、节点、订阅是三套东西。 Cloudflare 适合网站和 WS 节点，不适合 Reality / HY2。 一键脚本方便，但复杂环境下容易覆盖已有服务。 Reality 和 VLESS WS 可以共存，只要端口与配置分开。 FlClash 的 URL 订阅需要 YAML 文件，不是 vless:// 分享链接。 自维护 YAML 订阅虽然麻烦一点，但最可控。 后续如果继续优化，我会优先保留 Reality 作为主力节点，把 WS CDN 当作备用节点，而不是盲目追求“套 CDN”。\n","permalink":"https://blog.estevancyber.net/posts/vless-reality-ws-cdn-node-config/","summary":"记录一次节点配置排障：从订阅失效、Nginx 被脚本影响，到最终保留 VLESS WS TLS CDN 节点，并手动补回 VLESS Reality Vision 节点与自维护订阅。","title":"从脚本踩坑到双节点：VLESS WS CDN 与 Reality 节点配置记录"},{"content":"这篇文章记录我把域名接入 Cloudflare，并在 VPS 上搭建个人网站的过程。\n最开始我只是想给 VPS 绑定一个正式域名，后来顺手把站点拆成了两个子域名：\nblog.estevancyber.net → 个人博客 tools.estevancyber.net → 工具页 最终形成的结构是：\n访客 → Cloudflare → DigitalOcean VPS → Nginx ├── blog.estevancyber.net → /var/www/blog └── tools.estevancyber.net → /var/www/tools 一、购买域名 我先在 Squarespace 中购买并管理域名。\n一开始我对“域名注册商”和“DNS 托管”这两个概念有点混：\n注册商：你在哪里买域名。 DNS 托管商：谁来管理这个域名的解析记录。 Cloudflare 接管 DNS：不是转移域名所有权，而是把 Nameserver 改成 Cloudflare 给我的两个地址。 所以我不需要把域名转出 Squarespace，只需要把 Nameserver 改成 Cloudflare 即可。\n二、接入 Cloudflare 在 Cloudflare 中添加域名后，它会分配两个 Nameserver。然后回到域名注册商后台，把原来的 Nameserver 替换成 Cloudflare 的。\n我这里最终验证到：\nestevancyber.net nameserver = lindsey.ns.cloudflare.com estevancyber.net nameserver = stan.ns.cloudflare.com 这个结果说明：域名的 DNS 权威服务器已经切换到 Cloudflare。\n三、配置 DNS 记录 Cloudflare 接管 DNS 后，我添加了几条记录：\nblog A VPS 公网 IP tools A VPS 公网 IP www CNAME estevancyber.net @ A VPS 公网 IP 一开始我全部使用灰云 DNS only，方便排错。确认 Nginx 和网站都能正常访问后，再把 blog 和 tools 切换为橙云 Proxied。\n需要注意：\n博客、网站、API 适合走 Cloudflare 橙云。 SSH、数据库、代理节点、管理后台不要随便走橙云。 DNS 记录删掉不是关键，关键是 Cloudflare 接管后需要把有用记录重新建好。 四、整理 Nginx 站点目录 原本 Nginx 默认目录里已经有一个旧工具页面。为了后续维护清晰，我把站点目录整理成：\n/var/www/blog → 博客 /var/www/tools → 工具页 创建目录：\nsudo mkdir -p /var/www/blog sudo mkdir -p /var/www/tools 把旧工具页迁移到 tools：\nsudo cp -r /usr/share/nginx/html/* /var/www/tools/ 创建临时博客首页：\necho \u0026#34;Hello, this is Estevan Cyber Blog.\u0026#34; | sudo tee /var/www/blog/index.html 五、配置 Nginx 多站点 Nginx 根据不同子域名分发到不同目录。核心配置如下：\nserver { listen 80; listen [::]:80; server_name blog.estevancyber.net; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:443 ssl; server_name blog.estevancyber.net; ssl_certificate /etc/nginx/ssl/estevancyber/origin.pem; ssl_certificate_key /etc/nginx/ssl/estevancyber/origin.key; root /var/www/blog; index index.html; location / { try_files $uri $uri/ =404; } } tools 子域名同理，只需要把 server_name 和 root 换成：\nserver_name tools.estevancyber.net; root /var/www/tools; 检查配置并重载：\nsudo nginx -t sudo systemctl reload nginx 六、配置 HTTPS 我一开始开启 Cloudflare 橙云后遇到了：\nError 525 SSL handshake failed 原因是 Cloudflare 到源站服务器的 HTTPS 握手失败。临时可以切到 Flexible 恢复访问，但长期更推荐使用：\nCloudflare SSL/TLS → Full (strict) 我最后选择了 Cloudflare Origin CA：\nCloudflare → SSL/TLS → Origin Server。 创建 Origin Certificate。 Hostnames 填： *.estevancyber.net estevancyber.net 在 VPS 保存为： /etc/nginx/ssl/estevancyber/origin.pem /etc/nginx/ssl/estevancyber/origin.key 设置权限： sudo chmod 600 /etc/nginx/ssl/estevancyber/origin.key sudo chmod 644 /etc/nginx/ssl/estevancyber/origin.pem 这样链路变成：\n浏览器 → Cloudflare：HTTPS Cloudflare → VPS：HTTPS VPS Nginx → 静态站点目录 七、部署 Hugo + PaperMod 博客 博客使用 Hugo + PaperMod。\n创建站点：\nhugo new site estevancyber-blog cd estevancyber-blog 安装 PaperMod：\ngit init git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod 配置 config.yaml：\nbaseURL: \u0026#34;https://blog.estevancyber.net/\u0026#34; languageCode: \u0026#34;zh-cn\u0026#34; title: \u0026#34;Estevan Cyber\u0026#34; theme: \u0026#34;PaperMod\u0026#34; params: env: production defaultTheme: auto ShowReadingTime: true ShowCodeCopyButtons: true ShowToc: true homeInfoParams: Title: \u0026#34;Estevan Cyber\u0026#34; Content: \u0026#34;记录我的 AI Agent 学习、云服务折腾、项目开发与技术成长。\u0026#34; 构建并发布：\nhugo sudo rm -rf /var/www/blog/* sudo cp -r public/* /var/www/blog/ 最终博客首页效果如下：\n后续我又增加了顶部菜单：\n八、踩坑记录 1. Hugo 版本过低 系统 apt 里的 Hugo 版本可能比较旧，新版 PaperMod 可能要求更高版本。我最后安装了 Hugo Extended 新版。\n2. 配置文件冲突 项目里一度同时存在：\nhugo.toml hugo.yaml config.yaml 这会导致 Hugo 读取配置混乱。最后我只保留 config.yaml。\n3. 图片路径问题 带截图的技术博客更适合 Page Bundle：\ncontent/posts/article-name/ ├── index.md └── image.png 文章中写：\n![图片说明](image.png) 这样图片和文章在一起，迁移和维护都更清楚。\n总结 这次配置让我真正理解了域名、DNS、Cloudflare、Nginx、HTTPS 和 Hugo 之间的关系。\n最重要的经验是：\n先灰云排错，再橙云加速和防护。 先让 HTTP 通，再做 HTTPS。 先让站点能访问，再做 Full strict。 多站点要整理目录，不要一直堆在默认 Nginx 目录里。 Hugo 博客建议一开始就规划好文章和图片结构。 ","permalink":"https://blog.estevancyber.net/posts/cloudflare-domain-blog/","summary":"记录从购买域名、接入 Cloudflare、配置 DNS、划分 blog/tools 子域名，到用 Nginx 和 Hugo 搭建个人网站的完整过程。","title":"Cloudflare 域名托管与个人网站搭建记录"},{"content":"\n这篇文章记录我在 VPS 上部署 Hermes-agent，并把它接入微信的过程。\n最初我只是想在服务器上跑一个可以长期在线的私人 AI Agent。后来发现 Hermes-agent 支持 Docker 部署和消息平台接入，于是就尝试把它接入微信，让它成为一个可以随时对话的私人助手。\n最终目标是：\n微信 → Hermes Weixin Gateway → Hermes-agent → LLM Provider → 返回回复 一、为什么要在 VPS 上部署 Agent 相比本地运行，VPS 部署有几个好处：\n24 小时在线 不依赖本地电脑开机 可以接入微信、Telegram 等消息平台 可以逐步扩展成自动化任务中心 后续可以和个人博客、API、数据库结合 我的 VPS 已经配置好了 Docker，所以 Hermes-agent 直接使用 Docker 部署。\n二、部署前准备 服务器环境：\nUbuntu 24.04 LTS Docker Docker Compose 普通用户 leo UFW 防火墙 先确认 Docker 可用：\ndocker run hello-world 如果能看到：\nHello from Docker! 说明 Docker 已经正常工作。\n三、拉取 Hermes-agent 进入用户目录：\ncd ~ git clone https://github.com/NousResearch/hermes-agent.git cd hermes-agent 启动：\nHERMES_UID=$(id -u) HERMES_GID=$(id -g) docker compose up -d 一开始 Docker 会下载和构建镜像，过程可能比较久。\n启动后检查容器：\ndocker compose ps 正常会看到类似：\nhermes gateway Up hermes-dashboard dashboard Up 四、进入 Hermes Setup 进入配置向导：\ndocker compose exec gateway hermes setup Hermes 会出现 Setup Wizard。\n这里有两种路线：\nQuick Setup：走 Nous Portal，适合快速开始。 Full Setup：自己配置模型提供商和工具。 如果使用 OpenRouter，可以选择免费模型或低成本模型进行测试。\n五、选择 Terminal Backend 配置过程中，Hermes 会询问 terminal backend。\n我这里选择：\nKeep current (local) 简单理解：\nLocal：在当前 VPS / 容器环境执行。 Docker：再套一层容器。 SSH：连接另一台远程机器。 云沙盒：适合更复杂场景。 对我当前这个 VPS 单机部署来说，local 最简单。\n六、接入微信 进入 Gateway 配置：\ndocker compose exec gateway hermes gateway setup 选择 Weixin / WeChat 后，按照提示扫码授权。\n配置成功后会看到类似：\nWeixin configured Account ID: ... User ID: ... 还可以选择是否把当前微信用户设置为 home channel：\n我选择将自己的 Weixin user ID 设置为 home channel。这样 Hermes 就知道默认消息应该发到哪里。\n七、重启 Gateway 配置完成后，不要直接开放公网端口。Docker 部署下，重启 gateway 容器即可：\ndocker compose restart gateway 查看日志：\ndocker logs hermes --tail=100 如果微信发消息没有回应，也可以边发消息边看日志：\ndocker logs hermes --tail=100 八、踩坑：权限问题 我曾经遇到过日志权限错误：\nPermissionError: [Errno 13] Permission denied: \u0026#39;/opt/data/logs/agent.log\u0026#39; 原因是容器内 Hermes 用户无法写入挂载目录。修复方法：\ncd ~/hermes-agent docker compose down sudo chown -R leo:leo ~/.hermes chmod -R u+rwX ~/.hermes rm -f ~/.hermes/logs/gateways/default/lock HERMES_UID=$(id -u) HERMES_GID=$(id -g) docker compose up -d 这个问题解决后，gateway 才能正常写日志并接收消息。\n九、踩坑：gateway profile 问题 后来又遇到过：\nno such gateway \u0026#39;default\u0026#39; 我的理解是：profile 和 gateway 还没有正确绑定，或者配置没有被 gateway 容器加载。\n排查命令：\ndocker compose exec gateway hermes profile list docker compose exec gateway hermes gateway setup docker compose restart gateway 最终通过重新配置 gateway，并重启 Docker 容器解决。\n十、模型切换 Hermes 跑通后，默认模型可能比较普通。可以通过：\ndocker compose exec gateway hermes model 切换 provider 和模型。\n换完模型后建议重启 gateway：\ndocker compose restart gateway 十一、安全原则 Hermes 部署完成后，我没有开放额外公网端口。\n当前原则是：\n不开放 Hermes Dashboard 到公网。 不开放 Hermes API 到公网。 不把 Bot Token、API Key 发到公开仓库。 只通过微信或 SSH 隧道访问。 配置文件和密钥只保留在 VPS 本地。 十二、常用维护命令 进入目录：\ncd ~/hermes-agent 查看容器：\ndocker compose ps 查看日志：\ndocker logs hermes --tail=100 docker logs hermes-dashboard --tail=100 重启 gateway：\ndocker compose restart gateway 重新配置模型：\ndocker compose exec gateway hermes model 重新配置消息平台：\ndocker compose exec gateway hermes gateway setup 查看诊断：\ndocker compose exec gateway hermes doctor 十三、当前成果 目前 Hermes-agent 已经可以通过微信回复消息。\n它在我的 VPS 上作为一个长期在线的私人 AI Agent，可以用于：\n日常问答 记录想法 辅助学习 后续自动化任务 与个人项目联动 这也让我对 AI Agent 的理解更具体了：它不只是一个聊天模型，而是一个可以长期运行、连接工具和消息入口的服务。\n总结 这次部署让我理解了几个关键点：\nDocker 很适合部署 AI Agent 服务。 消息平台接入比单纯 CLI 更有实际使用价值。 日志和权限是排查容器问题的关键。 不要一开始就暴露 Dashboard 或 API。 先让最小链路跑通，再逐步扩展工具和模型。 下一步我计划继续探索：\nHermes-agent 的工具调用 定时任务 与 GitHub / 博客 / API 的联动 把它接入自己的 AI Agent 项目实践中 ","permalink":"https://blog.estevancyber.net/posts/hermes-agent-wechat/","summary":"记录在 DigitalOcean VPS 上用 Docker 部署 Hermes-agent，并接入微信作为私人 AI Agent 的完整过程和踩坑记录。","title":"VPS 上部署 Hermes-agent：让微信接入私人 AI Agent"},{"content":"这篇文章记录我第一次从零配置海外 VPS 的完整过程。\n最开始，我只是想买一台云服务器，用来学习 Linux、SSH、Docker、Nginx 和域名解析。后来这个 VPS 逐渐变成了一个小型个人基础设施：它承担了服务器实验、个人博客、工具页面和 AI Agent 服务等功能。\n这篇不是“炫技教程”，而是一份普通用户也可以参考的实践记录。\n一、为什么要搭一台 VPS 相比直接使用各种现成平台，自己配置 VPS 有几个明显好处：\n可以系统学习 Linux、SSH、Nginx、Docker 等基础技能 可以部署自己的博客、API、工具页和轻量数据库 可以更直观地理解域名、DNS、HTTPS 和 Cloudflare 后续可以作为 AI Agent、小程序、自动化任务的运行环境 出问题时能真正理解服务是怎么跑起来的 我选择的是 DigitalOcean，系统使用 Ubuntu 24.04 LTS。对个人博客、轻量服务和学习用途来说，入门配置不需要太高，1 vCPU / 2GB RAM 已经足够。\n二、创建服务器 创建 VPS 时，我主要关注这几个选项：\n配置项 推荐选择 Region 选择自己实际访问更稳定的区域 Image Ubuntu 24.04 LTS Size 1 vCPU / 2GB RAM 起步 Authentication 优先使用 SSH Key Monitoring 建议开启 Authentication ：设置 root 密码。\n点击 Create ，等待获取公网 IP。\n我分别测试了纽约和旧金山两个节点。理论上美国西海岸离亚洲更近，但跨境线路并不只取决于地理距离，还取决于运营商路由、IP 段、晚高峰拥堵等因素。\n因此，最终选择哪个区域，最好以自己的实测为准。\n三、连接服务器 创建好服务器后，可以用 SSH 登录。\nssh root@你的服务器公网IP 初次登录后，我不建议长期使用 root 用户。root 权限太高，误操作风险比较大。更稳妥的做法是创建普通用户，并给它 sudo 权限。\nadduser leo usermod -aG sudo leo 之后日常登录使用：\nssh leo@你的服务器公网IP 四、基础安全配置 服务器上线后，我做了几项基础安全加固。\n1. 更新系统及BBR加速 sudo apt update sudo apt upgrade -y 开启BBR加速\n为了解决跨海传输的丢包和延迟问题，必须开启 Linux 内核的 BBR 拥塞控制算法 。\n在终端依次执行以下 3 行命令：\necho \u0026#34;net.core.default_qdisc=fq\u0026#34; \u0026gt;\u0026gt; /etc/sysctl.conf echo \u0026#34;net.ipv4.tcp_congestion_control=bbr\u0026#34; \u0026gt;\u0026gt; /etc/sysctl.conf sysctl -p 验证 ：输入 lsmod | grep bbr ，如果看到 tcp_bbr 字样即为成功。\n效果 ：实测 YouTube 4K 速度可从 4Mbps 提升至 40Mbps+。\n注意 ：这一步一定要做，对速度提升明显！\n2. 开启 UFW 防火墙 sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status 当前主要开放端口：\n22/tcp SSH 80/tcp HTTP 443/tcp HTTPS 如果后续部署其他服务，也应该按需开放端口，而不是一次性开放所有端口。\n3. 禁用 root 登录和密码登录 编辑 SSH 配置：\nsudo nano /etc/ssh/sshd_config 确认以下配置：\nPermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no 检查配置语法：\nsudo sshd -t 重启 SSH：\nsudo systemctl restart ssh 这样服务器会更安全：不能直接用 root 登录，也不能用密码暴力尝试登录，只能通过 SSH Key 访问。\n五、VPS 性能与网络测试 为了了解服务器的性能和网络情况，我使用了 bench.sh 做基础测试：\ncurl -Lso- bench.sh | bash 主要关注几个指标：\nCPU 核心数 内存大小 磁盘 I/O 上传 / 下载速度 延迟和丢包 本地也可以用 PowerShell 测试：\nping 你的VPS公网IP -n 50 tracert 你的VPS公网IP 我最终对比了 NYC3 和 SFO3 两个区域：\n节点 平均延迟 丢包 NYC3 约 238ms 0% SFO3 约 249ms 0% 虽然旧金山从地理位置上看更近，但实际测试中纽约节点更稳定，因此最终保留了 NYC3。\n这个过程也让我意识到：VPS 选区不能只看地图距离，实际延迟、丢包和路由才更重要。 六、安装 Docker 为了避免把所有软件都直接装在系统里，我选择用 Docker 管理后续服务。\n安装完成后，用下面命令验证 Docker 是否可用：\ndocker run hello-world 常用命令：\ndocker ps docker ps -a docker logs 容器名 --tail=100 docker compose ps docker compose restart 服务名 Docker 的好处是：每个服务都相对独立，后续迁移、删除、重启和排错都更清晰。\n七、域名与 Cloudflare 后来我购买了域名，并将 DNS 托管到 Cloudflare。\n我的域名结构如下：\nblog.estevancyber.net → 个人博客 tools.estevancyber.net → 工具页 Cloudflare 主要负责：\nDNS 管理 HTTPS 证书 基础缓存 隐藏源站 IP 基础安全防护 接入 Cloudflare 的核心步骤是：\n在 Cloudflare 添加域名 获取 Cloudflare 分配的两个 Nameserver 到域名注册商处替换原 Nameserver 等待 Cloudflare 显示 Active 在 Cloudflare DNS 中添加 A / CNAME 记录 我的 DNS 记录大致如下：\nblog A VPS公网IP tools A VPS公网IP www CNAME estevancyber.net @ A VPS公网IP 一开始建议先用灰云 DNS only，等网站部署和 HTTPS 都确认正常后，再切换为橙云 Proxied。\n八、Nginx 多站点配置 我的 VPS 上使用 Nginx 根据不同子域名分发到不同目录：\nblog.estevancyber.net → /var/www/blog tools.estevancyber.net → /var/www/tools Nginx 配置示例：\nserver { listen 80; listen [::]:80; server_name blog.estevancyber.net; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:443 ssl; server_name blog.estevancyber.net; ssl_certificate /etc/nginx/ssl/estevancyber/origin.pem; ssl_certificate_key /etc/nginx/ssl/estevancyber/origin.key; root /var/www/blog; index index.html; location / { try_files $uri $uri/ =404; } } server { listen 80; listen [::]:80; server_name tools.estevancyber.net; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:443 ssl; server_name tools.estevancyber.net; ssl_certificate /etc/nginx/ssl/estevancyber/origin.pem; ssl_certificate_key /etc/nginx/ssl/estevancyber/origin.key; root /var/www/tools; index index.html; location / { try_files $uri $uri/ =404; } } 检查配置：\nsudo nginx -t sudo systemctl reload nginx 九、Cloudflare HTTPS 配置 最开始我直接打开橙云后遇到了 Error 525 SSL handshake failed。原因是 Cloudflare 到源站服务器的 HTTPS 握手失败。\n临时可以使用 Flexible 模式恢复访问，但这不是长期推荐方案。\n最终我选择使用 Cloudflare Origin CA 证书：\nCloudflare → SSL/TLS → Origin Server 创建 Origin Certificate Hostnames 设置为： *.estevancyber.net estevancyber.net 将证书保存到服务器： /etc/nginx/ssl/estevancyber/origin.pem /etc/nginx/ssl/estevancyber/origin.key 设置权限： sudo chmod 600 /etc/nginx/ssl/estevancyber/origin.key sudo chmod 644 /etc/nginx/ssl/estevancyber/origin.pem Cloudflare SSL/TLS 模式改为： Full (strict) 这样最终链路就是：\n浏览器 → Cloudflare：HTTPS Cloudflare → VPS Nginx：HTTPS Nginx → 静态网站目录 十、部署 Hugo + PaperMod 博客 博客使用 Hugo + PaperMod 构建。\n创建站点：\nhugo new site estevancyber-blog cd estevancyber-blog 安装 PaperMod：\ngit init git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod 注意：新版 PaperMod 对 Hugo 版本有要求。如果系统自带的 Hugo 版本太低，可以下载新版 Hugo Extended。\n检查版本：\nhugo version 构建博客：\nhugo 发布到 Nginx 目录：\nsudo rm -rf /var/www/blog/* sudo cp -r public/* /var/www/blog/ 总结 这次配置让我真正理解了 VPS、SSH、DNS、Nginx、Cloudflare、Docker 和博客之间的关系。\n对普通用户来说，最重要的不是一开始就追求复杂架构，而是先做到：\n能安全登录服务器 能更新和维护系统 能正确配置防火墙 能用域名访问网站 能通过 Docker 管理服务 能逐步形成自己的技术基础设施 这台 VPS 也会成为我后续学习 AI Agent 和部署个人项目的主要实验环境。\n","permalink":"https://blog.estevancyber.net/posts/vps-deployment-first-blog/","summary":"这篇文章记录我第一次从零配置海外 VPS 的完整过程：从服务器选择、SSH 安全加固、Cloudflare 接入，到 Hugo 博客部署。","title":"如何从0开始部署海外 VPS"},{"content":"你好，我是 Estevan。\n这里会记录我的 AI Agent 学习、VPS 部署、个人项目和技术实验。\n","permalink":"https://blog.estevancyber.net/about/","summary":"\u003cp\u003e你好，我是 Estevan。\u003c/p\u003e\n\u003cp\u003e这里会记录我的 AI Agent 学习、VPS 部署、个人项目和技术实验。\u003c/p\u003e","title":"关于"},{"content":"这里会整理我的个人项目。\n已完成 VPS 基础环境搭建 VLESS Reality 节点部署 Hermes-agent 微信 AI Agent Hugo + Cloudflare 个人博客 计划中 AI Agent 学习及开发 Demo 今天吃什么 Agent 小程序 个人 API 服务 ","permalink":"https://blog.estevancyber.net/projects/","summary":"\u003cp\u003e这里会整理我的个人项目。\u003c/p\u003e\n\u003ch2 id=\"已完成\"\u003e已完成\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eVPS 基础环境搭建\u003c/li\u003e\n\u003cli\u003eVLESS Reality 节点部署\u003c/li\u003e\n\u003cli\u003eHermes-agent 微信 AI Agent\u003c/li\u003e\n\u003cli\u003eHugo + Cloudflare 个人博客\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"计划中\"\u003e计划中\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAI Agent 学习及开发 Demo\u003c/li\u003e\n\u003cli\u003e今天吃什么 Agent 小程序\u003c/li\u003e\n\u003cli\u003e个人 API 服务\u003c/li\u003e\n\u003c/ul\u003e","title":"项目"}]