معظمُ خطط الخوادم الافتراضية تشمل IPv6، ومعظمها يُترَك نصفَ مضبوط: فالعنوان مُسنَد، وسجلُّ AAAA موجود، لكن الجدار الناري أو خادم الويب لا يُنصِت عليه قطّ. فيجرّب زائرٌ عنده IPv6 الطريقَ السريع، وينتظر حتى تنقضي المهلة، ثم يتراجع إلى IPv4. فيبدو الموقعُ بطيئًا لأسبابٍ لن يُظهرها أيُّ اختبارٍ على IPv4.

هل يعمل فعلًا

ip -6 addr show
ping6 -c2 ipv6.google.com
curl -6 -sS -o /dev/null -w '%{http_code}\
' https://yourdomain.com

السطرُ الأخير هو الذي يهمّ. فإن تعلّق أو فشل بينما تُجيب نسخةُ IPv4، فسجلُّ AAAA عندك يشير إلى بابٍ لا أحد خلفه.

المواضعُ الثلاثة التي تُفحَص

  • خادمُ الويب — يحتاج Nginx سطرَ إنصاتٍ خاصًّا به: listen [::]:443 ssl;
  • والجدارُ الناري — يتعامل ufw وfirewalld مع الإصدار السادس على حدة؛ وقواعدُ iptables لا تسري على ip6tables البتّة.
  • ونظامُ الأسماء — فسجلُّ AAAA لا ينفع إلّا إن صحّ ما قبله.
# nginx
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

وتطبيقك سيرى عنوانًا مختلفًا

عميلُ IPv6 يصل بعنوانٍ مثل 2001:db8::1. فالشفرةُ التي تخزّن عنوانًا في عمودٍ بخمسة عشر حرفًا، أو تقارنه بقائمة سماحٍ من الإصدار الرابع، تنكسر بصمت. وحدُّ المعدّل المبنيّ على العنوان الكامل ضيّقٌ أيضًا، إذ يملك العميلُ الواحد عادةً نطاق ‎/64 كاملًا.

وخلف كلاودفلير أو أي وسيط، يكون العنوانُ الذي يراه خادمك هو الوسيط. فاقرأ الحقيقي من الترويسة المُمرَّرة — انظر كلاودفلير وعنوان الزائر الحقيقي.

وإن كنت لن تُتِمّ العمل

فاحذف سجلَّ AAAA. فانعدامُ IPv6 اتّصالُ IPv4 نظيفٌ سريع. وأمّا IPv6 المكسور فمهلةٌ منقضية في كل زيارةٍ أولى.