网络知识探索 | 从好奇心驱动到系统认知

探索历程

从编译器到云服务的递进式学习

起点：web编译器的好奇心

• 初衷：想了解网页编译器的实现原理
• 实践：借助ChatGPT实现一个简单的编译器
• 思考点：如何让他人访问到自己的项目？

递进链条：

关键认识：

任何项目最终都要运行在某个端口或解析在某个域名。实现这一点需要两个核心步骤：

1. 部署项目（选择运行环境）
2. 暴露访问（解决网络可达性）

---

项目部署与访问

部署方案对比

部署方式	优势	劣势	适用场景
本地电脑	开发便捷、成本低	无公网IP、可靠性差	个人测试、开发
虚拟机	隔离环保、测试安全	配置复杂、仍无公网IP	学习OS、测试环境
云服务器	公网IP、高可用	成本持续、需运维	生产环境、对外服务
Vercel等PaaS	即时部署、零运维	功能限制、冷启动	前端项目、Serverless应用

方案一：本地电脑部署

技术栈

# Node.js
npx http-server ./dist -p 8080

# Python
python -m http.server 8000

# Docker
docker run -p 8080:80 my-app:latest

核心问题：公网IP缺失

IPv4现状：

理想模型：每台设备 ↔ 唯一公网IP
现实模型：你的设备 ↔ 私有IP ↔ 运营商公网IP
                      (被多层NAT隐藏)

为什么是私有IP？

• IPv4地址空间枯竭（仅43亿个地址）
• 运营商无法为每个用户分配公网IP
• 结果：家庭设备使用192.168.x.x、10.x.x.x等私有段

安全角度的权衡：

❌ 无法被直接访问 → 降低被攻击风险
✅ IPv6解决方案 → 真正的万物互联
   但目前普及度低，过渡期仍需兼容IPv4

解决方案A：局域网访问

原理： 建立本地网络，设备在同一IP段

查看本机IP：

# Windows
ipconfig

# Linux/Mac
ifconfig / ip addr

局域网的扩展形态：

• 热点组网（最简单）
• 路由器组网（最常见）
• 异地VPN组网（见后文）

解决方案B：内网穿透

定义： 将私网设备暴露到公网访问

工作流程：

常见服务：

• Ngrok - 快速简便，付费开放功能
• Frp - 自建穿透服务，需付费VPS
• LocalTunnel - 轻量级方案

技术核心：

建立连接  →  持久隧道  →  请求转发  →  响应回传
(TCP)       (加密)       (代理)       (双向)

风险警示：⚠️

内网穿透 vs 服务器部署

内网穿透的问题：
- 本地设备变成服务端 → 数据安全风险大
- 攻击者若入侵可直达你的电脑
- 家庭网络通常防火墙防护不足

建议：远程数据访问场景 → 用服务器，别穿透本地

---

方案二：虚拟机部署

虚拟机的网络特性

误解澄清：

❌ 常见误认：虚拟机 = 仍需内网穿透
✅ 实际情况：虚拟机可配置为类物理机

网络配置模式：

模式	原理	用途
NAT模式	VM经主机转发	外网隔离、安全
桥接模式	VM直连物理网络	类物理机、可被局域网访问
仅主机模式	VM仅与主机通信	完全隔离

推荐配置（用于项目部署）：

选择 → 桥接模式
结果 → VM获得真正的局域网IP
       如：192.168.1.150
访问 → 其他电脑可用该IP:端口访问

虚拟机的优势

开发环境隔离
  ↓
在VM中安装CentOS/Ubuntu
  ↓
实验破坏性操作无后顾之忧
  ↓
学习Linux系统管理
  ↓
完整的服务器学习体验

进阶应用：

• Docker in VM（容器的容器）
• 多VM集群实验
• 网络拓扑学习

---

方案三：云服务器部署

部署流程

编写代码
   ↓
制作Dockerfile
   ↓
本地build & test
   ↓
scp传到服务器（或git push）
   ↓
服务器docker run
   ↓
互联网可访问

文件传输方式

方式1：SCP命令

# 上传本地文件到服务器
scp /path/to/local/file username@server_ip:/path/to/remote

# 下载服务器文件到本地
scp username@server_ip:/path/to/file /path/to/local

# 完整例子
scp ./Dockerfile root@192.168.1.100:/app

问题： Windows PEM证书认证困难

解决方案：

❌ scp + PEM密钥 → 兼容性问题
✅ 使用GUI工具：
   - FinalShell（免费、好用）
   - 宝塔面板（可视化文件管理）
   - WinSCP（专业传输工具）

Docker的核心价值

---

方案四：Vercel部署

平台特性

传统服务器（需自己管理）：
购买 → 配置 → 部署 → 监控 → 更新 → 维护
⬆️成本高、配置复杂

Vercel（托管式）：
GitHub → 推送代码 → 自动构建 → 自动部署
⬆️即时性、零运维

Vercel的优势

特性	优势
自动部署	关联GitHub仓库，push即部署
全球CDN	内容就近分发，加速访问
Serverless函数	支持后端函数，无需管理服务器
性能优化	自动图片优化、代码分割
框架集成	Next.js官方支持，极佳体验

适用场景

✅ 前端项目（SPA、SSG、SSR）
✅ Next.js全栈应用
✅ 静态博客、文档
✅ API函数服务
✅ 开源项目快速分享

❌ 需要持久化存储的后端
❌ 数据库密集型应用
❌ 需要精细运维的系统

实战案例：部署Gemini接口代理

# 原理：
GitHub的Gemini代理项目
  ↓
fork到自己账号
  ↓
Vercel导入GitHub项目
  ↓
自动构建部署
  ↓
获得自己的域名：xxx.vercel.app
  ↓
国内可直接访问Gemini API

参考教程： YouTube - Vercel一键部署

---

服务器深度探索

代理机制的两面性

什么是代理？

请求链路：
客户端 ──→ 服务端

有了代理：
客户端 ──→ 代理服务器 ──→ 服务端

---

正向代理（Forward Proxy）

代理谁？代理客户端

常见应用

1. 翻墙（梯子）

打开Clash
  ↓
所有网络流量 → Clash代理
  ↓
流量通过海外VPS中转
  ↓
访问Google、YouTube等

原理：你的真实IP被隐藏，目标服务器看到的是代理服务器的IP

2. 企业网络管理

公司内网通过正向代理访问外网
  → 监控：记录访问日志
  → 过滤：阻止访问特定网站
  → 加速：缓存热门资源

3. 隐私保护

真实IP隐藏 → 匿名性 ↑
             → 追踪难度 ↑

技术细节

校园网场景的代理问题

场景：连接代理后，连不上校园网

原因：
- 校园网的认证服务器检查你的IP来源
- 开Clash后，你发出的请求IP = 代理服务器IP
- 校园网认证失败 → 断网

解决：
1. 关闭代理，重新认证
2. 配置分流规则，校园网相关域名不走代理

---

反向代理（Reverse Proxy）

代理谁？代理服务端

互联网 ──→ 反向代理服务器 ──→ 真实服务器
         (对外假装是真实服务器)

常见应用

1. 隐藏真实服务器

攻击者看到：example.com → IP: 1.2.3.4 (反向代理)
实际情况：真实服务器 → IP: 192.168.1.100 (隐藏)

好处：
- 降低真实服务器被直接攻击的风险
- 可以在代理层进行防御
- 更换后端服务器对用户透明

2. 负载均衡

3. 国内访问OpenAI的原理

架构：
用户 ──→ 国内服务器(反向代理) ──→ OpenAI API
        (你自己的服务器)       (国外真实API)

步骤：
1. 购买国内服务器
2. 在服务器上运行反向代理程序
3. 监听: example.cn:8080
4. 转发规则：所有请求 → api.openai.com

用户体验：
用户访问 example.cn → 等同访问 openai.com
(延迟可能增加，但突破地理限制)

代码示例(Nginx)：
server {
    listen 8080;
    server_name example.cn;

    location / {
        proxy_pass https://api.openai.com;
        proxy_set_header Host api.openai.com;
    }
}

---

实战尝试与现实困局

尝试一：异地反代绕过备案

背景：

中国域名管理规则：
- 域名指向国内IP → 需要ICP备案
- ICP备案 → 审批困难、时间长

绕过思路：
域名 → 阿里云新加坡服务器IP ──→ 反向代理 → 国内服务器
      (无需备案)           (真实服务)

失败原因：

理论可行 ❌ 实际遇冷

问题：
1. 购买新加坡服务器后，IP段被阿里云管制
2. 反向代理请求返回到国内时，被GFW检测
3. 连接被截断 → 功能失效

教训：
工作原理 ≠ 实际可用
长城防御 > 技术绕过

尝试二：反代+API实现科学上网

想法：

海外服务器上部署代理+API
  ↓
本地服务器反代这个API
  ↓
国内用户访问本地服务 = 访问国外API
  ↓
实现Clash的效果但通过正规渠道

失败原因：

实施步骤：
1. 部署Shadowsocks/V2Ray → 海外服务器
2. 本地服务器反代这个服务
3. 测试流量转发...

监测机制：
DPI(深包检测) → 识别特殊协议流量
  ↓
自动标记 & 干扰
  ↓
服务不可用

现实：
不是技术问题，是管制问题

核心感悟

可行 ≠ 合法 ≠ 实际可用

理论研究：值得学习
实际应用：需谨慎判断
盲目尝试：得不偿失

服务器的正道用途：
✅ 部署自己的网站/应用
✅ 提供API接口
✅ 运行定时任务
✅ 存储数据

不必要的折腾：
❌ 突破地理限制
❌ 规避管制措施
❌ 隐匿真实身份

---

局域网与异地组网

为什么需要异地组网？

场景一：办公
家里电脑（个人项目） ←→ 公司电脑（工作相关）
需求：无缝访问 & 文件同步

场景二：开发协作
小组成员分散在不同地点
需求：共享开发环境 & 实时文件同步

场景三：智能家居
客厅、卧室、厨房各有设备
需求：统一管理 & 远程控制

传统方案的痛点：
- 云盘同步 → 延迟、费用
- VPN搭建 → 复杂、速度慢
- 文件传输 → 繁琐、容易过时

方案一：VPN异地组网

VPN原理

VPN能做什么？

1. 异地组网

OpenVPN/WireGuard部署在海外服务器
  ↓
每个本地设备都连接到这个服务器
  ↓
虽然物理分散，但逻辑上在同一个虚拟网络
  ↓
可以互相ping、远程桌面、文件共享

2. 翻墙（本质也是隧道）

所有流量 → VPN隧道 → 国外服务器 → 目标网站
           (加密)

自建VPN的复杂性

需要的技术栈：
1. 拥有公网IP的服务器（海外）
2. VPN软件配置（OpenVPN/WireGuard）
3. 证书管理（TLS/SSL）
4. 网络路由配置
5. 防火墙规则设置
6. 持续维护

对于个人开发者：
❌ 太复杂、太繁琐
✅ 用第三方托管服务

---

方案二：Tailscale - 简化的异地组网

核心特性

Tailscale = "VPN的傻瓜式版本"

传统VPN：需要自己搭建服务器
Tailscale：提供托管的VPN服务

特点：
✅ 零配置：安装 + 登录 = 完成
✅ 跨平台：Windows/Mac/Linux/iOS/Android
✅ 自动发现：无需手动配置IP
✅ 加密隧道：端对端加密
✅ 免费版够用：个人用户足够

使用流程

第一步：各设备安装Tailscale
   ↓
第二步：所有设备用同一账号登录
   ↓
第三步：系统自动分配虚拟IP
   ↓
第四步：设备间互相发现 & 直连
   ↓
完成！你的异地设备网络组建好了

实现效果

参考教程： YouTube - Tailscale使用指南

---

应用场景一：文件同步 - Syncthing

问题背景

传统协作模式：
开发者A编辑文件 ──→ 保存到U盘/云盘 ──→ 传给开发者B
                     ↑ 手动操作，容易失误

更糟的情况（双人编辑同一文件）：
A发给B一个版本 ──→ B修改 ──→ B发给A
                             ↓
                    A继续修改旧版本
                             ↓
                    两个修改版本无法合并！
                    谁的改动应该保留？

Syncthing的解决方案

核心特性：实时同步 + 版本控制

使用场景：
公司电脑上创建文件 → 自动同步到家里电脑
家里电脑修改文件  → 自动同步回公司电脑

优势：
1. 实时性：改动立即同步，无延迟
2. 双向同步：两个电脑都是最新版本
3. 版本历史：保留7天修改历史，可回滚
4. 冲突处理：自动检测冲突文件并标记
5. 局域网优先：同网络直连，外网加密转发

基础设置

安装步骤：

1. 两台设备都安装Syncthing
2. 在Syncthing中添加共享文件夹
3. 互相添加为受信设备
4. 配置要同步的目录
5. 启动同步

配置示例：
设备A: ~/Projects ←→ 设备B: ~/Projects
       (同步中)

参考教程： YouTube - Syncthing基础

在团队中的应用畅想

学习小组场景：
Tailscale + Syncthing 组合拳

1. 用Tailscale建立异地局域网
   ↓ 所有成员设备连接到同一虚拟网络

2. 用Syncthing创建共享工作目录
   ↓ 所有成员的电脑自动同步

3. 协作工作流程：
   小组成员A修改代码 ──→ 立即同步给全组
                        ↓
                    B看到修改，继续开发
                        ↓
                    冲突自动标记，手动合并
                        ↓
                    版本历史防止误操作

效率提升：
❌ 老模式：上传 → 下载 → 合并（30分钟）
✅ 新模式：改完自动同步（3秒）

实时协作体验：
类似Google Docs，但用于代码和项目文件

局限性：

当前使用：Syncthing
缺点：
- 不支持iOS（只支持Android）
- 无版本控制（只有修改历史）

待选方案：Resilio Sync（下文）

---

应用场景二：远程控制

Windows远程桌面

原理：
┌────────────────────────────────────┐
│  被控电脑(Windows)                 │
│  启用远程桌面功能                  │
└─────────────┬──────────────────────┘
              ↓
    ┌──────────────────────┐
    │ 在Tailscale虚拟IP上  │
    │ 监听3389端口(RDP协议)│
    └──────────┬───────────┘
               ↓
    ┌──────────────────────┐
    │ 其他设备通过Tailscale│
    │ 连接: 100.0.0.2:3389 │
    └──────────┬───────────┘
               ↓
        屏幕共享 + 输入控制

使用流程：

# 被控电脑设置
1. 设置 → 系统 → 远程桌面 → 启用
2. 注意Windows家庭版不支持（企业版/专业版可用）

# 控制端操作
1. 安装远程桌面客户端
2. 输入: 100.0.0.2:3389 (Tailscale IP)
3. 输入用户名密码
4. 开始远程控制

额外功能：
✅ 文件拖拽：本机文件直接拖到远程桌面
✅ 剪贴板共享：复制粘贴跨设备
✅ 多显示器：支持远程设备的多屏

参考教程： YouTube - 远程桌面_

替代方案：ToDesk

需求场景：
- 没有企业版Windows
- 跨系统远程控制
- 更简洁的UI

推荐：ToDesk（国产）

特点：
✅ 免费版功能完整
✅ 跨平台（Win/Mac/Linux/移动端）
✅ 配置简单
✅ 国内服务器，速度快
✅ 支持屏幕录制

对比：
Windows远程桌面: 功能强但限制多
ToDesk: 功能足够，使用简单

---

方案三：Resilio Sync - 企业级同步

对比Syncthing

特性	Syncthing	Resilio Sync
跨平台	Win/Mac/Linux	Win/Mac/Linux/iOS/Android
同步速度	较快	极快（块级同步）
版本控制	修改历史(7天)	付费版支持
局域网优化	✅	✅
冲突检测	✅	✅
费用	免费	免费版+付费版
iOS支持	❌	✅

块级同步（Block-level Sync）

修改一个大文件的一小部分

Syncthing：
上传整个文件 → 同步给其他设备
(浪费带宽)

Resilio Sync：
只上传修改的块 → 同步到其他设备
(效率高2-10倍)

比喻：
Syncthing: 整本书有一个字改了，重新打印一本书
Resilio: 只打印改了那一页

付费版的价值

需要版本控制？
  → 修改历史管理
  → 防止手滑删除
  → 回滚到历史版本

多人协作需要？
  → 更稳定的同步
  → 更完善的冲突解决
  → 企业级支持

参考教程： YouTube - Resilio Sync

---

本地组网实践

背景：寝室网络困局

现状：
- 笔记本：连校园网（12点后断网）
- 台式机：无WiFi卡、需要网络
- 老师校园号：24小时可用

问题：
同一账号只能一台设备登录
→ 选择：要么笔记本上网，要么台式机上网
→ 无法同时！

灵感：使用路由器发散一个账号的网络

路由器的核心功能

1. 网络接入点（WAN端口）

校园网
  ↓
路由器WAN口连接校园网线
  ↓
在路由器后台用老师校园号登入
  ↓
一次登入，永久有效

2. DHCP地址分配

3. NAT（网络地址转换）

4. 无线接入（WiFi）

物理层：WiFi信号覆盖
网络层：DHCP+NAT分配地址
安全层：WPA2/WPA3加密

连接流程：
设备扫描 → 输入密码 → 获得IP → 上网

5. 防火墙与安全

路由器的防火墙作用：
┌──────────────────────────────────┐
│ 互联网 ←→ 防火墙 ←→ 本地设备    │
│         (过滤规则)               │
└──────────────────────────────────┘

保护：
❌ 阻止未授权的外部访问
✅ 允许本地设备主动发起连接

6. QoS（质量服务）

多个设备竞争带宽时的管理

场景：
设备A下载电影（占用90%带宽）
设备B想浏览网页（卡死）

QoS解决：
A下载：分配60%
B浏览：分配40%
→ 公平分配

或者设置优先级：
视频会议（高优先级） > 下载（低优先级）

7. 文件共享（SMB/NFS）

局域网内设备共享文件

原理：
┌────────────────────────────────┐
│ 设备A启用文件共享              │
│ 共享目录：C:\Shared             │
│ 访问地址：\\192.168.1.100       │
└────────────┬───────────────────┘
             ↓
    其他设备通过文件浏览器
    访问：\\192.168.1.100\Shared
           → 看到A的文件

---

实战设置步骤

第一步：路由器硬件连接

校园网线 ──→ 路由器WAN口
           （蓝色接口）

WiFi设备 ←→ 路由器WiFi信号

其他设备 ──→ 路由器LAN口
           （黄色接口）

第二步：进入路由器后台

# 打开浏览器
输入：192.168.1.1（大多数路由器默认）
或：192.168.0.1

# 输入默认账号密码
通常：admin / admin
（查看路由器底部标签）

第三步：配置WiFi登入

# 在后台找到"WAN设置"或"网络设置"
选择：动态IP（自动获取）或 PPPoE（拨号）

如果是PPPoE：
输入：老师校园号
输入：密码
保存

# 稍等，路由器获得上网

第四步：修改WiFi密码

位置：无线设置 → 无线安全

修改：
- WiFi名称（SSID）：随意
- 密码：设置强密码
- 加密方式：WPA2/WPA3

保存并重启

第五步：连接WiFi

笔记本 / 台式机 / 手机
      ↓
发现WiFi → 输入密码 → 自动获得IP → 上网！

---

高级设置：全局代理

想法：一个路由器，所有设备都能翻墙

痛点：
每台设备单独装Clash → 繁琐
某台设备Clash掉线 → 那台设备断网

解决方案：
在路由器上装Clash
  → 所有设备都走路由器的代理
  → 只需维护一个Clash配置

技术实现

前置条件：
路由器支持刷OpenWrt或类似系统
路由器性能足够（好点的路由器）

步骤：
1. 刷入OpenWrt固件
2. 安装Clash插件
3. 配置转发规则
4. 所有WiFi用户自动走代理

效果：
❌ 复杂，需要技术
✅ 一劳永逸，全家福利

参考教程： YouTube - 路由器刷机与Clash

谨慎建议

当前：新路由器，稳定性最重要
做法：暂不尝试，保持原样

未来：快要报废的旧路由器
再考虑：各种折腾、实验

---

拓展思考：多层网络架构

问题：是否能用路由器接Tailscale？

设想：
将路由器作为一个整体
通过Tailscale连接到其他网络
      ↓
寝室的所有设备 ←→ 家里的所有设备
              （通过虚拟网络）

技术可行性

理论上可行：
1. 在路由器上部署Tailscale客户端
2. 路由器作为一个虚拟节点
3. 其他位置的路由器也部署Tailscale
4. 两个局域网在虚拟层连接

但存在IP分配复杂性：
两层IP地址：
- 第一层：真实网络（校园网）
- 第二层：虚拟网络（Tailscale）
- 第三层：内网（路由器后的设备IP）

路由变得复杂 → 配置困难

应用价值

现状：设备少（1-2个）
做法：每台设备单独连Tailscale
成本：10秒内搞定

未来：设备多（50+个分散各地）
场景：企业多分公司网络

此时：
用路由器网段作为整体
通过Tailscale互连
→ 管理效率大幅提升
→ 类似互联网的分层思想

互联网的启示

互联网的分层结构：
┌───────────────────────────┐
│ 全球互联网                │
├───────────┬───────────────┤
│ 大区域1   │ 大区域2      │
├──┬──┬──┬──┼──┬──┬──┬──┬──┤
│AS1 AS2 ... │AS10 AS11 ..  │
├──┼──┼──┼──┼──┼──┼──┼──┼──┤
│R1 R2 R3... │ R25 R26 ...  │
└──┴──┴──┴──┴──┴──┴──┴──┴──┘
(运营商、企业网、用户网)

本质：
把多个小网络（局域网）
通过BGP路由协议
组合成大网络（互联网）

我们做的：
把多个小设备（异地）
通过Tailscale
组合成虚拟网络

---

核心概念总结

网络的本质

网络 = 设备 + 连接 + 规则

设备：电脑、手机、服务器、路由器等
连接：物理(网线、WiFi) / 虚拟(VPN、代理)
规则：IP、DNS、防火墙、路由等

从局域到广域的递进

访问流程的演进

场景1：本地访问项目
localhost:8080 ──→ 本机 ──→ 浏览器

场景2：局域网访问
192.168.1.100:8080 ──→ 同网络其他设备

场景3：公网访问
example.com ──→ DNS解析 ──→ 114.55.24.95 ──→ 服务器
      (或IP)                    (真实IP)

场景4：异地组网访问
我的项目 @ 寝室台式机 ──→ Tailscale虚拟IP ──→ 家里笔记本
   (100.0.0.1)                 (跨地域直连)

代理机制的现实应用

正向代理（代理客户端）：
你 → 代理服务器 → 目标网站
     (隐藏你的IP)

应用：VPN翻墙、企业网络管理

反向代理（代理服务端）：
用户 → 反向代理 → 真实服务器
      (隐藏真实服务器)

应用：Nginx负载均衡、API服务转发、缓存加速

警告：
正向代理翻墙：小风险（个人）
反向代理翻墙：大风险（服务器被关联）

部署架构对比

开发阶段：
代码 → localhost:3000
     (本地快速验证)

分享阶段：
代码 + Docker → 内网穿透
             (小范围内测)

生产阶段：
代码 + Docker → 云服务器 + 域名 + DNS + 反向代理
             (完整的互联网体验)

Serverless阶段：
代码 + Git → Vercel自动部署
          (零运维，自动扩展)

---

---

最后的思考

为什么要学网络知识？

直接原因：
"我想部署项目到服务器"

深层原因：
理解现代互联网如何运作
从被动使用者 → 主动创造者

更深层原因：
网络 = 现代社会的基础设施
如同20世纪的电力、交通
掌握网络 = 掌握信息时代的话语权

学习的核心方法

❌ 被动学习：看教程，做笔记
✅ 主动探索：有想法，立即实践

❌ 完美理论：等完全理解再动手
✅ 快速迭代：动手 → 遇到问题 → 查资料 → 解决 → 理解加深

在这份笔记中：
我们采用的正是这种方式
从一个想法出发
→ 遇到问题
→ 研究解决方案
→ 积累知识体系
因为所有的案例都是我切切实实做过的尝试 这里做一个汇总 形成体系

网络知识的实用价值

短期：
- 能部署自己的项目
- 能远程管理服务器
- 能搭建家庭网络

中期：
- 理解互联网运作原理
- 能做力所能及的网络优化
- 能解决大多数网络问题

长期：
- 掌握信息时代的核心技能
- 为更复杂系统的学习打基础
- 在技术上拥有更多自主权

---

附录：常用工具速查表

需求	工具	用途
异地组网	Tailscale	VPN虚拟网络
文件同步	Syncthing	实时文件同步
企业同步	Resilio Sync	块级同步 + 版本控制
远程控制	ToDesk / RDP	远程桌面
文件传输	SCP / FTP	服务器文件传输
服务器管理	宝塔面板	可视化面板
代码部署	Vercel	自动化部署
容器化	Docker	环境隔离打包
域名管理	阿里云 / 腾讯云	域名 + DNS解析
代理工具	Clash	正向代理
反向代理	Nginx	负载均衡 + 转发

---

写在最后：

这份笔记不是终点，而是起点。

真正的学习发生在实践中——在失败中排查问题，在成功后总结经验。

有些知识现在不能用，但当你需要时，记得回来翻翻。

因为互联网的美妙之处就在于： 你永远不知道自己什么时候会用到什么。

但当你用到时，就能化为强大的力量。