2026-03-21

发布时间 : 2026-04-21 01:00

03月21日

03月21日

一、今日完成情况

被消费主义洗脑/狗头，购买了一年腾讯云服务器6MB带宽。
配置腾讯云服务使用我的vultr，安装clash内核，连接国外服务器实现代理
配置腾讯云服务器，作为中继，实现MacBook和游戏本互通，效果良好，画质较高。

二、今日感悟

核心业务数据：
- 服务器配置
今日工作总结：
- 干的事非常有意义，还是需要选择6MB的，这样画质非常好，实现我远程访问电脑，其实听丝滑的，就和本地工作一样了。
明日工作计划：
- 暂无，明天周日，可以简单一点。
今日学习成长：
- 太有成就感了，报错解决了半天，发现cat和vim居然消息不同，这是活久见。

三、备注

预定–华尔街AI发展推演没有系统化了解，导出为图谱的形式，导出笔记，进行理解。截止日期：3月20日预计时间：1h
预定–老大的论文阅读还是没有完成，这里需要花点时间梳理其算法逻辑。截止日期：3月22日预计时间：~~
预定–完成dify工作流本地游戏本部署服务。
预定–完成Google自动检测邮件，并且实现自动化脚本
预定–完成实验室项目数据抽取，打通同步抽取线程
完成–完成国内云服务器中转配合nomachine，实现稳定的访问，我这个节点需要打通来，然后测评一下3M带宽的效果，是否会卡顿。
预定–关于异步async背后的原理完全不清楚，需要梳理清楚图谱，作为笔记[[2026-03-20 15.55.08-异步并发示意图.excalidraw]]

四、云服务器代理内核配置

目标：在国内腾讯云 Ubuntu 无桌面服务器上，通过 Vultr 的 Hysteria2 节点科学上网（rule 模式，国内直连，国外代理），并设置成开机自启服务。

2025-03-21 实际操作完整流程（已验证成功）

1. 前置准备（在能正常访问 GitHub 的环境完成）

桌面端 Clash Verge 已配置好 Hysteria2 节点并能正常使用
从 https://github.com/MetaCubeX/mihomo/releases/latest 下载 mihomo-linux-amd64-v1-v1.19.21.gz（或最新 amd64 版本）
上传到服务器 /etc/clash/ 目录，并解压、重命名、加执行权限：

     cd /etc/clash
     gzip -d mihomo-linux-amd64-v1-v1.19.21.gz
     sudo mv mihomo-linux-amd64-v1-v1.19.21 mihomo
     sudo chmod +x mihomo

2. 配置文件（config.yaml）

在 /etc/clash/ 下创建 config.yaml，内容完整复制桌面端配置（已验证可直接用）：

     mixed-port: 7897
     allow-lan: true
     mode: rule
     log-level: info
     proxies: [...]          # Hysteria2-easytake 配置
     proxy-groups: [...]     # Proxy、Mode、Rule 模式、Global 模式、Direct 直连
     rules: [...]            # GEOIP,CN,DIRECT + 国内域名直连 + MATCH,Proxy

完整的vultr代理配置如下：

mixed-port: 7897
allow-lan: true
mode: rule
log-level: info

proxies:
  - name: "Hysteria2-easytake"
    type: hysteria2
    server: easytake.work
    port: 8443
    password: Se7RAuFZ8Lzg
    alpn:
      - h3
    sni: easytake.work
    skip-cert-verify: false
    udp: true

proxy-groups:
  # === 主代理选择组 ===
  - name: "Proxy"
    type: select
    proxies:
      - "Hysteria2-easytake"
      - "DIRECT"

  # === 模式选择 ===
  - name: "Mode"
    type: select
    proxies:
      - "Rule 模式"
      - "Global 模式"
      - "Direct 直连"

  # === 规则模式 ===
  - name: "Rule 模式"
    type: select
    proxies:
      - "Proxy"
      - "DIRECT"

  # === 全局模式 ===
  - name: "Global 模式"
    type: select
    proxies:
      - "Proxy"

  # === 直连模式 ===
  - name: "Direct 直连"
    type: select
    proxies:
      - "DIRECT"

rules:
  # 直连的国内网站或服务
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,weibo.com,DIRECT
  - DOMAIN-SUFFIX,alipay.com,DIRECT

  # 默认所有其余流量通过代理
  - MATCH,Proxy

3. 首次启动测试（最容易踩坑的地方）

   cd /etc/clash
   ./mihomo -d .

常见错误及解决：

报错：can’t download MMDB / geoip.metadb / context deadline exceeded
原因：国内无法访问 GitHub release-assets 自动下载 geoip.metadb
解决：在能翻墙的环境手动下载 geoip.metadb
推荐链接（任选一个能下）：
https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.metadb
或 https://ghproxy.com/https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.metadb
或 https://cdn.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.metadb
下载后上传到/etc/clash/目录（与 config.yaml 同级）
重新运行 ./mihomo -d . → 不再报下载错误

启动后日志停在 “Start initial compatible provider Mode” 后不动
结论：这是正常现象！表示初始化完成，已监听 7897 端口，后台安静运行
验证方式：

新终端：curl -x http://127.0.0.1:7897 ipinfo.io → 显示新加坡 IP 即成功

4. 设置 systemd 服务（实现开机自启 + 后台运行）

创建服务文件（这一步之前漏做了，导致 systemctl 找不到）

     sudo tee /etc/systemd/system/clash.service > /dev/null << 'EOF'
     [Unit]
     Description=Clash mihomo Proxy Service
     After=network.target

     [Service]
     Type=simple
     User=root
     WorkingDirectory=/etc/clash
     ExecStart=/etc/clash/mihomo -d /etc/clash
     Restart=always
     RestartSec=5

     [Install]
     WantedBy=multi-user.target
     EOF

加载并启动服务（关键两步，很多人忘）

 sudo systemctl daemon-reload
 sudo systemctl enable clash
 sudo systemctl start clash

检查状态

 sudo systemctl status clash

→ 看到 Active: active (running) + mihomo 初始化日志 → 成功

5. 让服务器所有命令默认走代理（强烈推荐）

   echo 'export http_proxy=http://127.0.0.1:7897'  | sudo tee -a /etc/profile
   echo 'export https_proxy=http://127.0.0.1:7897' | sudo tee -a /etc/profile
   source /etc/profile

以后 apt update、git clone、curl、wget、docker pull 等全部自动走代理（国内域名直连）

6. 常用指令–快速上手

常用管理命令总结

查看状态：sudo systemctl status clash
实时日志：journalctl -u clash -f
重启服务：sudo systemctl restart clash
停止服务：sudo systemctl stop clash
改配置后重载：sudo systemctl restart clash
手动前台调试：cd /etc/clash && ./mihomo -d .

注意事项 & 经验教训

永远不要指望 mihomo 自动下载 geoip.metadb（国内基本超时）
systemd 服务文件创建后必须 daemon-reload，否则 systemctl 找不到
日志停在 “Start initial compatible provider XXX” 是正常，不是卡死
Hysteria2 依赖 UDP，腾讯云安全组要放行出站 UDP 流量（默认已放行）
如果节点突然连不上：检查 easytake.work:8443 是否可达、密码/SNI 是否正确

至此，腾讯云服务器已完整配置代理内核，可长期稳定运行。

7. 手动关闭/开启代理配置

A、配置文件

修改.bashrc 文件，指令如下：

vi ~/.bashrc

添加如下代码：

# Clash 代理快捷开关（mihomo mixed-port: 7897）
alias proxy_on='export http_proxy=http://127.0.0.1:7897; export https_proxy=http://127.0.0.1:7897; export all_proxy=http://127.0.0.1:7897; echo "代理已开启（127.0.0.1:7897）"'

alias proxy_off='unset http_proxy https_proxy all_proxy; echo "代理已关闭"'

# 可选：显示当前代理状态
alias proxy_status='echo "http_proxy : ${http_proxy:-未设置}"; echo "https_proxy: ${https_proxy:-未设置}"; echo "all_proxy  : ${all_proxy:-未设置}"'

让改动生效，更新：

source ~/.bashrc

B、效果展示

测试节点位置：

curl ipinfo.io

这里显示的是新加坡的节点，然后关闭代理再次测试：

这里显示的是云服务器的IP，至此我的服务器代理配置顺利完成！！！

五、云服务器公用IP中转nomachine

1. NoMachine 连接方式 – 教程

在你的本地电脑（客户端机器） 打开 NoMachine 客户端软件：
- 新建连接
- 主机填：127.0.0.1
- 端口填：4000
- 协议选 NX（默认）
- 用户名/密码填你云服务器上 NoMachine 的账号密码

点连接 → 就能看到腾讯云服务器的桌面了！
所有流量都走 frp 隧道（4000 端口被 frp 完美转发），相当于你本地直接连了云服务器的 NoMachine，完全不需要公网暴露 4000 端口。

2. 把 frps（服务器端）和 frpc（客户端）都改成 systemd 服务（永久后台自启，无需 nohup、手动启动）

你之前 clash 就是这么配的，这次完全复用，两边各配一个服务，服务器重启后自动跑，再也不用手动 ./frps 或 nohup。

A. 云服务器端（腾讯云，frps 服务）

在腾讯云执行：

cd ~/frp_0.54.0_linux_amd64

sudo tee /etc/systemd/system/frps.service << 'EOF'
[Unit]
Description=frps Service
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root/frp_0.54.0_linux_amd64
ExecStart=/root/frp_0.54.0_linux_amd64/frps -c /root/frp_0.54.0_linux_amd64/frps.toml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now frps
sudo systemctl status frps

检查日志：journalctl -u frps -f

B. 客户端机器（你的这台 Linux，frpc 服务）

在你这台机器（kipley@kipley）执行：

cd ~/frp_0.54.0_linux_amd64

sudo tee /etc/systemd/system/frpc.service << 'EOF'
[Unit]
Description=frpc Service
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/home/kipley/frp_0.54.0_linux_amd64
ExecStart=/home/kipley/frp_0.54.0_linux_amd64/frpc -c /home/kipley/frp_0.54.0_linux_amd64/frpc.toml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now frpc
sudo systemctl status frpc

检查日志：journalctl -u frpc -f

3. 常用管理命令（以后永远用这些）

服务器端（腾讯云）：

重启：sudo systemctl restart frps
查看状态：sudo systemctl status frps
实时日志：journalctl -u frps -f

客户端（你的机器）：

重启：sudo systemctl restart frpc
查看状态：sudo systemctl status frpc
实时日志：journalctl -u frpc -f

4. 最终验证（全流程通）

两边服务都 active (running)
本地 NoMachine 连 127.0.0.1:4000 → 成功进入云服务器桌面
重启服务器/客户端机器后，frps/frpc 自动启动，NoMachine 依然能连

客户端：

服务端：

至此，你的整套方案彻底「无人值守」了：

云服务器开机 → frps 自启
你本地开机 → frpc 自启
NoMachine 随时连 127.0.0.1:4000 就是云服务器桌面

5、错误排查笔记

现象 1：Connection refused (连接被拒绝)

诊断：MacBook 使用 nc -zv 探测服务器 7000 端口失败。
根源：frps 进程未在后台持久运行。虽然手动启动成功，但退出终端或按 Ctrl+C 后进程消失，导致端口关闭。
对策：使用 nohup 或 tmux 保持服务端后台运行，并用 sudo netstat -tunlp | grep 7000 确认监听状态。

现象 2：Session shutdown (会话关闭)

诊断：物理链路已通（nc 成功），但客户端连接后立即断开。
根源：客户端开启了 Tailscale 或 Clash 系统代理。流量在发出前被路由劫持，或者在握手阶段因 TLS 特征被干扰。
对策：暂时关闭本地代理工具，并显式在 [transport] 中配置 tls.enable = false 降级协议进行测试。

现象 3：EOF (文件结束符错误)

诊断：连接报错从 session shutdown 变为 EOF。
根源：身份校验参数不匹配。FRP v0.50+ 版本对配置格式要求极严，必须显式声明 [auth] 段落。

现象 4：frpc 报 dial tcp 127.0.0.1:7000: connection refused

诊断：Mac nc 测试成功，但 frpc 日志始终显示连接本机 127.0.0.1:7000（服务器端 frps.log 无任何新记录）。
根源：frpc.toml 中的 serverAddr 被错误写成 “127.0.0.1”（最常见手滑 + vi 未保存导致）。
对策：先执行 rm -f .*.swp 删除 swap 文件，然后用 cat > ./frpc.toml << 'EOF' 强制完整重写（serverAddr = “162.14.77.140”）。

现象 5：vi 编辑后 cat 显示内容完全不同（甚至代理名都不一样）

诊断：vi 里明明改成正确 IP 和 tls，但 cat 还是旧版 test-tcp + 127.0.0.1。
根源：vi 打开的是残留的 .frpc.toml.swp 恢复缓冲区，:w 只保存了 swap，未覆盖真实文件。

对策：rm -f .*.swp + cat > ./frpc.toml << 'EOF' 重定向写入（彻底绕过 vi 保存坑）。

6、最终效果

经过服务器中转，远程操纵游戏本，丝滑的很，几乎没有延迟额，甚至可以非常流畅的看陈翔六点半。

我的服务器的性能是6MB的，因此带宽非常可以

静态操作与文字办公：非常丝滑

表现：在进行代码编写（如 Neovim 配置）、文档阅读或网页浏览时，6Mbps 的带宽完全绰绰有余。
感受：由于 NoMachine 采用了高效的 NX 协议，其对指令响应的压缩极好。在 6M 中继下，鼠标移动和键盘输入几乎感觉不到延迟，响应速度会非常接近本地操作。

窗口拖动与界面切换：表现良好

表现：在 Ubuntu 桌面切换窗口、拖动文件夹时，由于带宽限制，可能会在快速移动时出现轻微的“边缘模糊”或“像素块”，但动作停止后会立即恢复清晰。
建议：如果觉得不够顺滑，可以在 NoMachine 的显示设置（Display settings）中调低一点质量（Quality），以换取更高的帧率。

视频播放与高负载动画：会有明显压力

表现：如果你尝试在远程桌面上播放 1080p 视频或进行复杂的 3D 渲染预览，6Mbps 会成为瓶颈。
感受：视频可能会出现掉帧或明显的画面撕裂。对于这种高带宽需求场景，中继模式的性能不如局域网直连或更高带宽的公网。

关键指标：延迟（Latency）比带宽更重要

网络环境：既然你已经通过 FRP 穿透成功，影响“丝滑感”的核心不再是那 6M 带宽，而是你的游戏本到腾讯云服务器之间的 Ping 值。
预期：如果你的 Ping 值在 30ms 以内，操作会感觉像是在本地；如果超过 100ms，即使带宽给到 100M，你也会感觉到明显的鼠标“粘滞感”。

UDP 协商失败 (UDP negotiation failed)：这是一个小痛点。目前你走的是 TCP 协议。现状：在 74ms 的延时下，TCP 协议足以应对办公，但如果延时波动，TCP 的重传机制会让画面瞬间卡顿。

这是当前连接的性能，下面查看一下延时，在客户端ping一下服务器，txt文件是nomachine的检测报告：

你目前处于 “高压缩、中等延迟、极高稳定性” 的状态。

LLM 开发/写代码：⭐⭐⭐⭐⭐（完全胜任）
看论文/网页浏览：⭐⭐⭐⭐（偶尔滚屏会有轻微模糊，但立刻清晰）
观看视频/远程游戏：⭐⭐（100ms+ 的延迟和 6M 带宽会吃力）

txt报告解读：

1. 核心网络指标：延迟 (Latency)

报表最下方给出了最真实的协议层延迟：

5s 窗口延迟：114 ms
30s 窗口延迟：106 ms

解读：这个数值比你之前 ping 出来的 74ms 要高。

原因：ping 只是物理层的往返，而这里的 100ms+ 包含了 FRP 转发损耗、NoMachine 协议封包以及服务器处理的时间。

体感：100ms 是远程办公的“分水岭”，你会感觉到鼠标略微有一点“飘”，但对于敲代码（LLM 开发）来说依然在舒适区。

2. 带宽利用率与压缩比

Protocol compression ratio (协议压缩比): 5.324:1
整体流量: 约 42 MB 的数据经过压缩后，实际在网络上传输的有效负荷大大降低。

解读：NoMachine 的 NX 协议表现极其出色。它把你原始的桌面变化数据压缩了 5 倍多才发送。这意味着你的 6Mbps (约 750KB/s) 带宽，在 NX 协议的加持下，实际发挥了接近 30Mbps 的无损传输效果。这就是为什么你在 6M 中继下依然觉得顺滑的原因。

3. 渲染效率 (Render Statistics)

Request #72 (主要图像传输): 表现出极高的压缩比 (16.821:1)。
硬件加速: 结合你之前的 NVENC 信息，系统在处理大面积画面更新（如滚动代码窗口）时，压缩效率极高。

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 kipleyarch@gmail.com