WireGuard 自建 VPN 完整教程 2026：从零搭建高性能全设备翻墙

先说清：WireGuard 是什么，又不是什么

选自建方案时，很多人是冲着「WireGuard 速度快」来的。这话没错，但只说对了一半。WireGuard 是一套工作在网络层的 VPN 协议：连上之后，它在设备上建一块虚拟网卡，系统里几乎所有流量都从这条加密隧道走。它没有「服务端/客户端」的强弱之分，每个节点都叫 Peer，靠成对的公私钥互相认人，配置几十行就能写完。协议实现精简，主流 Linux 发行版的内核已经直接内置，跑起来几乎不占 CPU，这是它性能好的根本原因。

但另一半必须在动手前讲透：WireGuard 从设计上就不做流量伪装。它的握手包和数据包特征固定，走的是 UDP，明眼的深度包检测一眼就能认出来。这带来三个现实后果：

• 在审查强度高的网络里，裸 WireGuard 很容易被限速（QoS）甚至封端口，晚高峰掉速是常事，不是你配置错了；
• 它走 UDP，没法像某些代理协议那样借道 CDN 或伪装成普通网页流量，补救手段（见故障排查）都要额外折腾；
• 它的强项是「全流量、够快、切换网络不断线」，不是「隐蔽」。最在意抗封锁的话方向要反过来，先看带伪装的方案，比如用面板部署的 VLESS+Reality（见 3X-UI 面板自建教程），或读完 主流协议对比再决定。

还有两个设计细节值得提前知道。一是 WireGuard 没有「连接」状态：不维持长连接，没数据时完全沉默，有数据才加密发出。切换网络——WiFi 切移动数据、换了出口 IP——对端认的是公钥而不是地址，隧道自动续上，不必手动重连，手机上感知最明显。二是它只管三层转发，不理解应用：没有规则分流、域名嗅探、按进程直连这些概念。想让国内应用直连、国外服务走隧道，原生做不到，要么靠 AllowedIPs 按网段粗分，要么在隧道外再套一层带规则的客户端。这不是缺陷，是定位——它把简单和快做到极致，把灵活让给了别的工具。

那么什么情况值得自建？家里有路由器、电视盒子这类没法逐个装代理客户端的设备，想让全屋接上就通；或者要在多台自己的机器之间组一张跨地域内网；或者受不了逐个 App 设代理的繁琐。需求对上了，它几乎是同类里最省心的；对不上，搭完只会失望。不想折腾的人可以直接考虑现成的机场服务，买完即用。

部署前检查清单

正式动手前，先逐项确认下面几件事：

• 你有一台带公网 IP 的 VPS，且能放行 UDP 端口。NAT 后的机器做服务端要额外做端口映射，不在本文范围内。
• 云厂商控制台的安全组/防火墙你能改。很多新手卡在这里：系统内放行了，云平台那层没开，握手包根本进不来。
• 线路预期放低。跨境线路质量决定体验上限，协议再快也救不了烂线路。
• 客户端设备都支持 WireGuard。官方客户端覆盖 Windows、macOS、iOS、Android、Linux 和 OpenWrt，老旧设备先确认系统版本。
• 你接受「可能被限速」这个前提。本地网络对 UDP 不友好的话，先搭起来试，真遇到限速再上排查表里的对策。
• 准备好一个备用通道。隧道是单点：VPS 挂了或 IP 被封，所有设备同时断网。先留一个能应急的代理或机场订阅。

选机与系统准备

WireGuard 本身对硬件几乎没要求：单核 CPU、512MB 内存就能跑得很好，加密解密在内核里完成，开销极低。真正要花心思的是带宽和线路：全隧道下全家流量都从这台机器过，月流量往宽里留；机房位置决定延迟，离你近、回程口碑好的优先于配置高的。不知道从哪台入手，先看一遍 2026 VPS 供应商横向对比再下单。其中 Oracle Cloud 的免费 ARM 实例配置给得很足，练手和自用都合适，开通流程见 Oracle Cloud 免费注册教程——但它家的安全列表是独立的一层防火墙，后文会再提醒。

系统选近年的 Ubuntu 或 Debian 即可，内核都已内置 WireGuard 模块。拿到机器先做初始化：

# 更新系统并装齐后面要用到的工具
apt update && apt upgrade -y
apt install -y curl wget qrencode iptables

# 确认内核能加载 WireGuard 模块
modprobe wireguard && lsmod | grep wireguard

# 确认 wg 命令可用
wg --version

modprobe 不报错、lsmod 能查到模块、wg --version 有输出，三项都过即环境就绪；wg 不存在就补装 wireguard-tools，不必换系统。

服务端部署

整个服务端只做四件事：生成密钥、写接口配置、打开转发与 NAT、放行端口。下面手动走一遍，省事路线在本节末尾。

第一步：生成服务端与第一个客户端的密钥

WireGuard 的身份就是密钥：谁持有私钥，谁就是这个 Peer，且密钥在本地生成、从不经过网络传输。

mkdir -p /etc/wireguard && cd /etc/wireguard
umask 077

# 服务端密钥对
wg genkey | tee server_private.key | wg pubkey > server_public.key

# 第一个客户端的密钥对（先在服务端生成，再把配置发给设备）
wg genkey | tee client1_private.key | wg pubkey > client1_public.key

umask 077 不是仪式感——私钥被其他用户读到，对方就能冒充这个 Peer 接入你的隧道。

第二步：写服务端配置 wg0.conf

cat > /etc/wireguard/wg0.conf << EOF
[Interface]
PrivateKey = $(cat server_private.key)
Address = 10.66.66.1/24
ListenPort = 51820

# 隧道起来时加转发与 NAT 规则，关掉时自动撤销；eth0 换成你机器的公网网卡名
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# 客户端 1
PublicKey = $(cat client1_public.key)
AllowedIPs = 10.66.66.2/32
EOF

几个容易踩的点：公网网卡名不一定是 eth0，先用 ip addr 看清楚再写，云厂商的机器常见 ens3、enp0s3；服务端 [Peer] 里的 AllowedIPs 写的是「这个 Peer 在隧道内的地址」，一个客户端一个 /32，不要图省事写整个网段；内网网段 10.66.66.0/24 只是示例，和你家局域网网段不冲突就行。

端口说一句：默认 51820 等于自报家门，扫描和针对性限速都先找它。换随机高位端口能躲掉一部分无差别扫描，代价是自己要记牢、防火墙两处跟着改。这不是安全措施——真正的门禁是密钥——只是减少噪音。另外在公司或校园网里连不上时，先怀疑出口策略封了非常用 UDP 端口，而不是服务端坏了。

第三步：打开 IP 转发

隧道收到包要转发到公网，靠内核转发开关，默认是关的：

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 有 IPv6 需求再加一行 net.ipv6.conf.all.forwarding=1
sysctl -p
sysctl net.ipv4.ip_forward   # 输出 1 才算生效

第四步：放行端口——系统和云平台两层都要开

ufw allow 51820/udp
ufw route allow in on wg0 out on eth0
ufw reload

用 iptables 的话放行入站 UDP 51820 并保存规则即可。别忘了云平台那一层：控制台的安全组/安全列表里同样要放行 UDP 51820 入站——Oracle Cloud 的 VCN 安全列表不放行，系统里怎么配都握不上手。

第五步：启动并验证

wg-quick up wg0
systemctl enable wg-quick@wg0   # 开机自启
wg show                          # 查看接口与 Peer 状态

wg show 能列出接口、监听端口和每个 Peer，服务端就算起来了；客户端连上后 Peer 下出现握手时间和流量计数，才是全线打通的标志。

赶时间的替代路线：社区维护的 wireguard-install 一键脚本（从其官方仓库获取，以仓库当前说明为准）能交互式做完上面几步并生成客户端配置和二维码。省事，但出问题时你不知道它改过什么——第一次建议手动走一遍。

客户端配置：全隧道与分流是两种活法

客户端配置的核心只有一个字段：AllowedIPs，它决定哪些目标地址的流量进隧道。写满是全隧道，只写一部分是分流，先想清楚再生成配置。

服务端生成客户端配置文件：

cat > /etc/wireguard/client1.conf << EOF
[Interface]
PrivateKey = $(cat client1_private.key)
Address = 10.66.66.2/24
DNS = 1.1.1.1, 1.0.0.1

[Peer]
PublicKey = $(cat server_public.key)
Endpoint = <VPS公网IP>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
EOF

# 生成二维码，手机扫码导入
qrencode -t ansiutf8 < /etc/wireguard/client1.conf

全隧道模式就是上面的写法：AllowedIPs = 0.0.0.0/0, ::/0，IPv4 和 IPv6 的全部流量都进隧道。适合公共 WiFi 下护住整台设备、给电视盒子/路由器做全局出口。代价是访问国内服务也要绕一圈，延迟和流量成本都更高，而且 DNS 必须跟着走隧道，只代理流量不代理 DNS 会出现解析被污染的怪象。

分流模式把 AllowedIPs 换成真正需要的网段，例如只让隧道内网和某个 DNS 走 VPN：

AllowedIPs = 10.66.66.0/24, 1.1.1.1/32

其余流量直连本地网络。适合「只想回公司内网」「只让某几台设备互访」的场景。想要按应用、按域名精细分流，那不是 WireGuard 的活，去看带规则的客户端（可参考全平台客户端配置指南，按域名分流可以配合 Clash Nyanpasu 这类客户端）。

其余字段通用：Endpoint 是服务端公网地址加端口；PersistentKeepalive = 25 让 NAT 后的客户端每 25 秒发一个保活包，避免映射过期，家宽和移动设备务必保留。

各平台导入方式大同小异：从 WireGuard 官网或应用商店装官方客户端，导入 .conf 文件或扫二维码，打开开关即可。桌面端要点：Windows 导入文件后点 Activate；macOS 可用 App Store 版，或 brew install wireguard-tools 后用 wg-quick up wg0 管理；Linux 把配置放进 /etc/wireguard/ 同样用 wg-quick 启停。移动端在 App 里从文件导入或扫码，最省事。路由器端（OpenWrt）先装包：

opkg update
opkg install wireguard-tools kmod-wireguard luci-proto-wireguard

然后在 LuCI 界面里新建 WireGuard 接口，把客户端配置里的私钥、地址和 Peer 参数填进去，并把接口划进防火墙的 LAN 区域，全家设备即走路由器出口，不必逐台安装。

连上后做三项验证：打开 ip.sb 之类的位置查询页，出口 IP 应变成 VPS 的 IP；服务端 wg show 里该 Peer 的握手时间是刚刚；再打开一个需要隧道的服务确认可用。三项都过，再谈优化。

各平台再分别提醒几句。Windows 客户端全隧道时建议勾选阻止隧道外流量的选项，断线时宁可断网也别裸奔。macOS 的 App Store 版和命令行版别同时启用，会抢路由。iOS 版支持按网络自动启停（连家里 WiFi 自动断开、切移动网络自动接上），值得配好；Android 版有分应用隧道选项，只让个别 App 走 VPN 时比改 AllowedIPs 更直观。OpenWrt 上把接口划进防火墙 zone 时选错区域是新手最常见的断网原因，划分前先备份路由器配置。

最后是 DNS 与泄露这件容易被忽略的事。全隧道不等于全保护：客户端 DNS 字段留空时，很多系统会继续用本地下发的解析服务器，出现「IP 在国外、DNS 在本地」的半吊子状态，两边判定地区对不上就会抽风，隐私上更是等于没藏。全隧道时 DNS 必须显式指定并走隧道。IPv6 同理：设备有 IPv6 而隧道只接管 IPv4 时，v6 流量会绕过隧道直连；AllowedIPs 里写上 ::/0，或在设备上关掉 IPv6，二选一。浏览器的 WebRTC 也可能暴露本地地址，那是应用层问题，需单独处理。

多设备接入与密钥管理

WireGuard 没有「账号」概念，加一台设备就是加一对密钥、一个隧道地址、一段 [Peer]。原则先立好：一台设备一对密钥，绝不共用——共用就没法单独吊销，手机丢了只能全员换钥匙。

新增设备的流程（在服务端执行）：

cd /etc/wireguard
wg genkey | tee phone_private.key | wg pubkey > phone_public.key

# 把新 Peer 追加进服务端配置
cat >> /etc/wireguard/wg0.conf << EOF

[Peer]
# 手机
PublicKey = $(cat phone_public.key)
AllowedIPs = 10.66.66.3/32
EOF

# 不重启隧道，热加载新配置（已连设备不受影响）
wg syncconf wg0 <(wg-quick strip wg0)

注意最后一步：新手常写的 wg-quick down/up 会把所有在线设备一起踢下线，wg syncconf 才是正确的热更新方式。给新设备生成 .conf 和二维码的方法同上一节，地址按顺序往后排（.2、.3、.4……），排到谁、用在哪台设备上都记下来——这就是下面这份清单的意义。

地址规划多说两句。/24 网段能容纳两百多台设备，个人和家庭绰绰有余；但要避开家用路由器常见的 192.168.0.0/24、192.168.1.0/24 默认段，否则在外连回家会路由撞车。用 10.x 冷门段（如本文的 10.66.66.0/24）最省心。若还想让隧道设备互访家中局域网，先把两张网的边界画清楚再动手——改网段等于所有设备配置一起换。

密钥管理清单

设备一多，乱象都出在管理上。照着这份清单维护，能省掉大部分事故：

• 建一张登记表：设备名、隧道地址、公钥指纹（前几位即可）、发放日期、持有人。公钥不是秘密，可以放心记录；私钥永远不进表格。
• 私钥只存两处：服务端 /etc/wireguard/（权限 600）和设备本地。不要用聊天软件、网盘明文传私钥文件，配置二维码当面扫最稳妥。
• 吊销要干脆：设备丢失或停用，先在服务端删掉对应 [Peer]（或 wg set wg0 peer <公钥> remove 后 wg-quick save wg0 持久化），再删服务端存的那份客户端私钥，顺序反了会留窗口期。
• 定期轮换：长期设备建议半年到一年换一次密钥对：按新增流程发新配置、验证可用后再吊销旧 Peer，别先删旧的再发新的。
• 服务端私钥单独备份：它丢了等于全网重建，加密备份一份离线保存，别和 VPS 快照放同一处。
• 看流量识异常：偶尔跑一次 wg show，握手时间和流量计数能看出哪台设备在连、跑了多少；某 Peer 流量暴涨或深夜频繁握手，值得查一下。

用量再大一点，可以把加设备写成脚本批量执行：生成密钥、取下一个空闲地址、生成配置与二维码、热加载，一条命令完成。注意地址提取要取地址段的末位数字，别把掩码位数误当成地址——这类小 bug 会让新设备拿到错地址且极难排查（原文的示例脚本就栽在这里，取到的其实是 /32 的掩码位数）。

跑稳之后：性能认知与日常维护

先泼一盆冷水：网上很多优化教程热衷于让你往 /etc/sysctl.conf 里堆内核参数，其中相当一部分对转发流量并不起作用。你笔记本发出的 TCP 连接，拥塞控制是你和最终网站在两端协商的，VPS 只是转发中间人，在它身上改 tcp_congestion_control，改的只是它自己发起的连接。所以服务端开 BBR、调大缓冲区这类操作，对自用体感基本无感，别当救命稻草。真正决定体验的排序是：线路质量第一，MTU 第二，其余都是边角。

MTU 为什么排这么前：隧道封装会给每个包套上几十字节的头，路径 MTU 本来就紧（PPPoE 家宽、某些移动网络）时，大包会被分片或丢弃，表现就是「网页能开、图片视频加载不全」「测速还行、实际使用卡」。症状对上时按排查表的方法把 MTU 降到 1280 验证，立竿见影。反过来，线路和 MTU 都正常时，WireGuard 的开销小到可以忽略，瓶颈从来不是协议本身。

日常维护养成三个习惯即可：系统和 wireguard-tools 跟着发行版更新；每月瞥一眼 wg show，核对登记表与实际 Peer 是否对得上；wg0.conf 和服务端私钥保持一份加密离线备份。几十台规模之前不需要任何监控面板。

故障排查表

故障大多能按「先看握手，再看转发，最后看线路」的顺序定位：wg show 里没有握手记录，问题在连通性和密钥；握手之后出问题，查转发、DNS 和 MTU。

现象	先查什么	处理方向
完全没有握手记录	云安全组与系统防火墙的 UDP 端口、Endpoint 地址、双方公钥是否配对	两层防火墙都放行监听端口；确认客户端 [Peer] 里是服务端公钥、服务端 [Peer] 里是该客户端公钥
握手成功但打不开网页	服务端 IP 转发与 NAT、PostUp 里的网卡名	sysctl net.ipv4.ip_forward 应为 1；iptables -t nat -L POSTROUTING 应有 MASQUERADE；网卡名写错是最常见原因
能打开网页但解析异常或被污染	客户端 DNS 是否走隧道	客户端 [Interface] 加 DNS = 1.1.1.1 等可信解析，别让解析留在本地
IPv6 网站直连、位置对不上	客户端是否只隧道了 IPv4	全隧道时 AllowedIPs 同时写 0.0.0.0/0, ::/0；无 IPv6 需求也可在设备上关掉 IPv6
速度上不去、视频卡顿	MTU、线路本身、是否被 UDP 限速	MTU 从 1280 起逐步试调并用 ping 探路；晚高峰才慢多半是 QoS，见下一行
晚高峰明显掉速或端口被封	是否 UDP 被针对性限速	换监听端口；或用 udp2raw、Phantun 把 UDP 包进 TCP 绕行；长期不稳则改走带伪装的协议
切换 WiFi/移动网络后断连	客户端保活与 App 后台权限	确认 PersistentKeepalive = 25；移动端允许后台运行；协议支持 IP 漫游，一般会自动恢复
某些网站能开、某些打不开或图片加载不全	MTU 过大导致大包被丢弃	把接口 MTU 调到 1280 保守值验证，好了再逐步往上加
隧道内设备之间互访不通	双方 AllowedIPs 是否包含隧道网段	分流模式下容易漏写隧道网段地址，补上即可

补两个细节。其一，MTU 探测：ping -M do -s 1392 <目标> 能通说明路径容得下 1420 的包，逐步加大 s 到不通为止，取最后一个能通值加 28 设为 MTU；懒得测时，移动网络和跨运营商场景直接用 1280 通常稳妥。其二，UDP 包 TCP 要两端配合：以 udp2raw 为例，服务端监听 TCP 端口转发给本机 WireGuard，客户端先连 udp2raw、再把 Endpoint 指向本地回环地址，延迟会上升，只当救急。还有人把 Cloudflare WARP 作为第二跳出口（用 wgcf 生成它的 WireGuard 配置接入），能改变出口归属、帮助部分流媒体解锁，但多一跳多一分不确定性，先把直连跑稳再考虑。

排查的通用习惯：一次只改一个变量。同时换端口、改 MTU、动 DNS，好了不知道是谁的功劳，坏了更不知道从哪退回去。

收尾：什么时候别只靠 WireGuard

把预期放回开头那句话：WireGuard 是优秀的隧道机器，不是一套隐身衣。线路环境宽松、追求全设备省心的人可以长期单用；身处强审查网络、或稳定性不能打折的人，更稳妥的是双通道——WireGuard 管全设备覆盖，再备一条带伪装的主力线（比如 3X-UI 部署的 Reality 节点），或备一个机场订阅当后路，单点出问题不至于全屋断网。先跑起来用一周，看本地网络对 UDP 的态度，再决定要不要加保险。

---

延伸阅读

• 流媒体使用与常见问题汇总
• 全平台代理客户端配置指南
• 直连、中转、专线线路差异说明
• AI 工具新手入门与常见问题

免责声明

本文仅供技术交流和学习参考。涉及第三方服务的链接可能包含 sponsored 标记，请自行核实服务条款、价格和可用性，并遵守当地法律法规。