سرورهای فقط IPv6 به یک دلیل ساده ارزاناند: آدرسهای IPv4 کمیاباند و هر ماه هزینه دارند، آدرسهای IPv6 نه. پس سؤال این نیست که آیا فقط IPv6 ارزانتر است (هست)، بلکه این است که آیا چیزهایی که واقعاً استفاده میکنید هنوز کار میکنند. به جای تکرار پاسخهای یکساله انجمنها، در سپتامبر ۲۰۲۶ بررسی کردیم.
چه چیزی را آزمایش کردیم و نتیجه
رکوردهای IPv6 (AAAA) سرویسهایی را که یک سرور معمولی در روز اول با آنها سروکار دارد جستوجو کردیم. نبود رکورد AAAA یعنی یک دستگاه فقط IPv6 بدون کمک نمیتواند به آن برسد.
| سرویس | IPv6 تا ۲۶ سپتامبر ۲۰۲۶ |
|---|---|
| github.com، api.github.com | ❌ نه |
| objects.githubusercontent.com (دانلود انتشارها) | ❌ نه |
| ghcr.io (رجیستری کانتینر GitHub) | ❌ نه |
| raw.githubusercontent.com | ✅ بله |
| Docker Hub (registry-1.docker.io) | ✅ بله |
| PyPI، npm، crates.io، پراکسی ماژول Go | ✅ بله |
| آینههای بسته Debian / Ubuntu / Alpine | ✅ بله |
| GitLab | ✅ بله |
| Let's Encrypt (ACME) | ✅ بله |
| Telegram Bot API | ✅ بله |
| discord.com و gateway دیسکورد | ❌ نه |
| APIهای OpenAI، Anthropic، Google Gemini | ✅ بله |
| Hugging Face (سایت) | ✅ بله، اما میزبان CDN فایلهای بزرگ: ❌ نه |
| ollama.com | ❌ نه (registry.ollama.ai: ✅ بله) |
| Binance API | ❌ نه |
| Coinbase API | ✅ بله |
الگو روشن است: مدیرهای بسته، APIهای بزرگ هوش مصنوعی و Telegram آمادهاند. GitHub، سرویسی که تقریباً هر سروری لازمش دارد، هنوز نه.
در عمل یعنی چه
روی VPS فقط IPv6 دقیقاً در این جاها به دیوار میخورید:
git clone https://github.com/...شکست میخورد. همینطور اسکریپتهای نصبی که یک انتشار GitHub را با curl میگیرند، و هر چیزی که ایمیج ازghcr.ioمیکشد.- باتهای Discord اصلاً نمیتوانند به gateway وصل شوند.
- برخی دانلودهای مدل خراب میشوند: میزبان فایلهای بزرگ Hugging Face و ollama.com در بررسی ما IPv6 نداشتند.
- باتهای رمزارز روی صرافیهای فقط IPv4 نمیتوانند به API برسند.
و یک مشکل بیصداتر در سمت ورودی: بازدیدکنندگان روی شبکههای فقط IPv4 نمیتوانند به سایتی روی سرور فقط IPv6 برسند، مگر اینکه یک پراکسی یا CDN با IPv4 جلوی آن بگذارید.
هر سرویسی را در دو ثانیه آزمایش کنید
dig +short AAAA github.com # empty output = no IPv6
dig +short AAAA api.telegram.org # addresses = IPv6 available
curl -6 -sI https://pypi.org | head -1 # on a dual-stack box: proves it answers over v6
این را پیش از انتخاب پلن برای همه چیزهایی که پروژهتان با آنها حرف میزند اجرا کنید.
راهحلهای جایگزین و هزینهشان
- NAT64/DNS64. یک دروازه درخواستهای IPv6 را به مقصدهای IPv4 ترجمه میکند. دروازههای عمومی وجود دارند، اما ترافیک خود را از دستگاه کس دیگری عبور میدهید و به uptime او وابسته میشوید.
- آینهها و پراکسیها. مخزنهای GitHub را در GitLab آینه کنید، ایمیجها را به Docker Hub بفرستید، یک پراکسی کوچک روی دستگاه dual-stack اجرا کنید. شدنی است، اما لولهکشیای است که باید زنده نگهش دارید.
- یک CDN در جلو برای ترافیک وب ورودی، تا بازدیدکنندگان IPv4 به شما برسند.
هر راهحل به تنهایی قابل قبول است. با هم، همان چند دلاری را که پلن فقط IPv6 صرفهجویی کرده بود میخورند.
کی واقعاً به IPv4 نیاز دارید، و چه نوعی
برای بیشتر پروژهها پاسخ صادقانه این است: اتصال IPv4 میخواهید، اما لزوماً آدرس IPv4 خودتان را نه.
- اگر هیچ چیز نیاز ندارد از بیرون به سرور شما وصل شود (باتها، agentها، workerها، کارهای cron)، یک پلن NAT کافی است. از طریق NAT به هر سرویسی، از جمله سرویسهای فقط IPv4، میرسد و شما از طریق یک پورت SSH شخصی وارد میشوید. این گزینه اقتصادی است: پلنهای NAT از ۳ دلار در ماه.
- اگر چیزی باید از بیرون وصل شود (وبسایت، سرور ایمیل، سرور بازی، نقطه پایانی VPN)، یک پلن با IPv4 اختصاصی بگیرید.
دقیقاً به دلایل جدول بالا پلن فقط IPv6 نمیفروشیم: با NAT سهدلاری و دسترسی کامل به IPv4، صرفهجویی ارزش سروری را ندارد که نمیتواند از GitHub کلون کند. هنوز مطمئن نیستید کدام را لازم دارید؟ این هم آزمون یکسؤالی.
نظرات
هنوز نظری نیست. اولین نفر باشید.