本文说明 VPS 上系统、TCP、代理、DNS 与 IPv6 的配置和验收方法。部署前需确认发行版支持周期、内核权限与云平台网络条件。
各项配置应独立验证。先确认虚拟化类型、发行版、网络与控制台恢复能力，备份关键配置；不能一次更换内核、默认路由、DNS 和代理服务后再判断哪一步导致失联。
一、使用受支持的基础系统
查看 /etc/os-release 和当前运行内核，使用发行版提供的安全更新。Debian 11 的 LTS 已于 2026-08-31 结束，不再作为新 VPS 推荐；当前 Debian 13 为 Trixie。Debian 11 生命周期、Debian 发布信息
Debian 10→11 只是一次历史迁移阶段，后续大版本需要按各版本 release notes 逐阶段升级。全局替换所有源代号、对配置提示统一选 yes，不是完整升级方法。云平台提供的镜像与网络代理也要核对，先具备控制台和可恢复备份再执行。
二、先测量，再决定是否启用标准 BBR
标准 BBR 与民间 BBR PLUS、自定义内核或用户态 TCP 栈不是同一组件。TCP 拥塞控制不能突破物理带宽，也不能保证解决运营商 QoS、UDP 丢包或流媒体访问限制。
先查看宿主或完整 VM 实际支持的算法与队列：
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
tc qdisc show
如果内核提供 tcp_bbr 模块但尚未加载，可先 sudo modprobe tcp_bbr 再查询。确认存在后，可测试：
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
记录原值，用相同对端、方向和负载比较吞吐、时延与丢包。默认 qdisc 修改不自动替换所有现有接口队列，算法变更也应对新建 TCP 连接验收。确定有效后再写独立 sysctl 文件，出问题按原值恢复。Linux TCP 参数文档
OpenVZ/LXC 等共享宿主内核的实例通常不能自行更换宿主内核或全局 TCP 策略；是否开放相关 namespace 参数取决于服务商。不要为了这一限制直接运行旧 lkl-haproxy、短链接或来历不明的 root 脚本。
三、代理服务与部署脚本
Xray 的协议与配置按上游文档维护。xray-agent 仓库是部署管理脚本，其访问目标与功能取决于具体脚本版本，不能假定只访问 GitHub。脚本还可能安装依赖、申请证书、访问 DNS API 并修改防火墙。
使用前选择明确提交或发布版本，下载到本地审查内容及依赖来源，保留变更前的服务、网络与证书配置。不要关闭证书校验，也不要将未经检查的远程内容直接交给 shell。下载校验失败时修复 CA/系统时间/来源，不绕过验证。
安装后先识别服务实际使用的程序与配置路径：
systemctl cat xray
systemctl status xray
journalctl -u xray -n 100 --no-pager
服务可能使用 -confdir 合并多个文件，名称和路径以自己的 unit 为准。按实际二进制与参数测试配置，例如：
/实际路径/xray run -test -config /实际路径/config.json
-test 只检查配置，不启动服务；仍需要验证监听、TLS/证书、客户端连接及出站行为。Xray 命令参数
geosite/geoip 更新不要用 wget -O 直接覆盖正在使用的文件：下载失败可能留下空文件，两个数据文件也可能来自不同批次。应在临时目录下载同一明确版本，检查完整性、大小和提供方的校验信息，使用配置副本与新资源进行测试，备份旧文件后替换；重启失败时同时恢复旧配置和对应资源。没有这套失败处理前不安排定时自动重启。
四、WARP 与地址选择
希望使用 WARP 时，优先按Cloudflare 官方 Linux 客户端说明确认受支持发行版与官方包仓库。客户端的 DNS 模式、全流量模式和代理模式不能混为一谈；远程服务器启用前先规划管理流量与回退路径，避免默认路由变化影响 SSH。
在已安装且确认适用的客户端上，首次注册与连接流程为：
warp-cli registration new
warp-cli connect
warp-cli status
curl https://www.cloudflare.com/cdn-cgi/trace
以实际状态和 warp=on 验证当前请求，不承诺解锁指定平台或固定地区；第三方 WireGuard 配置脚本也不等同于官方客户端。
glibc 的 /etc/gai.conf 影响部分程序的地址排序，不保证浏览器、代理内核或带有 Happy Eyeballs 的应用照此选择。precedence ::ffff:0:0/96 100 是偏向 IPv4 的规则示例，但自定义一条 precedence 可能替换整套默认表，应按 man page 审查完整配置；label 2002::/16 2 只涉及特定 6to4 前缀，不是通用的“IPv6 优先开关”。gai.conf 手册
优先使用应用自己的地址/出站选择设置，并分别用 curl -4、curl -6 检查连通性。单次访问一个 IP 查询站，不能证明系统所有应用的优先级。
五、AdGuard Home 的 DNS 与端口
按AdGuard Home 上游说明安装对应架构的正式发布包，记录版本与校验信息，备份配置和工作数据。升级优先使用产品支持的更新路径；手工更换二进制时先停服务、保留旧文件、测试后恢复服务。
部署前查看监听和解析器状态：
sudo ss -lntup
ls -l /etc/resolv.conf
cat /etc/resolv.conf
DNS 通常同时需要 TCP/UDP 53，管理界面与加密 DNS 另有端口。公网 VPS 上限制可信客户端，不能把递归解析器无认证暴露成开放 DNS。
若 systemd-resolved 占用 127.0.0.53:53，可以选择其他具体地址供 AdGuard Home 监听，或按官方 FAQ调整 stub listener 及 resolv.conf。不能先 stop/disable resolved，再留下指向已经停用的 stub 地址；也不能忽略 AdGuard 自身上游 DNS 是否形成循环。
验证从目标客户端解析正常、重启后仍正常，以及 AdGuard 停止时有没有需要的回退 DNS，再决定如何整合服务。
六、HE 6in4 隧道是有条件的 IPv6 方案
优先使用服务商原生 IPv6。HE Tunnel Broker 的 6in4 通过 IPv4 协议号 41 封装，不是 TCP/UDP 的“41 端口”；放行端口 41 没有解决同一个问题。IANA 协议号登记
创建前确认服务商允许协议 41，端点 IPv4 与注册信息对应，防火墙和 MTU 可用。有 NAT 时还需要路由器/服务商正确转发该协议，不能只将 local 改成私网地址就保证工作。隧道路由可能绕行，是否改善性能要实际测量，不能承诺规避 QoS 或断言所有流量都绕美国。
已有隧道时，以其 Example Configuration 为准。对由 ifupdown 管理的 Debian，可只在一个被 includes 引用的 /etc/network/interfaces.d/he-ipv6 文件中配置；不要同样写入主文件而造成重复：
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:db8:1234::2
netmask 64
endpoint 203.0.113.20
local 198.51.100.10
ttl 255
mtu 1480
gateway 2001:db8:1234::1
这里全是文档示例地址，不能照抄联网。用自己的 Client IPv6、Server IPv6、Server IPv4 和本机 IPv4 替换；隧道链路 /64 与另行分配的 routed prefix 是不同概念。1480 仅适用于相应 IPv4 MTU 条件，实际路径更小时要重新确定 MTU。ifupdown 配置手册
在控制台应用该接口，再检查地址、路由和真实 IPv6 请求：
sudo ifup he-ipv6
ip -6 address show dev he-ipv6
ip -6 route
curl -6 https://www.cloudflare.com/cdn-cgi/trace
不要因某个网站禁 ICMP 就断言隧道失败，也不要为一个接口重启全部网络服务。停用时先 ifdown he-ipv6，再移除其唯一配置和相关路由/防火墙规则；明确是自己的独立隧道后，再在服务端删除它。每次网络变更都应验证管理连接和关键业务的回退。
评论区