华润赢
@huarunying
LeadaxeLxBox / sing-box-lx 开发者
值得推荐作者发言
GitHub

Leadaxe：反对新增 ipv6_fallback_ipv4 自动策略，给出四条理由与替代配置

Leadaxe 在 sing-box-lx #27（新增 DNS 策略的功能请求，已关闭）发布一份立场为「反对」的分析（原帖注明该分析由 AI agent Claude 代整理）：自动模式唯一的好处是不用手写域名列表，但代价更大——1）用 geosite 规则集挂 ipv6_only、其余走 prefer_ipv6，两条规则已能达到几乎相同的覆盖，验证码主要来自 Google 与 Cloudflare；2）若到达服务端的是域名而非 IP（sniff 的 override_destination、fakeip、不经 TUN 的应用代理），地址族由服务端决定，客户端 DNS 策略不影响出网地址，自有服务端应在服务端配置（如 Xray freedom 的 domainStrategy: UseIPv6v4）；3）有 AAAA 但实际 IPv6 不通的站点常见，自动模式下故障会变成零星的站点不可用、难以定位；4）需要整条路径都有 IPv6——TUN 没有 inet6_address 时系统在 AI_ADDRCONFIG 下根本不请求 AAAA，服务端出口无 IPv6 则所有带 AAAA 的域名不可达。他还列出会改变评估的三个条件（Google/Cloudflare 之外确有相当比例的验证码站点、确认到服务端的是 IP 字面量而非域名、自有服务端为何不能在服务端设置），结论是现有两条规则已能解决，暂不新增该策略。

作者原文

🤖 Анализ подготовлен AI-агентом Claude (Anthropic). Позиция: против.

Зачем нужна стратегия ipv6_fallback_ipv4

Автоматический режим даёт одно: не нужно вести список доменов вручную. Капча зависит от репутации адреса, а не от домена, поэтому в идеале режим уберёт её везде, где у сайта есть AAAA. Ниже — почему этой пользы недостаточно.

Аргументы против

1. Список доменов уже ведётся готовым rule-set

Вместо ручного domain_suffix можно подключить готовый rule-set и повесить на него ipv6_only:

"rules": [
  {
    "rule_set": ["geosite-google", "geosite-cloudflare"],
    "server": "default",
    "strategy": "ipv6_only"
  },
  {
    "server": "default",
    "strategy": "prefer_ipv6"
  }
]

Это те же два правила, но список сопровождают авторы geosite, а не пользователь. Основная доля капчи приходится на Google и Cloudflare-челленджи, так что охват почти тот же, что у автоматического режима.

2. Семейство адреса часто выбирает сервер, а не клиент

Если до сервера доходит домен, а не IP (sniff с override_destination, fakeip, приложение через прокси без TUN), сервер резолвит его сам. Тогда клиентская DNS-стратегия на выходной адрес не влияет. Для своего сервера правильное место — его конфигурация, например domainStrategy: UseIPv6v4 у freedom в Xray. Клиентская стратегия помогает только тогда, когда до сервера доходит IP-литерал.

3. Сбои сложнее диагностировать

Сайты, у которых AAAA опубликован, но IPv6 фактически не работает (CDN, частично живой IPv6 у провайдера VPN), встречаются регулярно. При списке ломается конкретный домен, и связь с правилом очевидна. В автоматическом режиме сайты отказывают выборочно, и понять, что виновата DNS-стратегия, трудно.

4. Нужен IPv6 на всём пути

  • Если у TUN нет IPv6-адреса (inet6_address), ОС при AI_ADDRCONFIG вообще не запрашивает AAAA. А приложение, получившее только AAAA, не сможет подключиться.
  • Если IPv6 нет на выходе VPN-сервера, все домены с AAAA станут недоступны, хотя IPv4 у них есть.

В режиме списка эти требования касаются нескольких доменов, в автоматическом — почти всего интернета.

Что бы изменило оценку

  • Заметная доля сайтов с капчей по IPv4, которые не покрываются geosite-google / geosite-cloudflare.
  • Подтверждение, что до сервера доходит IP-литерал, а не домен, иначе клиентская стратегия ничего не изменит.
  • Если сервер свой — объяснение, почему не подходит настройка семейства на сервере.

Вывод

Задача уже решается двумя правилами с готовым rule-set, без новой стратегии. Автоматический режим экономит сопровождение списка, но распространяет требование рабочего IPv6 на все домены с AAAA и делает сбои менее очевидными. Пока нет примеров капчи вне Google/Cloudflare, польза не перевешивает цену.

返回动态列表查看原文