Az IPv6-only (csak IPv6-os) VPS-nek nincs nyilvános IPv4 címe: kívülről csak IPv6 címen érhető el, és ő maga is csak IPv6-on éri el az internetet. Az IPv4 címek elfogyása miatt egyre több szolgáltató kínál ilyen, olcsóbb változatot. Hogy neked megéri-e, attól függ, mit futtatnál a szerveren, és kik csatlakoznak hozzá. Ha az IPv6 alapjaival most ismerkedsz, előbb olvasd el a blogcikkünket arról, mi az az IPv6.

Miért drága az IPv4 cím?

Az IPv4 címtér 32 bites, összesen nagyjából 4,3 milliárd címmel. Az európai címeket kiosztó RIPE NCC 2019 novemberében adta ki az utolsó szabad blokkját, azóta új cím szinte csak a másodpiacon szerezhető, ahol egyetlen cím ára több tíz dollár. A szolgáltatók ezt a költséget beépítik a VPS árába, több nagy felhőszolgáltató pedig 2024 óta külön óradíjat számít fel minden nyilvános IPv4 címért.

Az IPv6 címtér 128 bites, gyakorlatilag kimeríthetetlen: egy szerver gyakran egy teljes /64 alhálózatot kap, ami több mint 18 trillió cím. Az IPv6 cím így a szolgáltatónak szinte semmibe sem kerül.

Előnyök

Alacsonyabb ár

Ha a szolgáltatónak nem kell IPv4 címet adnia, a VPS olcsóbb lehet: a különbség szolgáltatónként jellemzően havi fél eurótól néhány euróig terjed. Egyetlen szervernél ez kevés, de ha sok kisebb gépet futtatsz (backend szervereket, workereket, tesztkörnyezeteket), a megtakarítás összeadódik.

Rengeteg cím, címfordítás nélkül

Ha a szolgáltató egy teljes IPv6 alhálózatot ad, minden konténer, virtuális gép vagy szolgáltatás kaphat saját nyilvános címet. Nincs szükség porttovábbításra és NAT-ra, két szolgáltatás akár ugyanazon a porton is futhat, külön címen.

Kevesebb automatikus szkennelés

A teljes IPv4 címtér percek alatt végigpásztázható, ezért egy új IPv4-es szerveren néhány perc múlva megjelennek az első SSH jelszópróbálgatások. Az IPv6 címtér túl nagy a vak szkenneléshez, így a naplók sokkal csendesebbek. Ez azonban nem védelem: a cím kiderülhet a DNS AAAA rekordjából, a Certificate Transparency naplókból vagy a szerver kimenő kapcsolataiból. A tűzfal és az SSH szerver biztonsági beállításai IPv6-on is kötelezők.

Jövőálló megoldás

A mobilhálózatok és sok otthoni internetszolgáltató már IPv6-ot használ, a Google mérése szerint a felhasználók közel fele IPv6-on éri el a szolgáltatásait. Egy IPv6-only szerveren most megtanulhatod, ami később alapértelmezés lesz.

Hátrányok

A csak IPv4-es hálózatokból nem érhető el közvetlenül

Ez a legnagyobb korlát. Sok otthoni és irodai hálózat, céges hálózat, szállodai vagy nyilvános wifi még mindig csak IPv4-et használ. Az innen érkező látogatók nem nyitják meg a weboldaladat, és nem csatlakoznak az SSH-hoz, a játékszerverhez vagy az API-dhoz. Webszervernél ez egy CDN-nel megoldható (lásd lent), más szolgáltatásoknál nehezebben.

Kifelé is csak IPv6

A szerver nem éri el azokat a szolgáltatásokat, amelyek csak IPv4 címmel rendelkeznek. A cikk írásakor (2026 novemberében) ilyen például a GitHub: a github.com, az api.github.com és a ghcr.io konténerregiszter nem érhető el IPv6-on, így a git clone, a GitHubról letöltött kiadások és a GitHubra épülő telepítőszkriptek nem működnek. Ugyanez előfordulhat fizetési szolgáltatók, külső API-k, licenc- és frissítési szerverek esetén is.

A legtöbb alapvető forrás viszont IPv6-on is elérhető: a Debian, az Ubuntu és az AlmaLinux csomagtárolói, a Docker Hub, a PyPI, az npm, a WordPress.org és a Let’s Encrypt is. Hogy egy adott szolgáltatásnak van-e IPv6 címe, a dig paranccsal ellenőrizheted:

dig +short AAAA api.example.com

Ha a parancs nem ír ki semmit, a szolgáltatás csak IPv4-en érhető el.

Önálló levelezőszervernek nem alkalmas

Önálló levelezőszervert, amely közvetlenül az internetről fogad leveleket és oda küldi őket, nem érdemes IPv6-only gépen futtatni. Sok levelezőszerver még csak IPv4-en fogad leveleket, így ezekre nem tudsz küldeni, a csak IPv4-es küldők pedig neked nem tudnak. A nagy levelezőszolgáltatók ráadásul az IPv6-on érkező leveleket szigorúbban ellenőrzik (fordított DNS, SPF, DKIM nélkül elutasítják őket).

Egy elosztott levelezőrendszerben viszont a levelek tárolására jól használható. Ilyenkor egy IPv4 és IPv6 címmel is rendelkező frontend szerver (például Exim és Dovecot proxy) fogadja a beérkező leveleket és a levelezőprogramok IMAP, POP3 és SMTP kapcsolatait, majd továbbítja őket a több tároló backend egyikéhez. A frontend és a backendek közötti forgalom mehet IPv6-on: a backendeket kívülről senkinek nem kell elérnie, így az IPv4 cím csak felesleges költség lenne. A másik lehetőség egy belső hálózat (privát VLAN) a gépek között, ha a szolgáltató kínál ilyet.

Ha nem akarsz saját levelezőrendszert üzemeltetni, bízd a leveleket egy külön e-mail tárhelyre. Ha pedig az alkalmazásod SMTP-n küld értesítőket, ellenőrizd, hogy a kimenő levelezőszerver IPv6-on is elérhető-e.

A saját hálózatodnak is IPv6 kell

Ahhoz, hogy SSH-n csatlakozz a szerverhez, a te internetkapcsolatodnak is IPv6-osnak kell lennie. A saját gépeden ezzel ellenőrizheted:

curl -6 https://ifconfig.co

Ha a parancs nem az IPv6 címedet írja ki, hanem hibát ad, a hálózatod csak IPv4-es. Ilyenkor egy IPv4 és IPv6 címmel is rendelkező közvetítő szerveren (jump hoston) keresztül, VPN-nel, a Cloudflare Tunnel és Access párossal, vagy a szolgáltató webes konzolján érheted el a szervert.

Szoftverek, amelyek IPv4-et feltételeznek

Egyes programok alapértelmezésben csak az IPv4 címen (0.0.0.0) figyelnek, vagy a beállításaikban IPv4 cím szerepel. A Docker konténerek alapértelmezésben csak IPv4 címet kapnak, így IPv6-only gépen az IPv6 támogatást a daemon.json fájlban külön be kell kapcsolni, különben a konténerek nem érik el az internetet. Néhány külső monitorozó és uptime-figyelő szolgáltatás is csak IPv4-ről ellenőriz.

Webszervernél: tegyél elé CDN-t

Weboldalnál a csak IPv4-es látogatók problémája egy CDN-nel megoldható. A CDN a látogatókat IPv4-en és IPv6-on is fogadja, a szerveredhez pedig IPv6-on csatlakozik. A Cloudflare ingyenes csomagja is így működik:

1. Add hozzá a domaint a Cloudflare-hez, és vegyél fel egy AAAA rekordot a VPS IPv6 címével, bekapcsolt proxyval (narancssárga felhő). A rekordra nincs szükség.
2. A szerveren legyen érvényes SSL tanúsítvány, a Cloudflare-ben pedig a Full (strict) mód; a módok különbségét az SSL Cloudflare mögött cikk magyarázza el.
3. Állítsd be a webszervert, hogy a naplóba a látogató valódi IP címét írja, ne a Cloudflare-ét: Nginxnél a real_ip_header CF-Connecting-IP; és a Cloudflare IP-tartományaira mutató set_real_ip_from sorok, Apache-nál a mod_remoteip modul kell hozzá. A tartományok listája a https://www.cloudflare.com/ips/ oldalon található.
4. Ha szeretnéd, a tűzfalon a 80-as és a 443-as portot csak a Cloudflare IPv6-tartományaiból engedd, így a szervert senki nem éri el a CDN megkerülésével.

Más CDN-eknél előbb ellenőrizd, hogy tudnak-e IPv6-only szerverhez (originhez) csatlakozni, mert nem mindegyik tud.

Ennek a megoldásnak is vannak korlátai: a Cloudflare ingyenes proxyja csak a HTTP és HTTPS forgalmat továbbítja, az SSH, a levelezés, az adatbázis vagy egy játékszerver forgalmát nem. Ezekhez a Cloudflare Tunnel jelenthet megoldást: a szerveren futó cloudflared maga építi fel a kapcsolatot a Cloudflare felé, ezért nyitott port sem kell hozzá. IPv6-only gépen a --edge-ip-version auto (vagy 6) kapcsolóval indítsd, mert alapértelmezésben IPv4-en próbál kapcsolódni.

Ha több IPv6-only szervered van, egy másik lehetőség egy kis, IPv4 címmel is rendelkező VPS, amely fordított proxyként továbbítja a forgalmat a többi géphez, például az Nginx Proxy Managerrel.

Kifelé irányuló forgalom: NAT64 és DNS64

Ha a szervernek csak IPv4-es szolgáltatásokat is el kell érnie, a NAT64 és a DNS64 segít. A DNS64 feloldó a csak IPv4 címmel rendelkező nevekhez is ad IPv6 címet (a 64:ff9b::/96 előtaggal), a NAT64 átjáró pedig ezt a forgalmat IPv4-re fordítja. Ha a szolgáltatód kínál NAT64-et, elég a szerver DNS feloldójaként a DNS64 szervert beállítani.

Léteznek ingyenes, nyilvános NAT64 szolgáltatások is, de ezeket önkéntesek üzemeltetik, rendelkezésre állást nem vállalnak, és a forgalmad egy harmadik félen halad át, ezért éles rendszerhez nem ajánljuk őket. Megbízhatóbb, ha egy saját, IPv4 címmel is rendelkező szerveren keresztül küldöd a forgalmat, például HTTP proxyval vagy SSH SOCKS proxyval.

Mikor jó választás?

Felhasználás	IPv6-only VPS?
Weboldal, webalkalmazás Cloudflare vagy más CDN mögött	Igen
Backend, adatbázis vagy worker, amelyet csak a saját szervereid érnek el	Igen, ha azok is IPv6-osak, vagy egy proxy van előttük
Tesztszerver, tanulás, kísérletezés	Igen
Önálló levelezőszerver	Nem
Levéltároló backend egy IPv4-es frontend (Exim, Dovecot proxy) mögött	Igen
Játékszerver, VPN, VoIP, amelyhez a felhasználók közvetlenül csatlakoznak	Csak ha minden felhasználó IPv6-ot használ
GitHubra épülő telepítés, CI/CD	Csak NAT64-gyel vagy proxyval
Külső API-kat, fizetési rendszereket hívó alkalmazás	Előbb ellenőrizd, hogy azok IPv6-on is elérhetők-e

Röviden: az IPv6-only VPS akkor éri meg, ha a szerver szolgáltatásait egy CDN vagy egy proxy teszi elérhetővé az IPv4-es világ számára, és a szerver kifelé csak IPv6-on is elérhető forrásokat használ. Ha bizonytalan vagy, egy IPv4 címmel is rendelkező szerverrel kevesebb meglepetés ér.

IPv4 és IPv6 az aWh VPS-ein

KVM VPS csomagjainkban minden szerver alapértelmezésben egy IPv4 és egy IPv6 címet is kap, így mindkét protokollon elérhető, és mindkettőn eléri az internetet. Ha nincs szükséged IPv4 címre, a megrendeléskor választhatod, hogy a VPS csak IPv6 címmel működjön, így olcsóbb lesz. Egy Cloudflare mögötti weboldalhoz vagy egy elosztott rendszer belső gépeihez elég az IPv6-only változat, a frontend szerverhez és minden olyan géphez, amelyet közvetlenül IPv4-ről is el kell érni, válaszd az IPv4 címmel is rendelkezőt. Az IPv6 cím beállítását az IPv6 cím beállításáról szóló cikk mutatja be.