能用是能用，但国内访问有时候不太稳。还有些项目直接拿 workers.dev 当入口，延迟和可用性都看运气。

这里写一个比较常见的做法：不用默认的 workers.dev，改用自己的域名，再把这个域名 CNAME 到一个 Cloudflare 优选域名，最后用 Workers 路由接住请求。

说白了就是：

用户 -> 你的域名 -> 优选域名对应的 Cloudflare 节点 -> Workers 路由 -> 你的 Worker

这不是玄学加速，也不是保证永远最快。只是把入口换成一个更顺手的 Cloudflare 节点。

适用场景

这篇更适合这些情况：

• 你已经有一个能正常访问的 Worker。
• 默认的 workers.dev 入口在你的网络里不太稳定。
• 你有自己的域名，并且域名已经托管在 Cloudflare。
• 你想自己指定一个优选入口，而不是直接用 Cloudflare 自动生成的绑定方式。

如果你只是想给 Worker 绑一个普通域名，不折腾优选，直接用自定义域名会更简单。

先说结论

这篇用的是 Workers 路由，不是自定义域名。

原因很简单：

• 自定义域名会让 Cloudflare 自动创建 DNS 记录。
• 但这里需要手动把域名 CNAME 到优选域名。
• 所以更适合用 域名/* 这种 Workers 路由。

如果你只是正常部署一个 Worker，不搞优选，用自定义域名更省事。

如果你想自己指定优选入口，用路由更合适。

前置条件

需要这些：

示例里假设：

Worker 名称：my-worker
你的域名：wk.example.com
优选域名：cloudflare.example.net

实际操作时换成自己的。

最终效果

做完以后，你访问的是自己的域名：

https://wk.example.com

请求会先走你设置的优选域名对应节点，再由 Workers 路由交给目标 Worker 处理。平时访问、API 路径、静态资源路径都应该能被同一个 Worker 接住。

第一步：先确认 Worker 正常

先别急着改 DNS。

打开 Worker 默认地址：

https://my-worker.<你的 workers.dev 子域>.workers.dev

能正常返回内容再继续。

如果默认地址都打不开，先修 Worker。否则后面 DNS 和路由加上去，只会把问题搞得更乱。

也可以用命令测一下：

curl -I https://my-worker.<你的 workers.dev 子域>.workers.dev

有正常 HTTP 状态码就行。

第二步：添加 DNS 记录

进入 Cloudflare 控制台，选中你的域名 example.com。

添加一条 DNS 记录：

重点是代理状态选 仅 DNS 解析，也就是灰云。

不要开代理。

开了代理以后，Cloudflare 会按普通代理逻辑处理，请求入口就不一定是你想要的优选域名了。这个地方很多人会手滑。

添加完后，你的域名应该是：

wk.example.com

第三步：添加 Workers 路由

进入 Cloudflare 控制台：

Workers 和 Pages -> 你的 Worker -> 设置 -> 域和路由

添加一个路由：

wk.example.com/*

然后 Worker 选择你的项目，比如 my-worker。

这里的 /* 不能漏。

不加的话，只匹配根路径，很多接口、静态资源、子路径会直接寄。

第四步：测试访问

浏览器打开：

https://wk.example.com

命令行测：

curl -I https://wk.example.com

如果 Worker 里有 API 路径，也测一下：

curl -I https://wk.example.com/api

不要只测首页。很多项目首页能开，接口路径没被路由接住，后面才发现。

怎么判断有没有生效

先查 DNS：

nslookup wk.example.com

或者：

dig wk.example.com

正常应该能看到它最终指向你设置的优选域名。

再测 HTTPS：

curl -I https://wk.example.com

如果返回的是你 Worker 的响应，就说明路由也生效了。

常见问题

1. 打开是 404

大概率是路由没配对。

检查：

wk.example.com/*

域名、星号、斜杠都看一下。

2. DNS 查得到，但 Worker 没反应

DNS 只是把请求带到 Cloudflare 节点。

Worker 是否执行，看的是 Workers 路由。去“域和路由”看路由有没有绑定到正确 Worker。

3. HTTPS 证书报错

先等一会。

如果一直不行，检查这个域名是不是在 Cloudflare 里正常托管，DNS 记录有没有写错。

另外，别乱用不属于你的域名。证书和路由都不是这么玩的。

4. 优选域名突然变慢

正常。

所谓优选不是固定真理，只是当前测试下来比较好。网络会变，节点也会变。

解决方法就两个：

• 换一个优选域名。
• 自己定期测速。

5. 免费额度够不够

普通个人项目一般够。

Cloudflare Workers 免费计划有每日请求数和 CPU 时间限制。轻量 API、跳转页、小工具通常没问题。

但如果你拿它跑大流量下载、反代一堆东西，那就别想着白嫖无限用。迟早碰限制。

路由和自定义域名怎么选

简单点：

我这里用路由，不是因为它更高级，只是因为它适合“优选域名”这个玩法。

一个完整例子

假设：

Worker：my-worker
域名：example.com
入口：wk.example.com
优选域名：cloudflare.example.net

DNS：

CNAME  wk  cloudflare.example.net  仅 DNS 解析

Workers 路由：

wk.example.com/*

访问：

https://wk.example.com

如果能返回 Worker 内容，就完成了。

最后

这个方案适合已经有 Worker 项目，但默认入口访问不稳定的情况。

别把它想得太神。优选域名只是换入口，不会把一个烂项目变快，也不会解决 Worker 本身的代码问题。

先确认 Worker 正常，再改 DNS，再绑路由。按这个顺序来，不容易乱。

参考

• Cloudflare Workers 路由和域名
• Cloudflare Workers 自定义域名
• Cloudflare Workers Limits

真正麻烦的是后面这些零碎事情：加一个手机、删一个旧设备、生成二维码、改配置、重载服务、看 peer 有没有握手。

手动改 wg0.conf 也不是不行，就是次数多了很烦。而且一不小心把私钥、公钥、AllowedIPs 写错，又得回去排。

所以我写了个 wg-manager.sh，目标很简单：把 WireGuard 常见运维动作包起来，别每次都从头敲。

适用场景

这个脚本适合个人 VPS 上的 WireGuard 小环境：

• 想快速添加、删除客户端。
• 想直接在终端里生成二维码给手机扫。
• 不想每次都手动改 wg0.conf。
• 希望通过菜单看状态、重载配置、导出客户端文件。

如果你已经有复杂的策略路由、多网卡、多出口环境，这个脚本不一定适合直接接管。

前置条件

默认按 Debian / Ubuntu 这类常见服务器环境写。使用前至少需要：

• 一台可以使用 root 权限的 Linux 服务器。
• 系统能正常安装 WireGuard 相关软件包。
• 防火墙或云厂商安全组放行 WireGuard 使用的 UDP 端口。
• 你知道自己要给客户端分配的大致网段。

最终效果

最后你可以直接运行：

sudo ./wg-manager.sh

然后通过菜单完成客户端增删、二维码查看、服务状态检查和配置重载。常用操作不用再反复翻命令。

这个脚本是干嘛的

wg-manager 是一个 Bash 脚本，主要用来管理 WireGuard 服务端和客户端。

它现在能做这些：

• 安装 WireGuard 服务端。
• 创建第一个客户端。
• 添加 / 删除客户端。
• 自动分配客户端 IP。
• 生成客户端配置文件。
• 在终端显示二维码，手机直接扫。
• 支持全局模式和简单分流模式。
• 查看服务状态和 peer 信息。
• 重建配置并重载。
• 卸载脚本管理的配置。

适合一台 Debian / Ubuntu 云服务器。

不适合那种已经有复杂 WireGuard 生产环境、策略路由一堆、分流规则特别细的场景。这个脚本不是来接管复杂网络的，主要是把普通人最常用的那套流程弄顺。

为什么要写菜单模式

一开始这种脚本通常都是命令行参数：

sudo ./wg-manager.sh add-client iphone
sudo ./wg-manager.sh qr iphone
sudo ./wg-manager.sh status

能用，但要记命令。

平时自己手动运维的时候，我更想直接看到菜单：

sudo ./wg-manager.sh

然后选：

1) 安装 WireGuard
2) 添加客户端
3) 删除客户端
4) 列出客户端
5) 查看客户端配置
6) 显示客户端二维码
7) 查看服务状态
8) 重载配置
9) 卸载

这样不用每次翻 README。

还有一个细节：菜单模式启动时会先检查是不是 root。

如果没用 sudo，直接退出。不要让人填了一堆东西，最后才提示权限不够。那种体验有点抽象。

获取脚本

如果仓库已经公开，可以直接克隆：

git clone https://github.com/Kaurisss/wg-manager.git
cd wg-manager
chmod +x wg-manager.sh

也可以只下载单文件：

curl -fsSL -o wg-manager.sh https://raw.githubusercontent.com/Kaurisss/wg-manager/main/wg-manager.sh
chmod +x wg-manager.sh

脚本建议放服务器上用。别在本地 Windows 上硬跑，这玩意本来就是给 Linux 服务器准备的。

菜单模式使用

最简单：

sudo ./wg-manager.sh

第一次用，选安装 WireGuard。

脚本会让你填这些东西：

• WireGuard 接口名，默认 wg0
• UDP 端口，默认 51820
• IPv4 网段，默认 10.66.66.0/24
• 是否启用 IPv6
• 客户端 DNS
• 第一个客户端名字
• 客户端模式：全局 / 分流

大部分直接回车用默认值就行。

装完之后会生成服务端配置，也会顺手生成第一个客户端配置。

如果装了 qrencode，还能直接在终端显示二维码。手机 WireGuard 客户端一扫就能导入，挺省事。

命令行模式

菜单适合人手动点。

但写文档、自动化、复制命令时，子命令还是要保留。

安装并创建第一个客户端：

sudo ./wg-manager.sh install --client-name phone

启用 IPv6：

sudo ./wg-manager.sh install --enable-ipv6 --client-name phone

自定义端口和网段：

sudo ./wg-manager.sh install \
  --port 51820 \
  --ipv4-net 10.66.66.0/24 \
  --enable-ipv6 \
  --ipv6-net fd66:66:66::/64 \
  --client-name laptop

添加客户端：

sudo ./wg-manager.sh add-client iphone

显示二维码：

sudo ./wg-manager.sh qr iphone

查看状态：

sudo ./wg-manager.sh status

列出客户端：

./wg-manager.sh list-clients

重载配置：

sudo ./wg-manager.sh reload

卸载：

sudo ./wg-manager.sh uninstall --yes

全局模式和分流模式

脚本里客户端有两种模式。

全局模式

全局模式就是客户端所有流量都走 WireGuard：

AllowedIPs = 0.0.0.0/0,::/0

适合：

• 手机出门连回服务器。
• 想让所有流量都经过这台 VPS。
• 不想研究分流规则。

分流模式

分流模式就是只让指定网段走 WireGuard。

比如只走内网地址：

sudo ./wg-manager.sh add-client office \
  --mode split \
  --allowed-ips 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

注意，这只是靠 AllowedIPs 做简单分流。

它不是智能分流，也不会自动识别游戏、网站、域名。你要是想做特别细的规则，那得上更复杂的方案。

生成的文件放哪

默认都在 /etc/wireguard/：

/etc/wireguard/
├── wg0.conf
├── clients/
│   ├── phone.conf
│   └── iphone.conf
├── peers/
│   └── iphone/
│       ├── private.key
│       ├── public.key
│       ├── psk.key
│       └── meta
├── backup/
└── .wg-manager/
    ├── server.env
    ├── server_private.key
    └── server_public.key

这里面有私钥、PSK、客户端配置。

不要传 GitHub。

公开仓库里只放脚本、README、示例配置就行。真实配置文件传上去，基本就是自己给自己挖坑。

安全组和防火墙

脚本会尝试处理 UFW 和 firewalld，自动放行 WireGuard 的 UDP 端口。

但云服务器还有安全组。

这个脚本管不了云厂商控制台。

如果连不上，先看：

• 云服务器安全组有没有放行 UDP 51820
• 本机防火墙有没有拦
• 客户端里的 endpoint 是不是写错
• 服务端公网 IP 有没有变
• sudo ./wg-manager.sh status 里有没有握手

不要一连不上就怀疑脚本。

网络这东西很多时候不是配置没生成，是流量根本没进来。

排错顺序

我一般按这个顺序看：

1. 服务有没有起来

sudo ./wg-manager.sh status

或者：

sudo systemctl status wg-quick@wg0

2. 客户端配置有没有生成

ls -l /etc/wireguard/clients/

3. 二维码能不能扫

sudo ./wg-manager.sh qr iphone

4. peer 有没有握手

sudo wg

有 latest handshake 才说明客户端真的连上了。

没有握手就继续看端口、安全组、endpoint、公私钥。

已知限制

这个脚本不是万能的。

目前限制大概是：

• 只支持 Debian / Ubuntu。
• IPv4 网段只按 /24 处理。
• IPv6 网段只按 /64 处理。
• 默认用 iptables / ip6tables 做 NAT。
• 不接管已有复杂 WireGuard 环境。
• 分流只是简单 AllowedIPs，不做智能规则。

这些限制不是 bug，是故意先控制范围。

脚本这种东西最怕一开始想包打天下，最后写成一坨没人敢跑的东西。

最后

wg-manager 不是为了替代 WireGuard 官方工具。

它只是把我经常要做的几件事包成一个脚本：安装、加客户端、删客户端、扫二维码、看状态、重载配置。

能少手改一次 wg0.conf，就少一次写错配置的机会。

先能稳定跑，再慢慢补功能。这个方向比较像人样。

一开始只是想找个轻一点的主题，别搞得像那种花里胡哨的模板站。后面看到 OpenCode 这个终端风格还行，黑白、等宽字体、结构也比较干净，就先拿来用了。

为什么用这个主题

主要是几个点：

• 页面够干净，不抢文章内容。
• 等宽字体看代码舒服。
• 黑白风格比较耐看，不容易审美疲劳。
• 结构简单，后面想改也不算难。

有些主题第一眼很炫，真写文章的时候就开始乱：卡片太多、颜色太杂、动画一堆。看着不像博客，像卖课页。

这个至少没那么抽象。

现在的样子

目前博客主要放这些内容：

• 网络和服务器相关的折腾记录。
• Linux、脚本、命令速查。
• 一些工具部署和踩坑笔记。
• 后面可能会放 AI 编码、网站、自动化这些东西。

不一定写得多正式，能看懂、能复现就行。

代码块效果

命令块大概是这样：

npm install
npm run build

普通代码块：

function log(message) {
  console.log(`[stdout] ${message}`)
}

log('hello opencode')

后面可能会改的地方

这个主题能用，但也不是完全不用动。

我大概会改这些：

1. 首页文章列表再紧凑一点。
2. 中文排版细节调一下。
3. 分类和标签页面别太空。
4. 代码块复制按钮如果不好用就重写。
5. 移动端看着不顺眼的地方继续修。

先跑起来，再慢慢改。

结尾

这个站目前就当自己的技术笔记。

写文章不是为了装得很专业，主要是防止下次又忘了怎么配。能把坑记下来，就不算白折腾。

Linux 命令太多，不可能全背。平时能记住常用的，剩下的需要时能快速翻到就行。

目录

1. 常用命令简表
2. 文件和目录
3. 查看文件
4. 文本处理
5. 查找文件
6. 权限和用户
7. 进程和服务
8. 网络相关
9. 软件包管理
10. 磁盘和挂载
11. 压缩和解压
12. 日志和排错
13. Shell 小东西
14. 几个常用一行命令

常用命令简表

文件和目录

ls

看目录：

ls
ls -l
ls -la
ls -lh

常用参数：

• -l：详细列表
• -a：显示隐藏文件
• -h：文件大小更好看，比如 1.2G

cd 和 pwd

pwd
cd /var/www
cd ~
cd -

cd - 可以回到上一个目录，挺常用。

cp

cp a.txt b.txt
cp -r src/ backup/
cp -a src/ backup/

-a 会尽量保留权限、时间等信息，备份目录时比 -r 更稳一点。

mv

mv old.txt new.txt
mv file.txt /tmp/

既能移动，也能改名。

rm

rm file.txt
rm -r folder/
rm -rf folder/

rm -rf 别手滑。尤其是带变量的时候，先 echo 一下路径，不然删错真没得后悔。

mkdir

mkdir logs
mkdir -p app/data/cache

-p 会自动创建中间目录。

查看文件

cat

cat file.txt

小文件直接看。大文件别用它硬刷屏。

less

less app.log

常用操作：

• /关键词：搜索
• n：下一个结果
• q：退出

head 和 tail

head -n 20 app.log
tail -n 50 app.log
tail -f app.log

看日志一般用 tail -f。

nl

nl file.txt

带行号显示文件。排查配置时有用。

文本处理

grep

grep "ERROR" app.log
grep -n "ERROR" app.log
grep -R "listen" /etc/nginx
grep -i "error" app.log

常用参数：

• -n：显示行号
• -R：递归搜索目录
• -i：忽略大小写

如果系统里有 rg，我一般会优先用 rg，快很多：

rg "ERROR"
rg "listen" /etc/nginx

sed

sed -n '1,20p' file.txt
sed 's/old/new/g' file.txt

常用来替换文本或者只看某几行。

awk

awk '{print $1}' access.log
awk '{print $1, $9}' access.log

按列处理文本。日志分析经常用。

cut

cut -d':' -f1 /etc/passwd
cut -d',' -f1,3 data.csv

简单分列就用它，不用上来就写一堆脚本。

sort 和 uniq

sort file.txt
sort -n numbers.txt
sort file.txt | uniq
sort file.txt | uniq -c

统计重复项时很顺手。

wc

wc -l file.txt
wc -c file.txt

数行数、字节数。

查找文件

find

find . -name "*.log"
find /var/log -type f -mtime -7
find . -type f -size +100M

几个常用条件：

• -name：按名字
• -type f：只找文件
• -type d：只找目录
• -mtime -7：7 天内改过
• -size +100M：大于 100M

which

which nginx
which python

看命令到底从哪来的。

locate

locate nginx.conf

快，但是依赖索引。刚创建的文件可能搜不到。

权限和用户

chmod

chmod 644 file.txt
chmod 755 script.sh
chmod +x script.sh

常见权限：

• 644：普通文件
• 755：可执行脚本或目录
• 600：私钥这类敏感文件

chown

sudo chown user:group file.txt
sudo chown -R www-data:www-data /var/www/app

网站目录权限不对时经常要看这个。

用户相关

whoami
id
passwd
sudo useradd name
sudo usermod -aG sudo name

进程和服务

看进程

ps aux
ps aux | grep nginx
top
htop

有 htop 就用 htop，看着舒服点。

杀进程

kill 1234
kill -9 1234
pkill -f nginx

kill -9 是强杀，不是万能修复按钮。先正常 kill，不行再用。

systemd 服务

sudo systemctl status nginx
sudo systemctl start nginx
sudo systemctl restart nginx
sudo systemctl enable nginx

看服务日志：

journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"

网络相关

IP 和端口

ip addr
ip route
ss -tuln
ss -tulnp

ss -tulnp 能看哪个进程占了哪个端口。

连通性

ping 1.1.1.1
curl -I https://example.com
curl http://127.0.0.1:3000

测 HTTP 服务别只会 ping。ping 通不代表网站活着。

SSH

ssh root@1.2.3.4
ssh -p 2222 user@1.2.3.4
scp file.txt user@1.2.3.4:/tmp/

rsync

rsync -avz ./dist/ user@server:/var/www/app/
rsync -avz --delete ./dist/ user@server:/var/www/app/

--delete 会删除目标端多出来的文件，用之前先想清楚。

软件包管理

Debian / Ubuntu：

sudo apt update
sudo apt install nginx
sudo apt upgrade

CentOS / RHEL：

sudo yum install nginx
sudo dnf install nginx

Arch：

sudo pacman -S nginx

openSUSE：

sudo zypper install nginx

不同发行版命令不一样。别复制错系统了。

磁盘和挂载

看磁盘

df -h
du -sh *
du -sh /var/log

找大目录：

du -h --max-depth=1 / | sort -h

块设备

lsblk
blkid
sudo fdisk -l

挂载

sudo mount /dev/sdb1 /mnt
sudo umount /mnt

压缩和解压

tar

tar -czvf archive.tar.gz folder/
tar -xzvf archive.tar.gz
tar -tzf archive.tar.gz

zip

zip -r archive.zip folder/
unzip archive.zip

gzip

gzip file.txt
gunzip file.txt.gz

日志和排错

dmesg
journalctl -xe
journalctl -u service-name -f
tail -f /var/log/syslog
tail -f /var/log/nginx/error.log

端口被占用：

sudo lsof -i :80
sudo ss -tulnp | grep :80

配置改完不生效，先看服务有没有重启，再看日志。很多问题不是配置没写，是服务根本没加载。

Shell 小东西

环境变量

env
printenv
export NODE_ENV=production
echo $PATH

alias

alias ll='ls -lah'
alias gs='git status'

写进 ~/.bashrc 或 ~/.zshrc 才会长期生效。

执行脚本

chmod +x script.sh
./script.sh

定时任务

crontab -e
crontab -l

几个常用一行命令

找大文件：

find / -type f -size +500M 2>/dev/null

查日志里的错误：

grep -R --line-number "ERROR" /var/log 2>/dev/null

看当前目录每个文件夹大小：

du -h --max-depth=1 . | sort -h

同步网站构建产物：

rsync -avz --delete ./dist/ user@server:/var/www/site/

看某个服务最近日志：

journalctl -u nginx --since "2 hours ago" -f

找占用端口的进程：

sudo ss -tulnp | grep :3000

批量删 .tmp 文件：

find . -type f -name "*.tmp" -delete

这个命令执行前最好先把 -delete 去掉看一眼结果：

find . -type f -name "*.tmp"

别上来就删，删错挺麻烦。

这时候 Cloudflare Tunnel 就挺适合。它的逻辑很简单：本地机器主动连到 Cloudflare，然后外面的人通过你的域名访问这个隧道。你不用暴露端口，也不用管运营商给不给公网 IP。

适用场景

• 家里跑了一个网站，想临时给外网访问。
• NAS、面板、测试服务想绑个域名。
• 不想在路由器上开一堆端口。
• 没有公网 IP，但又想有 HTTPS。

别拿它当万能反代。要是你跑的是高并发、大流量服务，还是老老实实上服务器。Tunnel 更适合个人服务、测试环境和低频访问。

前置条件

先确认这几件事：

先测一下你的本地服务是不是活的：

curl -I http://127.0.0.1:80

能看到 200、301、302 这类正常响应就行。要是本地都打不开，先别折腾 Tunnel，不然排错会很抽象。

最终效果

做完以后，外网访问的是你的域名：

https://app.example.com

请求会从 Cloudflare 进入，再通过本机主动建立的 Tunnel 转到内网服务。你不用在路由器上做端口映射，也不用要求家里有公网 IP。

安装 cloudflared

cloudflared 是 Cloudflare Tunnel 的客户端。

macOS 可以直接用 Homebrew：

brew install cloudflared

Linux 下载二进制文件就行：

curl -L 'https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64' -o ./cloudflared
chmod +x ./cloudflared
sudo mv ./cloudflared /usr/local/bin/cloudflared

看一下有没有装好：

cloudflared --version

有版本号就行。

登录 Cloudflare

让本机的 cloudflared 拿到 Cloudflare 账号授权：

cloudflared tunnel login

命令会给一个链接。复制到浏览器打开，登录 Cloudflare，选择你要用的域名，然后授权。

授权成功后，本机会生成一个证书文件。这个文件别乱删，后面创建隧道要用。

创建隧道

给隧道起个名字，比如 home-web：

cloudflared tunnel create home-web

输出里会有两个关键信息：

Created tunnel home-web with id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Tunnel credentials written to /root/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

记住这两个：

• 隧道 ID
• credentials 文件路径

后面配置文件要填。

写配置文件

创建配置目录：

sudo mkdir -p /etc/cloudflared
sudo nano /etc/cloudflared/config.yml

示例配置：

tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
credentials-file: /root/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:80

  - hostname: admin.example.com
    service: http://127.0.0.1:8080

  - service: http_status:404

这里别照抄域名。换成你自己的。

ingress 是按顺序匹配的，最后那个 404 建议留着。不然没匹配到的请求怎么处理会比较乱。

配置写完先检查：

cloudflared tunnel ingress validate

能过再继续。

绑定域名

把域名指到这个 Tunnel：

cloudflared tunnel route dns home-web app.example.com
cloudflared tunnel route dns home-web admin.example.com

如果提示 DNS 记录冲突，去 Cloudflare 面板把旧的 A、AAAA、CNAME 记录删掉，再执行一次。

先手动跑一下

别急着装服务，先跑起来看看：

cloudflared tunnel run home-web

然后访问你的域名：

https://app.example.com

能打开就说明主流程没问题。

如果打不开，优先看这几个点：

• 本地服务是不是还活着。
• hostname 有没有写错。
• Cloudflare DNS 有没有指到 Tunnel。
• 服务器时间是不是离谱。
• 配置文件路径是不是对的。

设置开机启动

确认手动运行没问题后，再装成 systemd 服务：

sudo cloudflared service install
sudo systemctl enable --now cloudflared

看状态：

sudo systemctl status cloudflared

看实时日志：

journalctl -u cloudflared -f

日志里能看到连接成功，域名也能访问，就差不多了。

常用命令

一点安全建议

Tunnel 不等于你可以什么都裸奔。

如果是管理面板，最好再加一层登录，或者用 Cloudflare Access 限制访问。不然只是端口没暴露，服务本身该被扫还是可能被扫。

简单说：公网能访问的东西，就按公网服务来处理。别侥幸。

没有公网 IP，端口映射不会配，运营商还可能封端口。折腾半天，最后朋友还是连不上，挺抽象。

我这里用 WireGuard + 一台 VPS 解决。核心思路是：让家里的电脑和 VPS 先进同一个虚拟局域网，再让玩家通过 VPS 或虚拟 IP 连进来。

适用场景

这篇适合自己在家里或宿舍开 Minecraft 服务端，但朋友从外网连不进来的情况。

• 没有公网 IP，或者公网 IP 不稳定。
• 不想在路由器上手动做复杂端口映射。
• 有一台能访问公网的 VPS。
• 能接受 Minecraft 流量经过 VPS 中转。

如果你已经有公网 IP，并且端口映射能稳定工作，那可以不用 WireGuard。

两种方案

先看需求，不要上来就把所有人都拉去装 WireGuard。

新手建议先用方案 A。能跑起来再说，别一开始就搞复杂。

前置条件

你需要：

1. 一台有公网 IP 的 VPS，Debian/Ubuntu 最省事。
2. 服主电脑上装 WireGuard 客户端。
3. VPS 防火墙和云厂商安全组放行：
   • UDP 51820
   • TCP 25565
4. 服主电脑上能正常启动 Minecraft 服务端。

如果 Minecraft 本机都连不上，先修 Minecraft，不要怀疑 WireGuard。

最终效果

做完以后，朋友可以通过 VPS 入口连接你的 Minecraft 服务端。服主电脑和 VPS 之间用 WireGuard 组成虚拟局域网，VPS 负责把外部玩家的连接转到家里的服务器。

如果用方案 B，玩家也能加入同一个 WireGuard 网络，体验更像局域网联机。

VPS 安装 WireGuard

在 VPS 上执行：

sudo apt update
sudo apt install wireguard -y

生成服务端密钥：

sudo mkdir -p /etc/wireguard
cd /etc/wireguard
wg genkey | sudo tee privatekey | wg pubkey | sudo tee publickey

看公钥：

sudo cat /etc/wireguard/publickey

私钥别发给别人。公钥可以发。

开启转发：

sudo sysctl -w net.ipv4.ip_forward=1
sudo sed -i '/net.ipv4.ip_forward=1/s/^#//' /etc/sysctl.conf
sudo sysctl -p

方案 A：公网转发

这个方案下，朋友不用装 WireGuard。他们直接连 VPS公网IP:25565。

1. 服主电脑生成密钥

打开 WireGuard 客户端，添加一个空隧道。客户端会自动生成私钥和公钥。

你只需要复制服主电脑的公钥，等会填到 VPS 配置里。

2. VPS 写配置

编辑配置文件：

sudo nano /etc/wireguard/wg0.conf

示例：

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <VPS私钥>

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A PREROUTING -p tcp --dport 25565 -j DNAT --to-destination 10.0.0.2
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D PREROUTING -p tcp --dport 25565 -j DNAT --to-destination 10.0.0.2

[Peer]
PublicKey = <服主电脑公钥>
AllowedIPs = 10.0.0.2/32

10.0.0.2 就是服主电脑在 WireGuard 里的虚拟 IP。

3. 服主电脑写配置

在 WireGuard 客户端里填：

[Interface]
PrivateKey = <服主电脑私钥>
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <VPS公钥>
Endpoint = <VPS公网IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

这里的 PrivateKey 一般客户端已经自动填好了，不要手欠复制错。

4. 启动测试

VPS 上启动：

sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

服主电脑启动 WireGuard。

然后在服主电脑上测试：

ping 10.0.0.1

能 ping 通，说明隧道通了。

接着启动 Minecraft 服务端。朋友连接：

<VPS公网IP>:25565

如果连不上，先看 VPS 的 25565 有没有放行，再看本地防火墙有没有挡 Java。

方案 B：全员组网

这个方案更像真正的虚拟局域网。每个人都有一个 10.0.0.x 地址。

适合固定几个人长期玩。缺点也很明显：每个人都要装客户端，配置发错一个就会连不上。

1. 收集每个人的公钥

让每个玩家装 WireGuard，添加空隧道，把公钥发给你。

给每个人分一个 IP：

不要重复。重复就寄。

2. VPS 配置

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <VPS私钥>

[Peer]
PublicKey = <服主公钥>
AllowedIPs = 10.0.0.2/32

[Peer]
PublicKey = <玩家A公钥>
AllowedIPs = 10.0.0.3/32

[Peer]
PublicKey = <玩家B公钥>
AllowedIPs = 10.0.0.4/32

每加一个人，就加一个 [Peer]。

3. 玩家客户端配置

每个人的配置长得差不多，只是私钥和地址不同。

服主：

[Interface]
PrivateKey = <服主自己的私钥>
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <VPS公钥>
Endpoint = <VPS公网IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

玩家 A：

[Interface]
PrivateKey = <玩家A自己的私钥>
Address = 10.0.0.3/24
DNS = 1.1.1.1

[Peer]
PublicKey = <VPS公钥>
Endpoint = <VPS公网IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

私钥必须是每个人自己的。别把同一个配置群发，真不行。

4. 连接游戏

VPS 启动：

sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

所有人启动 WireGuard 后，互相 ping 一下：

ping 10.0.0.1
ping 10.0.0.2

能 ping 通，玩家就直接连服主虚拟 IP：

10.0.0.2:25565

排错

几个常见问题：

看 WireGuard 状态：

sudo wg

有 latest handshake 才算连上。没有握手就别看 Minecraft，问题还在网络层。

最后

我个人建议：

• 临时开服：方案 A。
• 固定朋友长期玩：方案 B。
• 不想给每个人讲配置：方案 A。
• 想延迟低一点、也更私密：方案 B。

先跑通，再优化。网络这东西一上来就追求完美，最后大概率卡在一个很蠢的配置上。