标签 网络配置 下的文章

浏览了社区和 GitHub 上众多的 Surge 配置仓库,我发现一个普遍痛点:配置项冗余且混乱。很多早已废弃的参数、默认即可的开关、甚至相互冲突的规则被盲目复制粘贴,对于追求极致整洁的强迫症患者来说,阅读这些配置文件简直是一种折磨。

为此,我决定重构一份 “反熵增” 的配置清单。

核心原则:如无必要,勿增实体。

  1. 剔除默认值:如果 Surge 的默认行为已经合理,绝不显式写入配置文件。
  2. 拒绝无效参数:清理死代码和过时配置(如 VIF 模式下的 skip-proxy)。
  3. 仅保留关键:只体现需要根据国情额外配置的,或社区公认的最佳实践(Best Practice)。

基于以上原则,我整理了以下配置。希望它能成为一份逻辑自洽、甚至赏心悦目的基准配置。欢迎大家从原理层面进行 “代码审查” 和讨论,我们将持续迭代更新。

[General] 核心设置

[General]
# --- 连接稳定性与测试 ---
# 开启 Wi-Fi 助理:当 Wi-Fi 信号极差或无法联网时,自动使用蜂窝数据
wifi-assist = true
# 连通性测试:用于检测是否具备互联网访问能力
internet-test-url = http://wifi.vivo.com.cn/generate_204
# 代理测速:用于测试代理节点的延迟基准
proxy-test-url = http://cp.cloudflare.com/generate_204

# --- 物理网络旁路 (核心优化) ---
# 作用:流量不经过 Surge 虚拟网卡,直接由物理网卡处理 (VIF 模式下唯一有效的绕过方式)
# 1. 192/10/172: 解决局域网传输 (NAS) 发热、跑不满带宽的问题;确保公共 Wi-Fi 认证页面正常弹出
# 2. 100.64: 解决 Tailscale/ZeroTier 组网连接失败、运营商内网服务异常
# 3. 224/239/255: 解决 AirPlay 投屏找不到设备、智能家居 SSDP 发现问题
tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, 239.255.255.250/32, 224.0.0.0/24, 255.255.255.255/32

# --- DNS 解析 ---
# 策略:阿里(223) + 腾讯(119) 提供高可用解析,System 作兜底
# 注意:保留 system 是为了在公共 Wi-Fi 未认证(外网不通)时,能获取路由器下发的内网 IP 以弹出登录页
dns-server = 223.5.5.5, 119.29.29.29, system
# 劫持转发:强制接管设备内所有发往 53 端口的 DNS 查询 (防止 App 自定义 DNS 导致分流失效)
hijack-dns = *:53

按需选配:

# ============================================
# Optional / Advanced Settings (按需启用)
# ============================================

# --- 远程控制器 (HTTP API) ---
# 允许通过 HTTP API 控制 Surge (如 Yacd 面板 / 快捷指令)
# http-api = pass@127.0.0.1:6171
# http-api-tls = false
# http-api-web-dashboard = false

# --- 局域网访问 (Wi-Fi/热点共享) ---
# 允许局域网内其他设备连接本机的代理服务
# allow-wifi-access = false
# allow-hotspot-access = true
# 代理服务监听端口 (默认 HTTP:6152, SOCKS5:6153)
# wifi-access-http-port = 6152
# wifi-access-socks5-port = 6153

# --- 高级网络行为 ---
# 隐藏状态栏 VPN 图标 
# hide-vpn-icon = false
# 排除简单主机名 (不包含点的域名) 走代理,通常用于让内部域名强制直连
# exclude-simple-hostnames = true
# IPv6 支持 (默认关闭,国内环境建议保持关闭以提升兼容性)
# ipv6 = false
# 当遇到 REJECT 策略时,是否显示网页报错页面 (默认为直接断开)
# show-error-page-for-reject = true
# UDP 转发失败时的回退行为 (默认为 REJECT,可选 DIRECT)
# udp-policy-not-supported-behaviour = REJECT

# --- DNS 与数据源 ---
# 加密 DNS (DoH/DoQ): 除非有抗污染强需求,否则不建议开启,会增加延迟
# encrypted-dns-server = https://223.5.5.5/dns-query, quic://dns.alidns.com
# 自定义 GeoIP 数据库源 (仅当默认数据库不准时使用)
# geoip-maxmind-url = https://raw.githubusercontent.com/Loyalsoldier/geoip/release/Country.mmdb
# 从 /etc/hosts 读取 DNS 记录 (仅 macOS)
# read-etc-hosts = true

# --- 遗留与替代项 (不推荐使用) ---
# [VIF Mode 无效] 即使配置也被忽略,物理直连请使用 tun-excluded-routes
# skip-proxy = 192.168.0.0/24, 10.0.0.0/8, 172.16.0.0/12, *.local, localhost

# [建议使用模块] 强制返回真实 IP (解决游戏 NAT 类型或去 IP 校验)
# 推荐使用 Surge 模块或 Rule 进行管理,保持主配置简洁
# always-real-ip = *.srv.nintendo.net, *.stun.playstation.net, xbox.*.microsoft.com

未完待续…


📌 转载信息
转载时间:
2026/1/24 10:34:11

浏览了社区和 GitHub 上众多的 Surge 配置仓库,我发现一个普遍痛点:配置项冗余且混乱。很多早已废弃的参数、默认即可的开关、甚至相互冲突的规则被盲目复制粘贴,对于追求极致整洁的强迫症患者来说,阅读这些配置文件简直是一种折磨。

为此,我决定重构一份 “反熵增” 的配置清单。

核心原则:如无必要,勿增实体。

  1. 剔除默认值:如果 Surge 的默认行为已经合理,绝不显式写入配置文件。
  2. 拒绝无效参数:清理死代码和过时配置(如 VIF 模式下的 skip-proxy)。
  3. 仅保留关键:只体现需要根据国情额外配置的,或社区公认的最佳实践(Best Practice)。

基于以上原则,我整理了以下配置。希望它能成为一份逻辑自洽、甚至赏心悦目的基准配置。欢迎大家从原理层面进行 “代码审查” 和讨论,我们将持续迭代更新。

[General] 核心设置

[General]
# --- 连接稳定性与测试 ---
# 开启 Wi-Fi 助理:当 Wi-Fi 信号极差或无法联网时,自动使用蜂窝数据
wifi-assist = true
# 连通性测试:用于检测是否具备互联网访问能力
internet-test-url = http://wifi.vivo.com.cn/generate_204
# 代理测速:用于测试代理节点的延迟基准
proxy-test-url = http://cp.cloudflare.com/generate_204

# --- 物理网络旁路 (核心优化) ---
# 作用:流量不经过 Surge 虚拟网卡,直接由物理网卡处理 (VIF 模式下唯一有效的绕过方式)
# 1. 192/10/172: 解决局域网传输 (NAS) 发热、跑不满带宽的问题;确保公共 Wi-Fi 认证页面正常弹出
# 2. 100.64: 解决 Tailscale/ZeroTier 组网连接失败、运营商内网服务异常
# 3. 224/239/255: 解决 AirPlay 投屏找不到设备、智能家居 SSDP 发现问题
tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, 239.255.255.250/32, 224.0.0.0/24, 255.255.255.255/32

# --- DNS 解析 ---
# 策略:阿里(223) + 腾讯(119) 提供高可用解析,System 作兜底
# 注意:保留 system 是为了在公共 Wi-Fi 未认证(外网不通)时,能获取路由器下发的内网 IP 以弹出登录页
dns-server = 223.5.5.5, 119.29.29.29, system
# 劫持转发:强制接管设备内所有发往 53 端口的 DNS 查询 (防止 App 自定义 DNS 导致分流失效)
hijack-dns = *:53

按需选配:

# ============================================
# Optional / Advanced Settings (按需启用)
# ============================================

# --- 远程控制器 (HTTP API) ---
# 允许通过 HTTP API 控制 Surge (如 Yacd 面板 / 快捷指令)
# http-api = pass@127.0.0.1:6171
# http-api-tls = false
# http-api-web-dashboard = false

# --- 局域网访问 (Wi-Fi/热点共享) ---
# 允许局域网内其他设备连接本机的代理服务
# allow-wifi-access = false
# allow-hotspot-access = true
# 代理服务监听端口 (默认 HTTP:6152, SOCKS5:6153)
# wifi-access-http-port = 6152
# wifi-access-socks5-port = 6153

# --- 高级网络行为 ---
# 隐藏状态栏 VPN 图标 
# hide-vpn-icon = false
# 排除简单主机名 (不包含点的域名) 走代理,通常用于让内部域名强制直连
# exclude-simple-hostnames = true
# IPv6 支持 (默认关闭,国内环境建议保持关闭以提升兼容性)
# ipv6 = false
# 当遇到 REJECT 策略时,是否显示网页报错页面 (默认为直接断开)
# show-error-page-for-reject = true
# UDP 转发失败时的回退行为 (默认为 REJECT,可选 DIRECT)
# udp-policy-not-supported-behaviour = REJECT

# --- DNS 与数据源 ---
# 加密 DNS (DoH/DoQ): 除非有抗污染强需求,否则不建议开启,会增加延迟
# encrypted-dns-server = https://223.5.5.5/dns-query, quic://dns.alidns.com
# 自定义 GeoIP 数据库源 (仅当默认数据库不准时使用)
# geoip-maxmind-url = https://raw.githubusercontent.com/Loyalsoldier/geoip/release/Country.mmdb
# 从 /etc/hosts 读取 DNS 记录 (仅 macOS)
# read-etc-hosts = true

# --- 遗留与替代项 (不推荐使用) ---
# [VIF Mode 无效] 即使配置也被忽略,物理直连请使用 tun-excluded-routes
# skip-proxy = 192.168.0.0/24, 10.0.0.0/8, 172.16.0.0/12, *.local, localhost

# [建议使用模块] 强制返回真实 IP (解决游戏 NAT 类型或去 IP 校验)
# 推荐使用 Surge 模块或 Rule 进行管理,保持主配置简洁
# always-real-ip = *.srv.nintendo.net, *.stun.playstation.net, xbox.*.microsoft.com

未完待续…


📌 转载信息
转载时间:
2026/1/24 07:00:09

背景:
昨天开始就频繁的无法连接位于海外 vps 的反代,然后 ping 一下发现丢包率好高,今天突发奇想我的 vps 是带 ipv6 的,因为我部署酒馆的服务器是家庭宽带有公网的 ipv6,我就 ping6 试了一下发现延迟低不少而且丢包率为 0,以此开始以下环节。

适用人群:
使用国内 nas 或者小主机等在自己家部署的酒馆,也就是家庭网络,现在大部分家庭网络都有公网的 ipv6

教程开始:

  1. 检查服务器主机当前 DNS 解析顺序
getent ahosts 你的域名

看输出结果是 ipv6 在前还是在后

1-1.ipv6 在下时,设置 ipv6 优先
查询配置文件

cat /etc/gai.conf

如果出现以下默认配置则代表是 ipv6 优先

#precedence  ::1/128       50 #precedence  ::/0          40 #precedence  2002::/16     30 #precedence ::/96          20 #precedence ::ffff:0:0/96  10 

如果是出现以下,需要给前面加上 #号

precedence ::ffff:0:0/96 100 
  1. 检查 Docker 是否启用 IPv6
docker network inspect bridge | grep -i ipv6

出现以下则代表开启
“EnableIPv6”: true,

2-1. 开启 docker 的 ipv6
1Panel 面板
docker 界面设置,开启 ipv6,子网 fd00::/80
并重启 docker 和容器

  1. 检查容器是否有 IPv6 地址
docker exec 容器名(sillytavern) ip -6 addr

如果出现
enp1s0 和 ipv6 地址则代表获取成功

3-1. 测试容器 ipv6 连通性

docker exec 容器名 ping6 -c 2 你的ipv6地址
  1. 设置容器 IPv6 优先级
    酒馆是 Alpine 容器,在环境变量里添加
NODE_OPTIONS=--dns-result-order=ipv6first

因为 docker 的网段设置是默认不带 ipv6 的所有在 1panel 里添加环境变量的时候,把网络段设置为 host
在 ssh 里输入如下

docker exec 容器名 node -e "
2const dns = require('dns');
3dns.lookup('你的域名', { all: true }, (err, addrs) => {
4 console.log(addrs);
5});
6"
7

ipv6 在前则设置成功
在验证一下

docker exec 容器名 node -e "
const dns = require('dns');
dns.lookup('你的域名', (err, addr, family) => {
console.log('实际使用 IP:', addr);
console.log('IP 版本:', family === 6 ? 'IPv6' : 'IPv4');
});
"

结果显示的是实际使用 ip:你的公网 ipv6 则成功

  1. 修改容器的 config.yaml
protocol: ipv4: true ipv6: true dnsPreferIPv6: true 

📌 转载信息
原作者:
ak7876
转载时间:
2026/1/12 15:39:49

本文会记录下整个过程,以及自己怎么发现并且解决问题,文笔差劲。

前因

  1. 我把家宽(有公网,封禁常规 Web 端口)NAS 部署的服务从腾讯 EO 迁移到 Cloudflare(后续简称 cf),采用的是 cf tunnels 开放内网的形式。
  2. cf tunnels 是通过 Docker 部署的。
  3. 为了体验更好,就又买了一个域名,弄 IP 优选,论坛有具体教程,这里就不多叙述了。
  4. 部署了个人写的博客网站(其实是一个多用户博客,但是目前仅对自己开放)。

问题点:上传文件一直失败

  1. 想上传文件图片作为博文的封面,但是发现上传一直失败,在 openlist、minio 上面上传也失败。
  2. 不通过 cf 直接通过端口访问博客,可以正常上传。
  3. 通过加速域名访问,发现不能上传。

想方设法解决问题

  1. 修改 cf 的配置。WAF 跳过、https、上传文件大小设置成 100M,超时时间默认 120s,发现还是没有效果。
  2. 修改 nginx 配置,也是没用,仔细想一下,我通过源站能上传文件,nginx 肯定是没有问题的,自己还是操作多余了,不过为了谨慎,还是做了一些调整。
  3. 优化代码,减少接口调用时间,图片会存储原图和一张 webp 图,发现原图以 80% 的质量压制成 webp 调用的类库很慢很慢,就换成了一个比较快的类库(截至发文的时候发现和 linux 不兼容,还没修复)。
  4. 通过 https 界面,把上传接口改成源地址的接口,发现 https 调用 http 会报错,但是源地址,又不想去弄 ssl 证书(感觉麻烦,而且还要定期续)。
  5. 在看博客的后台日志记录的时候,发现管道根本就没有具体的执行我接口,就已经被超时中止了,我就开始怀疑是不是在接口调用之前,程序在接受文件,文件还没接受完毕,就被中止了。从而导致上传失败。


最终解决方案

  1. V2EX 的帖子,在下面的评论中找到一个用户的评论,死马当活马医了,在 tunnels 的启动参数里面添加一个 --protocol http2 启动参数。
  2. 重新测试上传,飞牛界面显示下载速度有 1M/s 而且速度是立刻拉上来的,看来问题已经完美解决了。

最后,解决方案可能两种

因为我不确定是我重启了 tunnels 网速变好了,还是添加了参数网速变好了。

  1. 重启 Tunnels
  2. 添加启动参数 --protocol http2, 参数的具体作用我就不去查询了。


感谢各位佬听我 bb。我也是分享一下我自己解决问题的全路径。


📌 转载信息
转载时间:
2026/1/11 08:32:37

我的网络提供商不支持 TCP 长连接,所以我选择直连 fcm 服务器。


最好配置中添加个 FCM 策略组并在配置中添加 fcm 规则,比如像我这样:
#谷歌 fcm

如果你的节点不支持 TCP 长连接的话,请在客户端中设置中打开允许应用绕过选项,否则连接 fcm 服务器超时很久才连上以及连不上。
若支持 TCP 长连接,请关闭允许绕过选项,FCM 服务器走节点可能会产生的功耗和和延迟。


若连不上 fcm 服务器请检查 OEM 设备制造商的联网管理是否允许 Google play 服务相关应用的联网及后台联网,如果不是网络问题与息屏而被厂商掐断禁止联网以及连不上的,请尝试安装对应厂商的国际版的 “手机管家”、安全中心、流量管理、电池等 app 是否缓解问题,如不能解决但不建议停用和卸载它们请谨慎操作,风险自行承担。

不建议在系统 /system/etc/hosts 文件添加 fcm 域名,hosts 导致 fcm 有一些小问题反正我不加也不折腾,因为域名指定绑定某个的 IP,域名的 IP 会随时变动和过期或被黑洞,你 hosts 指定的旧 IP 未及时手动更新可用的 IP,不然旧 IP 被黑洞过期迁移导致连不上,执意添加的话可以在客户端的 hosts 添加 fcm 域名,但不推荐。

fcm 的连接时间没必要追求更高时长,能连接 1 个小时内左右说明系统和息屏没被掐断是稳定的,息屏不断开表示没问题的,偶尔断开超时几分钟是小概率网络环境等问题,又不是连接不上。
连接等疑问参阅官方文档:为 FCM 配置网络  |  Firebase Cloud Messaging
FCM 注册令牌:FCM 注册令牌管理的最佳做法  |  Firebase Cloud Messaging

如果 FCM Diagnostics 出现无微信等应用的推送日志,请尝试(通常无需开科技)打开微信 > 我 > 设置 > 顶部退出登录接着在微信 > 应用信息 > 强行停止下,再打开微信重新登录以便能注册 FCM token,再测试消息是否有日志即可。
不建议在应用分流绕过设置(com.android.settings)、Android 系统(android)等应用。
遇到不注册 fcm 令牌的应用请尝试把它全局并退出登录 强行停止 重新登录。

微信似乎每个月 FCM token 失效过期需要重新注册,不确定是哪方的问题,我在排查中。
fcm 有自动绕过代理的机制,利用允许应用绕过这个开启特性自动绕过代理,我现在 Firebase 官网提供的主机名,之前没加的域名给加上去,fcm.googleapis.com
accounts.google.com
iid.googleapis.com
android.apis.google.com
device-provisioning .googleapis.com
firebaseinstallations.googleapis.com
以便更新 FCM token,看后续微信还会不会 FCM token 过期失效,如果不能解决的话,估计是微信服务器抽风的问题。


📌 转载信息
原作者:
Google106
转载时间:
2026/1/7 19:14:53