上篇：放弃 AWS EC2：个人海外轻量服务器选型与“线路”避坑指南
最近折腾了一次在 AWS 上的个人安全隧道搭建，主要诉求是满足个人的远程访问需求。整个过程前后踩了不少坑，最开始我是直接在 AWS EC2 上开机器，后来发现体验并不理想，最后切到了 Lightsail（光帆），整体思路才真正跑顺。
这不是一篇“5 分钟一键成功”的教程，而是一篇从踩坑到跑通的实战复盘。今天这篇上篇，我们先不聊具体的代码配置，主要聊聊选型和网络线路——因为我发现，选错区域比配错协议要致命得多。
一、最开始的理所当然：为什么选 EC2？
一开始我的思路其实很普通，估计也是很多技术人的第一反应：
先在 AWS 上开一台美国 VPS
装上熟悉的 Ubuntu
再在上面搭一个可用的隧道节点
当时我最先开的是 EC2 + Ubuntu 24.04 LTS。从系统选择上来说，这一步没什么问题。Ubuntu 的优势很明显：教程多、兼容性好、软件安装简单，出问题也更容易排查。所以如果你也准备在 AWS 上自己搭，系统优先选 Ubuntu 24.04 LTS，这个选择本身没毛病。
问题其实出在区域和线路的组合上。
二、为什么 EC2 跑起来还是很慢？
我最开始在 EC2 上的选择是：美国东部 弗吉尼亚北部（us-east-1）。
结果全套搭好以后，最大的问题不是“能不能连上”，而是：延迟高、速度慢、容易超时。
一开始我还以为是隧道协议没配置好，反复检查参数，后来才发现根因根本不是协议，而是线路本身。
1. 美国东部离国内太远
如果你人在国内，选美国节点时一定要意识到一个物理现实：美国东部比美国西部远得多。
为了更直观地展示差距，我总结了这两个区域在国内访问时的体感对比：
所以像 us-east-1 这种区域，即使你协议选得再轻量、配置得再完美，体感也大概率还是差。
2. 核心认知修正：协议只能解决“隧道”，不能优化“物理线路”
很多人（包括之前的我）有一个误区：以为选了类似 WireGuard 这样更轻、性能更好的协议，网速就一定会更快。其实不对。协议的优势在于开销小、性能好，但它不能改变底层物理线路的质量。
[建议在此插入图片：一张简单的网络路由拓扑图，标出“本地网络 -> 国内出口 -> 太平洋海底光缆 -> 美国机房”的节点路径]
也就是说：如果这条路本来就拥堵、丢包，那你隧道搭得再漂亮，也只是“通了”，绝对不代表“快了”。
3. EC2 更像云基础设施，不像传统 VPS
为了让你明白为什么我最终放弃 EC2，可以直接看下面这个对比：
三、转向 Lightsail：个人场景的“真命天子”
如果你只是想要一台个人使用的小型海外 VPS，那我现在的结论非常明确：Lightsail（光帆）比 EC2 更适合。
1. 套餐直观，省心省力
Lightsail 更像传统的 VPS，每月多少钱、给多少内存、多大 SSD、带多少流量，一眼就能看明白。这比 EC2 那种“云主机积木”省心太多了。
2. 最合理的落地组合
我这次最后跑通并长期保留的配置是：
平台： AWS Lightsail
区域： Oregon（俄勒冈 / us-west-2）
系统： Ubuntu 24.04 LTS
套餐： $7/月
为什么选俄勒冈（us-west-2）？ 这一步极其关键。如果你的目标是美国节点，且你主要在国内使用，请务必优先考虑美国西部。从这次实践来看，us-west-2 的延迟和稳定性明显优于美东的 us-east-1。配合 1GB 内存、40GB SSD 和 2TB 流量，对于个人的日常远程访问和安全隧道来说，不仅性能够用，流量也非常宽裕。
总结一下： 慢不慢，核心看线路；省不省心，核心看产品定位。选定了机器和区域，接下来就是动手干活了。
在下一篇《AWS Lightsail 实战：使用 WireGuard 搭建省心的个人安全隧道》中，我会详细复盘我是如何用纯手工方式，一步步在 Lightsail 上把 WireGuard 跑起来，并且实现电脑和手机多端接入的。
