IPv6 للمواقع: ما الذي يتغير، وما الذي لا يتغير، وما الذي تتولاه CDN

لماذا عاد IPv6 إلى جدول الأعمال

يملك IPv4 نحو أربعة مليارات عنوان ووُزعت آخر الكتل الحرة في العقد 2010. لم يتوقف الإنترنت: وضع المشغلون عملاء كثيرين خلف عنوان مشترك واحد (NAT على مستوى المشغل) ويترجمون بين العالمين. يعمل ذلك، لكنه يضيف صندوقًا وسيطًا إلى كل اتصال، ويجعل القواعد لكل IP بلا معنى حين يتشارك ألف هاتف عنوانًا واحدًا، ويكلف المشغلين مالًا — لذلك تشغّل معظم شبكات الجوال الآن IPv6 أصلًا وتعامل IPv4 كمسار قديم. أضف جانب المشتريات: تسأل المناقصات العامة واستبيانات الأمن المؤسسية عمّا إذا كانت الخدمة قابلة للوصول عبر IPv6، و«لا» بسيطة نقطة ضائعة.

ما الذي يتغير فعلًا للموقع

لا شيء تقريبًا في HTML أو تطبيقك. للموقع ذي المكدّس المزدوج نوعان من سجلات DNS — A لـ IPv4 وAAAA لـ IPv6 — وباب أمامي يستمع على عائلتي العناوين. يحل المتصفح الحديث الاثنين، ويجربهما بالتوازي تقريبًا، ويحتفظ بمن يتصل أولًا (قاعدة Happy Eyeballs)، فلا يترك مسار IPv6 المعطّل الزائر عالقًا. وبعد فتح الاتصال يبقى HTTP هو HTTP: ملفات تعريف الارتباط نفسها، وترويسات التخزين المؤقت نفسها، وشهادة TLS نفسها. الفرق الظاهر في سجلاتك، حيث تبدأ عناوين مثل 2a01:4f9:... بالظهور إلى جانب العناوين المنقّطة المألوفة.

ما الذي تفعله CDN لك بالفعل

تعمل حافة CDN.com.tr بمكدّس مزدوج منذ سبتمبر 2026: يحمل كل اسم مضيف في CDN سجلات AAAA بجانب سجلات A وتقبل الحافة الاتصالات على كليهما. إذا كان موقعك يشير إلينا عبر 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 من 15 حرفًا عنوان IPv6 من 39 حرفًا. رابعًا، أجزاء بنيتك التي ليست خلف CDN — واجهة API على مضيف آخر، خادم بريد، مستقبِل webhook — ما زالت IPv4 فقط، ولا يستطيع عميل IPv6 فقط الوصول إليها إطلاقًا.

IPv6 وHTTP/3 يأتيان معًا

تغيير الحافة نفسه الذي جلب IPv6 فعّل HTTP/3 أيضًا، ويشترك الاثنان في السبب: كلاهما يزيل صندوقًا وسيطًا أو جولة ذهاب وإياب من مسار الزائر، وكلاهما تعلنه الحافة ويتبناه المتصفح دون إعداد من جانبك. إذا كان هدفك السرعة لا قابلية الوصول، فإن HTTP/3 هو الرافعة التي تظهر في Core Web Vitals؛ ويشرح دليل HTTP/2 مقابل HTTP/3 ما الذي يغيّره وكيف تراه في DevTools.