High CPU usage and connection leak due to IPv6 issues on networks with broken IPv6 connectivity

[ShmakovPavel]

TL;DR

mtg (version 2.2.8) causes 90%+ CPU usage and accumulates thousands of ESTABLISHED connections when running on a host where IPv6 is partially unavailable (ICMP works, but specific Telegram IPv6 prefixes are unreachable). The issue persists even after disabling IPv6 via sysctl and ip6tables.

Environment

• mtg version: 2.2.8 (also reproducible on 2.2.7)
• Deployment: Docker with --network=host
• Host OS: Ubuntu 22.04 (VPS provider)
• Network: IPv6 partially available (server has IPv6, can ping google.com IPv6, but specific Telegram IPv6 prefixes are unreachable)

Config (sanitized)

debug = false
secret = "<YOUR_SECRET>"
bind-to = "0.0.0.0:443"
concurrency = 2000
ad_tag = "<YOUR_TAG>"
tolerate-time-skewness = "10s"
prefer-ip = "prefer-ipv4"
ipv6 = false
ipv6-only = false

[network]
doh-ip = "9.9.9.9"
ipv4-only = true
prefer-ipv4 = true

[network.timeout]
tcp = "5s"
http = "10s"
idle = "1m"

[defense.anti-replay]
enabled = true
max-size = "1mib"
error-rate = 0.001

Symptoms

1. CPU spikes to 90%+ with only a few dozen active users
2. Thousands of ESTABLISHED connections from a single IP (Docker host 172.17.0.1)
3. Persistent IPv6 connection attempts despite all configuration flags:
   {"level":"warn","dc":203,"logger":"proxy","error":"no addresses to call: dial tcp6 [2a0a:f280:203:a:5000::100]:443: connect: cannot assign requested address","message":"cannot dial to telegram"}
4. ss shows active IPv6 connections even after ip6tables -P OUTPUT DROP and sysctl net.ipv6.conf.all.disable_ipv6=1

What I've tried (none worked)

• Setting ipv6 = false, ipv4-only = true, prefer-ipv4 = true
• System-level IPv6 disable: sysctl -w net.ipv6.conf.all.disable_ipv6=1
• Firewall block: ip6tables -P OUTPUT DROP and ip6tables -P INPUT DROP
• Environment variables: GODEBUG=netdns=go, MTG_IPV6=false
• Custom DNS with options inet4

The issue only temporarily resolves after docker restart, but connections gradually accumulate again.

Hypothesis

The issue likely started after commit "Change IP address set priority" (around v2.2.7). Version 2.2.5 appears stable (need confirmation). It seems mtg ignores both system-level and application-level IPv6 disable flags when the host has partial IPv6 connectivity (ICMP works, but specific prefixes are unreachable). This creates a loop of failed connection attempts, leaking file descriptors and consuming CPU.

Expected behavior

When ipv6 = false or ipv4-only = true is set, mtg should never attempt to dial IPv6 addresses, regardless of DNS responses or system capabilities.

Additional context

• The proxy works fine for actual clients (messages are delivered)
• The issue is not about client IPs (all traffic goes through Docker NAT)
• This happens on a specific VPS provider; may affect other providers with similar IPv6 routing

Request

Please investigate why mtg ignores ipv6 = false and ipv4-only = true settings on hosts with partial IPv6 connectivity. The ability to completely disable IPv6 is critical for deployments on networks where IPv6 is unreliable.

[dolonet]

The config has several keys that mtg does not recognize and silently ignores: ipv6, ipv6-only, and the entire [network] ipv4-only / prefer-ipv4. The only valid switch is top-level prefer-ip, and "prefer-ipv4" is not the same as "disable IPv6" — it tries IPv4 first but still falls back to IPv6. See mtglib/internal/dc/telegram.go GetAddresses: the prefer-ipv4 branch returns append(getV4, getV6...), so on partial/broken IPv6 every call still eventually dials tcp6.

To fully exclude IPv6:

prefer-ip = "only-ipv4"

(valid values: prefer-ipv4, prefer-ipv6, only-ipv4, only-ipv6 — see internal/config/type_prefer_ip.go).

On the v2.2.5→v2.2.7 regression hypothesis: PR #428 "Change IP address set priority" reordered the hardcoded default address set vs. the auto-updated one (so auto-update no longer needs to be disabled) — it did not change IPv4/IPv6 ordering. IPv6 addresses were always in the list under prefer-ipv4. v2.2.5 most likely just happened to pick a working IPv4 first every time.

A real meta-bug worth fixing: the TOML parser (go-toml/v2, called via toml.Unmarshal in internal/config/parse.go) does not reject unknown fields by default, so typos and misremembered option names fail silently — exactly the trap this config fell into. Happy to open a PR enabling strict decoding (decoder.DisallowUnknownFields(true)) so such configs fail loudly at startup. @9seconds — would that be welcome?

---

В конфиге несколько ключей, которых в mtg нет, и они молча игнорируются: ipv6, ipv6-only, секция [network] с ipv4-only/prefer-ipv4. Реально работает только prefer-ip на верхнем уровне, и "prefer-ipv4" — это не «отключить IPv6», а «сначала IPv4, потом IPv6»: в mtglib/internal/dc/telegram.go ветка prefer-ipv4 возвращает append(getV4, getV6...), поэтому при битом IPv6 tcp6 всё равно дёргается на каждый fallback.

Чтобы полностью убрать IPv6:

prefer-ip = "only-ipv4"

(допустимые значения: prefer-ipv4, prefer-ipv6, only-ipv4, only-ipv6 — см. internal/config/type_prefer_ip.go).

Про регрессию v2.2.5→v2.2.7: PR #428 «Change IP address set priority» поменял приоритет хардкоженного набора адресов относительно автообновляемого (чтобы больше не нужно было отключать auto-update), а не порядок IPv4/IPv6. IPv6-адреса в списке с prefer-ipv4 были всегда. На v2.2.5, скорее всего, просто везло с первым IPv4.

Отдельный баг — парсер TOML (go-toml/v2, toml.Unmarshal в internal/config/parse.go) по умолчанию не ругается на неизвестные поля, поэтому опечатки и придуманные имена опций молча игнорируются — именно в эту ловушку и попал конфиг. Готов прислать PR со строгим декодированием (decoder.DisallowUnknownFields(true)), чтобы такие конфиги падали при старте. @9seconds — если ок, пришлю.

[ShmakovPavel]

@dolonet Огромное спасибо за подробный разбор репорта. Извиняюсь за фантомные опции: чукча не кодер, чукча бизнес аналитик с курсором.
По итогу: prefer-ip = "only-ipv4" помог с изначально проблемой висящих соединений на ipv6 адреса.

Дальше просто для информации:
Вскрылось, что если в системе запрещено использование ipv6, то mtg, насколько я понял, все равно резолвит ipv6 адрес из секрета и пытается обращаться к нему:
dial tcp6 ... network is unreachable
Включение ipv6 обратно помогает.

Без переменной GODEBUG=netdns=go накапливаются и грузят ошибки
dial tcp: lookup ...: operation was canceled