IPv6 برای وب‌سایت‌ها: چه چیزی عوض می‌شود، چه چیزی نه و CDN چه چیزی را بر عهده می‌گیرد

چرا IPv6 دوباره در دستور کار است

IPv4 حدود چهار میلیارد آدرس دارد و آخرین بلوک‌های آزاد در دهه ۲۰۱۰ توزیع شدند. اینترنت متوقف نشد: اپراتورها مشتریان زیادی را پشت یک آدرس مشترک گذاشتند (NAT در سطح اپراتور) و بین دو دنیا ترجمه می‌کنند. کار می‌کند، اما به هر اتصال یک جعبه میانی اضافه می‌کند، وقتی هزار گوشی یک آدرس را به اشتراک می‌گذارند قواعد به‌ازای IP را بی‌معنا می‌کند و برای اپراتورها هزینه دارد — به همین دلیل بیشتر شبکه‌های موبایل حالا IPv6 را بومی اجرا می‌کنند و IPv4 را مسیر قدیمی می‌دانند. طرف خرید را هم اضافه کنید: مناقصه‌های عمومی و پرسشنامه‌های امنیتی سازمانی می‌پرسند آیا سرویس از طریق IPv6 در دسترس است، و یک «نه» ساده یک امتیاز از دست‌رفته است.

برای یک وب‌سایت واقعاً چه چیزی عوض می‌شود

تقریباً هیچ چیز در HTML یا برنامه شما. سایت دوپشته دو نوع رکورد DNS دارد — A برای IPv4 و AAAA برای IPv6 — و یک در ورودی که روی هر دو خانواده آدرس گوش می‌دهد. مرورگر مدرن هر دو را حل می‌کند، تقریباً موازی امتحانشان می‌کند و هر کدام را که زودتر وصل شود نگه می‌دارد (قاعده Happy Eyeballs)، پس مسیر IPv6 خراب بازدیدکننده را معطل نمی‌گذارد. وقتی اتصال باز شد، HTTP همان HTTP است: همان کوکی‌ها، همان سرآیندهای کش، همان گواهی TLS. تفاوت قابل‌مشاهده در لاگ‌های شماست، جایی که آدرس‌هایی مثل 2a01:4f9:... کنار آدرس‌های نقطه‌دار آشنا ظاهر می‌شوند.

CDN از قبل چه کاری برای شما انجام داده

لبه CDN.com.tr از سپتامبر ۲۰۲۶ دوپشته است: هر نام میزبان CDN در کنار رکوردهای A رکورد AAAA دارد و لبه اتصال روی هر دو را می‌پذیرد. اگر سایت شما با CNAME به ما اشاره می‌کند — تنظیم معمول برای www و زیردامنه‌ها — همان روز بدون هیچ تغییری در سمت شما IPv6 را به ارث برده است. سرور مبدأ شما دخالتی ندارد: لبه اتصال بازدیدکننده را با هر خانواده‌ای که رسیده خاتمه می‌دهد و از مبدأ شما دقیقاً مثل قبل با IPv4 می‌گیرد. بازدیدکننده یک سایت IPv6 می‌بیند؛ سرور شما هرگز به آدرس IPv6 نیاز ندارد.

CNAME هر دو خانواده را از نام میزبان CDN به ارث می‌برد

$ dig +short www.example.com AAAA
www.example.com.cdn.com.tr.
2a03:35e0:9700::9

$ dig +short www.example.com A
www.example.com.cdn.com.tr.
185.70.97.9

چطور سایت خودتان را بررسی کنید

دو فرمان برای هر نام میزبانی پاسخ می‌دهند: dig برای رکوردها، curl برای یک اتصال واقعی. در مرورگر، DevTools → Network → راست‌کلیک روی ستون‌ها → Remote Address نشان می‌دهد کدام خانواده استفاده شده. اگر curl -6 شکست بخورد ولی curl -4 کار کند، سایت از جایی که هستید از طریق IPv6 در دسترس نیست — ممکن است مشکل از سایت باشد یا از شبکه خودتان، پس قبل از باز کردن تیکت از یک گوشی با داده موبایل امتحان کنید.

اول رکوردها، بعد یک اتصال واقعی IPv6

$ dig +short AAAA www.example.com
2a03:35e0:9700::9

$ curl -6 -sI https://www.example.com/ | head -1
HTTP/2 200

$ curl -4 -sI https://www.example.com/ | head -1
HTTP/2 200

چیزهایی که واقعاً خراب می‌شوند

IPv6 صفحات را خراب نمی‌کند؛ فرض‌ها درباره آدرس‌ها را خراب می‌کند. اول، فهرست‌های مجاز و مسدود: قاعده‌ای که آدرس‌های IPv4 را نام می‌برد هرگز با بازدیدکننده IPv6 مطابقت ندارد، پس فهرست مجاز دفتر برای مسیر مدیریت، همکارانی را که روی موبایل فقط-IPv6 هستند راه نمی‌دهد تا وقتی محدوده IPv6 آن‌ها را اضافه کنید. دوم، محدودیت نرخ و شمارنده‌های به‌ازای IP: یک بازدیدکننده IPv6 ممکن است به‌طور مشروع آدرس‌هایش را داخل یک /64 بچرخاند، پس به‌ازای /64 بشمارید نه به‌ازای آدرس، وگرنه محدودیت‌هایتان هم نشت می‌کنند و هم ناعادلانه می‌شوند. سوم، تحلیل و مکان‌یابی جغرافیایی: پایگاه‌داده‌ها و داشبوردهایی که برای آدرس‌های نقطه‌دار ساخته شده‌اند نسخه‌های آگاه از IPv6 می‌خواهند و یک فیلد IPv4 با ۱۵ کاراکتر آدرس IPv6 با ۳۹ کاراکتر را می‌بُرد. چهارم، بخش‌هایی از پشته شما که پشت CDN نیستند — یک API روی میزبان دیگر، یک سرور ایمیل، یک گیرنده webhook — هنوز فقط IPv4 هستند و کلاینت فقط-IPv6 اصلاً به آن‌ها نمی‌رسد.

IPv6 و HTTP/3 با هم می‌آیند

همان تغییر لبه که IPv6 را آورد HTTP/3 را هم روشن کرد و این دو یک دلیل مشترک دارند: هر دو یک جعبه میانی یا یک رفت‌وبرگشت را از مسیر بازدیدکننده حذف می‌کنند و هر دو را لبه اعلام می‌کند و مرورگر بدون تنظیمی در سمت شما می‌پذیرد. اگر هدفتان سرعت است نه دسترس‌پذیری، HTTP/3 اهرمی است که در Core Web Vitals دیده می‌شود؛ راهنمای HTTP/2 در برابر HTTP/3 توضیح می‌دهد چه چیزی را عوض می‌کند و چطور در DevTools ببینیدش.