استضافة VPS في فرانكفورت: هل تناسبك؟

لمن تناسب استضافة VPS في فرانكفورت

تناسب استضافة VPS في فرانكفورت المشاريع التي يوجد مستخدموها في ألمانيا، أو في السوق الأوسع الناطق بالألمانية، أو الموزعين في أنحاء الاتحاد الأوروبي. تُعدّ فرانكفورت إحدى النقاط التي تلتقي فيها الشبكات الأوروبية وتتبادل حركة الشبكة مباشرة، لذلك يصل الخادم الموجود فيها إلى معظم أنحاء القارة خلال بضع عشرات من المللي ثانية. إذا كان معظم مستخدميك في أمريكا الشمالية، فسيبدو الخادم الأوروبي بطيئاً لهم مهما كانت سرعة الجهاز، لأن المسافة تضع حداً أدنى للزمن لا يمكن لإجراءات الضبط إزالته.

هناك سؤالان منفصلان يحددان الموقع، وخلطهما هو ما يؤدي إلى اختيارات سيئة. السؤال الأول هو مكان وجود مستخدميك، وهو سؤال يتعلق بالمسافة وزمن الرحلة ذهاباً وإياباً. والسؤال الثاني هو المكان المسموح قانونياً وتعاقدياً بتخزين بياناتك فيه. تقدّم فرانكفورت إجابة قوية عن السؤال الأول بالنسبة إلى الجمهور الأوروبي. أما بالنسبة إلى السؤال الثاني، فهي تزيل مشكلة محددة واحدة ولا تحسم أي شيء آخر.

لماذا تتمتع Frankfurt باتصال شبكي جيد إلى هذا الحد؟

تستضيف Frankfurt مركز DE-CIX ‏(Deutsche Commercial Internet Exchange)، وهو IXP ‏(internet exchange point) يُعد من أكبر مراكز تبادل الإنترنت في العالم من حيث ذروة حركة الشبكة وعدد الشبكات المتصلة به. والـIXP هو بنية تبديل مشتركة داخل مركز بيانات، تتصل فيها الشبكات المستقلة ببعضها بدلاً من الدفع لشبكة أكبر كي تنقل حركة الشبكة بينها. ينشر DE-CIX إحصاءات حركة الشبكة الحالية على موقعه، وتتغير هذه الأرقام؛ لذلك اقرأها من هناك بدلاً من الاعتماد على رقم منسوخ في مقال.

الأثر العملي يتعلق بالمسارات، لا بالإجماليات. عندما تتصل شبكة مزودك ومزود خدمة الإنترنت (ISP) للزائر بنقطة التبادل نفسها، تعبر حركة الشبكة بينهما قفزة توجيه واحدة في تلك النقطة. وعندما لا تتبادل الشبكتان الحركة محلياً، يجب أن تصل حركة الشبكة إلى شبكة ثالثة تنقلها لكليهما، وقد تكون أقرب نقطة تسليم لهذه الشبكة في بلد آخر. تدفع شبكتان ألمانيتان تتبادلان حركة الشبكة عبر Amsterdam أو London كلفة المسافة الإضافية مرتين، مرة في كل اتجاه. يطلق مهندسو الشبكات على ذلك اسم tromboning، وهو السبب المعتاد في أن يقيس خادم قريب مسافة بعيدة.

يمكنك رؤية ذلك بدلاً من افتراضه. شغّل mtr على خادمك من الشبكة التي تهمك، واقرأ أسماء القفزات في DNS العكسي. تتضمن أسماء مضيفي الموجّهات عادةً رموز مطارات IATA؛ لذلك يعني fra في اسم قفزة أن الموقع هو Frankfurt، ويعني ams أن الموقع هو Amsterdam، ويعني lhr أن الموقع هو London. يخبرك المسار من اتصال مستهلك ألماني إلى خادم ألماني، إذا ظهر فيه lhr في المنتصف، بالمكان الذي ذهبت إليه تلك الميلي ثواني الإضافية بالضبط.

ما مدى بُعد Frankfurt عن مستخدميك؟

تنتقل الإشارة الضوئية في الألياف بسرعة تقارب ثلثي سرعتها في الفراغ، أي نحو 200,000 كيلومتر في الثانية. تقطع الرحلة ذهاباً وإياباً المسار مرتين، لذلك فإن أسرع رحلة ممكنة ذهاباً وإياباً عبر مسافة قدرها d كيلومتر تساوي d/100 مللي ثانية. هذا حد أدنى، وهو مفيد لأن أي شيء لا يمكنه تجاوزه.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

تُحسب هذه القيم من المسافة بخط مستقيم، ولا تُقاس فعلياً. اقرأ العمود الأخير باعتباره أفضل حالة تسمح بها قوانين الفيزياء. عادةً ما تقع القياسات الفعلية بين 1.5 و2 ضعف هذا الحد الأدنى، لأن الألياف تتبع الطرق ووديان الأنهار بدلاً من المسارات على الدوائر العظمى، ولأن كل موجه على المسار يضيف تأخيراً صغيراً في التوجيه والانتظار في قائمة الانتظار.

تقع Berlin على بُعد 424 كيلومتراً من Frankfurt، بحد أدنى قدره 4.2 مللي ثانية. وتبعد Madrid مسافة 1,419 كيلومتراً، بحد أدنى قدره 14.2 مللي ثانية، وهي أبعد منطقة في الاتحاد الأوروبي عن هذا الموقع. أما New York فتقع على بُعد 6,206 كيلومتراً، بحد أدنى قدره 62.1 مللي ثانية، ولذلك فإن استهداف مستخدمين عبر الأطلسي قرار يتعلق بالموقع، وليس مشكلة يمكن حلها بالضبط والإعدادات.

ما تكلفة زمن الرحلة ذهاباً وإياباً البطيء على تحميل الصفحة؟

نادراً ما تكون رحلة ذهاباً وإياباً واحدة مجرد رحلة واحدة. يستغرق فتح اتصال HTTPS رحلة ذهاباً وإياباً لمصافحة TCP (بروتوكول التحكم في الإرسال)، ورحلة أخرى لمصافحة TLS (أمان طبقة النقل) 1.3. ثم يستغرق الطلب رحلة ثالثة قبل وصول البايت الأول من الاستجابة. ويضيف TLS 1.2 رحلة رابعة. كما يضيف بحث DNS (نظام أسماء النطاقات) غير المخزّن مؤقتاً رحلة إضافية واحدة على الأقل، إلى خادم مختلف أيضاً.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

يفترض عمود الرحلات ذهاباً وإياباً هنا مساراً محتملاً إلى خادم في Frankfurt، بينما يجري العمود الثاني حساباً اعتماداً عليه: ثلاث رحلات ذهاباً وإياباً قبل وصول البايت الأول. ينتظر مستخدم في Frankfurt مدة 15 ms. أما مستخدم في Singapore، مع زمن رحلة ذهاباً وإياباً قدره 170 ms، فينتظر 510 ms للاستجابة نفسها، قبل أن يرسم المتصفح أي شيء.

المضاعِف هو جوهر المسألة. كل millisecond إضافي من RTT (زمن الرحلة ذهاباً وإياباً) يضيف نحو ثلاثة milliseconds قبل وصول البايت الأول، ويستمر تأثيره بعد ذلك. يحدد HTML ورقة أنماط، وتحدد ورقة الأنماط خطاً، وكل عملية اكتشاف من هذه العمليات تضيف رحلة أخرى ذهاباً وإياباً على الاتصال نفسه. إن إضافة بضع مئات من milliseconds بسبب المسافة تحوّل صفحة بدت فورية إلى صفحة تبدو بطيئة، مع أن الخادم ينفّذ العمل نفسه تماماً وفي المدة نفسها تماماً.

يحدد هذا أيضاً حدود ما يمكن لـ CDN (شبكة توصيل المحتوى) إصلاحه. تتجاوز الملفات الثابتة المقدَّمة من cache قريبة من المستخدم المسار الطويل. أما لوحة التحكم التي تتطلب تسجيل الدخول وتسأل قاعدة البيانات عن معلومة، فلا تتجاوز هذا المسار: إذ لا يزال ذلك الطلب يقطع المسافة كاملة مرتين. إن وضع الخادم الأصلي بالقرب من المستخدمين الذين يسجّلون الدخول هو الجزء الذي لا توفّره لك أي cache.

كيف أقيس ذلك من المواقع التي يوجد فيها مستخدموني؟

شغّل هذه الأوامر من جهاز موجود على الشبكة التي تهمك، ويفضّل أن يكون عبر اتصال منزلي أو اتصال مكتب في البلد الذي تخدمه. إذا أجريت القياس من خادم آخر في مركز بيانات مختلف، فستحصل على معلومات عن مسارات مراكز البيانات، لا عن مستخدميك. الأوامر أدناه أمثلة لتشغيلها بنفسك؛ وأرقام زمن الاستجابة الوحيدة التي تستحق اتخاذ إجراء بشأنها هي الأرقام التي قستها بنفسك.

ping -c 20 your-server.example.com

يظهر سطر الملخص rtt min/avg/max/mdev = .... اقرأ avg لمعرفة الحالة المعتادة، وmdev لمعرفة التذبذب، أي الاختلاف بين الحزم. يشير avg الطبيعي مع mdev المرتفع إلى أن المسار غير مستقر، وهذا يضر بالعمل التفاعلي مثل SSH أو الصوت بدرجة أكبر من ارتفاع المتوسط قليلاً.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

يطبع -r تقريراً بدلاً من العرض المباشر، ويحافظ -w على أسماء المضيفين الطويلة كاملة، ويعرض -z رقم AS (النظام المستقل) لكل قفزة، ويرسل -c 50 دورة. ظهور فقدان عند قفزة وسطية واحدة، مع عدم وجود فقدان عند القفزة النهائية، أمر طبيعي وليس عطلاً؛ فكثير من الموجّهات تحدّ معدل ردود ICMP التي تنشئها لنفسها، مع استمرارها في تمرير كل شيء آخر بشكل سليم. أما الفقدان الذي يبدأ عند قفزة ويستمر في كل القفزات اللاحقة فهو فقدان حقيقي.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

كل حقل هو عدد تراكمي بالثواني منذ بدء الطلب، لذلك تقرأه بالطرح. يمثّل time_namelookup DNS. ويمثّل time_connect ناقص ذلك مصافحة TCP، وهي قريبة من دورة ذهاب وإياب واحدة. ويمثّل time_appconnect ناقص time_connect مصافحة TLS. ويمثّل time_starttransfer ناقص time_appconnect وقت معالجة تطبيقك نفسه مضافاً إليه دورة ذهاب وإياب أخرى. إذا كانت الفواصل الزمنية صغيرة وكان total لا يزال مرتفعاً، فالمشكلة في شيفرتك، لا في المدينة.

لقياس معدل النقل بدلاً من زمن الاستجابة، شغّل iperf3 -s على VPS، وافتح منفذه في الجدار الناري، ثم شغّل iperf3 -c your-server.example.com -R من العميل لاختبار اتجاه التنزيل. وللقياس من أماكن لا تملك فيها جهازاً، تتيح لك RIPE Atlas استخدام مجسّات موزعة في أنحاء أوروبا. عند مقارنة خادمين بدلاً من شبكتين، استخدم منهجية ثابتة بدلاً من أرقام لمرة واحدة؛ وهذا ما يوفّره اختبار VPS قابل للتكرار.

هل يجعل وجود خادم في فرانكفورت مشروعي ممتثلاً للائحة GDPR؟

لا. والسبب يستحق توضيحاً دقيقاً. تنطبق اللائحة العامة لحماية البيانات GDPR (General Data Protection Regulation) بناءً على أصحاب البيانات الشخصية التي تعالجها، ومكان تأسيس مؤسستك، وليس على البلد الذي توجد فيه الأجهزة. نقل الخادم إلى فرانكفورت لا يحقق الامتثال، كما أن تشغيله خارج الاتحاد الأوروبي لا يعني تلقائياً خرق اللائحة. الموقع عامل واحد من عدة عوامل.

ما يزيله الاستضافة داخل الاتحاد الأوروبي أو المنطقة الاقتصادية الأوروبية الأوسع EEA (European Economic Area) هو مسألة النقل الدولي للبيانات. تتضمن اللائحة فصلاً كاملاً عن إرسال البيانات الشخصية خارج المنطقة الاقتصادية الأوروبية، ويتطلب ذلك أداة قانونية مثل قرار ملاءمة أو بنود تعاقدية قياسية. لا تُنقل البيانات التي تبقى في فرانكفورت، ولذلك لا ينطبق ذلك الفصل على هذه العملية. هذا تبسيط حقيقي، وهو الحجم الفعلي للفائدة.

أما كل ما عدا ذلك فيبقى من مسؤوليتك. ما زلت تحتاج إلى أساس قانوني لكل غرض، وحقوق وصول وحذف قابلة للتنفيذ للأشخاص الموجودين في قاعدة بياناتك، وحد احتفاظ تفرضه فعلياً، وتدابير أمنية مناسبة لمستوى المخاطر، وإبلاغ السلطة الإشرافية خلال 72 ساعة من علمك بحدوث خرق للبيانات الشخصية. تحتاج أيضاً إلى اتفاقية معالجة مع مزود الاستضافة، وتُعرف في ألمانيا باسم Auftragsverarbeitungsvertrag أو AVV. لاحظ أيضاً أن الخادم الموجود في فرانكفورت قد يظل ينطوي على نقل للبيانات إذا كان موظفو الدعم خارج المنطقة الاقتصادية الأوروبية يستطيعون الوصول إليه، لذلك تحقق ممن يملك المفاتيح.

تضيف ألمانيا طبقة خاصة بها: إذ يكمل القانون الاتحادي BDSG (Bundesdatenschutzgesetz) اللائحة بقواعد وطنية، وتُعد بيانات الموظفين المجال الذي يفاجئ الناس أكثر من غيره. يقدم هذا القسم خلفية عامة، وليس استشارة قانونية. ينشر European Data Protection Board الإرشادات الرسمية على edpb.europa.eu، وأي مسألة تترتب عليها عواقب فعلية تستحق الاستعانة بمستشار مؤهل بدلاً من الاعتماد على برنامج تعليمي.

ما الذي ينبغي تغييره على الخادم نفسه؟

اضبط ساعة النظام على UTC (التوقيت العالمي المنسق)، ونسّق الطوابع الزمنية داخل تطبيقك. تطبّق ألمانيا التوقيت الصيفي، لذلك يتغير الوقت المحلي بمقدار ساعة مرتين سنوياً، وتتكرر ساعة واحدة في أواخر أكتوبر. تحتوي السجلات المكتوبة بالتوقيت المحلي على إدخالين عند 02:30 في تلك الليلة، ويصبح ربط الأحداث بينها عبر المناطق عملية تخمين. إذا كنت تريد استخدام التوقيت المحلي على الخادم، فاضبطه صراحةً وتحقق منه:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

يجب أن يعرض الناتج Time zone: Europe/Berlin (CEST, +0200) في الصيف و+0100 في الشتاء.

يُرتّب النص الألماني ترتيباً خاطئاً ضمن الإعدادات المحلية الافتراضية C، لأن فرز C يقارن البايتات الخام. أنشئ الإعدادات المحلية وراقب الفرق:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

يضع الفرز الأول Äpfel بعد Zebra، لأن أول بايت له في UTF-8 أعلى من أي حرف ASCII. أما الفرز الثاني فيضعه بجانب Apfel، كما يتوقع القارئ الألماني. هذا الأمر أهم مما يبدو، لأن PostgreSQL وMySQL يثبتان قواعد الترتيب عند إنشاء قاعدة البيانات، وتغييرها لاحقاً يتطلب إعادة إنشاء الفهارس. اتخذ القرار قبل تحميل البيانات.

يقلل مرآة حزم ألمانية مدة تشغيل apt. في Ubuntu 24.04 توجد المصادر في /etc/apt/sources.list.d/ubuntu.sources بتنسيق deb822، لذلك غيّر السطر URIs: إلى http://de.archive.ubuntu.com/ubuntu/ بدلاً من إضافة ملف ثانٍ. تؤدي الإضافة إلى Target Packages ... is configured multiple times، وهو خطأ تكرار مصادر deb822، ويوقف التحديثات إلى أن تحل المشكلة.

انشر سجلاً من نوع AAAA. يزوّد بعض مزوّدي خدمة الإنترنت الألمان اتصالات المستهلكين بإعداد DS-Lite (وضعية IPv4/IPv6 المزدوجة)، حيث لا يملك العميل عنوان IPv4 عاماً على الإطلاق، وتعبر حركة IPv4 الخاصة به بوابة ترجمة تابعة لشركة الاتصالات. تضيف هذه البوابة زمن تأخير وتزدحم خلال ساعات الذروة، بينما تخرج حركة IPv6 مباشرة. افحص المسارين بعد ضبط السجل:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

تعني نتيجة 200 من الأمر الثاني أن IPv6 يعمل من الطرف إلى الطرف. تعني Could not resolve host أو حدوث خطأ في الاتصال أن السجل أو المستمع مفقود، وأن زوارك الذين يستخدمون DS-Lite يسلكون المسار البطيء.

عندما يكون فرانكفورت اختياراً غير مناسب

• مستخدموك في الولايات المتحدة. شغّل الخدمة من هناك: خادم VPS في دالاس يقع بالقرب من وسط البلاد، بينما استضافة VPS في نيويورك توفّر مساراً أقصر إلى الساحل الشرقي وإلى حركة المرور التي تعبر المحيط الأطلسي على أي حال.
• مستخدموك في أمريكا اللاتينية. تقع فرانكفورت على مسافة أبعد من ساو باولو مقارنةً بنيويورك، لذا فإن خادم VPS في البرازيل هو الخيار المناسب فعلياً لهذا الجمهور.
• يجب أن تبقى بياناتك داخل بلد محدد خارج الاتحاد الأوروبي. تُعد أعمال القطاع العام الكندي الحالة الشائعة، ويوضح ما يهم فعلياً في استضافة VPS في كندا متطلبات إقامة البيانات هناك.
• تشغّل خادم ألعاب. يشعر اللاعبون بكل ميلي ثانية من زمن الرحلة ذهاباً وإياباً، لذلك تتفوق القرب منهم على أي مواصفة أخرى: يوضّح اختيار VPS لخوادم الألعاب كيفية التعامل مع ذلك.

بالنسبة إلى جمهور أوروبي موزع بين عدة بلدان، يُعد فرانكفورت الخيار الفردي الآمن، ويظل مناسباً مع نموك، لأن الشبكات التي تحتاج إلى الوصول إليها متصلة بالفعل بنقطة تبادل الإنترنت. قِس زمن الوصول من مواقع مستخدميك قبل الانتقال وبعده، واحتفظ بمجموعتي القياسات.

FAQ

هل يكفي VPS واحد في Frankfurt لخدمة أوروبا بأكملها؟

نعم، بالنسبة إلى معظم المشاريع. تضع المسافة المستقيمة الحد الأدنى عند 12.0 ms إلى Stockholm وعند 14.2 ms إلى Madrid، وتكون المسارات الفعلية عادةً بين 1.5 و2 ضعف هذا الحد الأدنى. لذلك تبقى أوروبا تقريباً بأكملها ضمن عشرات قليلة من المللي ثانية من خادم واحد في Frankfurt. أضف موقعاً ثانياً عندما تقيس شكوى فعلية من بلد محدد، أو عندما تحتاج إلى تجاوز الأعطال بدلاً من تحسين السرعة.

هل يجعل استضافة مشروعي في Frankfurt المشروع متوافقاً مع GDPR؟

لا. يُطبَّق GDPR بناءً على أصحاب البيانات الشخصية التي تعالجها ومكان تأسيسك، لا على موقع الخادم. تزيل الاستضافة داخل الاتحاد الأوروبي مسألة نقل البيانات الدولي في هذه المرحلة، وهذا تبسيط فعلي ويمثل كامل الفائدة هنا. ما زلت تحتاج إلى أساس قانوني للمعالجة، وآلية فعالة لممارسة حقوق أصحاب البيانات، وحد للاحتفاظ بالبيانات، وتدابير أمنية، والإبلاغ عن الاختراق خلال 72 ساعة، واتفاقية معالج مع مزود الخدمة، وتُسمى AVV في ألمانيا. هذه معلومات عامة وليست استشارة قانونية.

ما مقدار زمن الانتقال المتوقع بين Frankfurt وBerlin؟

تبعد المدينتان مسافة 424 km، ما يضع حداً أدنى ثابتاً لزمن الذهاب والإياب قدره 4.2 ms. يقيس المسار الذي يملك اتصالاً جيداً عادةً ما بين 1.5 و2 ضعف هذا الحد الأدنى. تحقّق من ذلك باستخدام ping -c 20 your-server.example.com من اتصال في Berlin، واقرأ قيمة avg في السطر rtt min/avg/max/mdev. تعني النتيجة التي تتجاوز هذا النطاق بكثير عادةً أن حركة الشبكة غادرت ألمانيا ثم عادت إليها، وسيُظهر لك mtr -rwzc 50 ذلك في أسماء القفزات.

هل ينبغي ضبط المنطقة الزمنية لخادم Frankfurt على Europe/Berlin؟

عادةً لا. أبقِ النظام على UTC حتى تظل السجلات قابلة للمقارنة ولا يكون أي طابع زمني ملتبساً. تنتقل ألمانيا إلى CEST في الربيع وتعود إلى CET في الخريف. وفي ليلة الانتقال إلى التوقيت الشتوي تتكرر ساعة محلية واحدة، لذلك قد تحمل حادثتان مختلفتان الطابع الزمني المحلي نفسه. نسّق الأوقات وفق المنطقة المحلية داخل تطبيقك، حيث يتوفر السياق اللازم لتنفيذ ذلك بصورة صحيحة. إذا أردت ضبط الخادم بالكامل على التوقيت المحلي، فشغّل sudo timedatectl set-timezone Europe/Berlin وتحقق باستخدام timedatectl.

هل يسبب الخادم الذي يدعم IPv4 فقط مشكلة للزوار من ألمانيا؟

سيعمل، لكنه سيكون أبطأ لبعضهم. يزوّد عدد من مزودي خدمة الإنترنت الألمان اتصالات المستهلكين بإعداد DS-Lite من دون عنوان IPv4 عام، لذلك يصل هؤلاء العملاء إلى الخادم الذي يدعم IPv4 فقط عبر بوابة ترجمة تابعة للمزود، ما يضيف زمن انتقال ويسبب ازدحاماً في أوقات الذروة. يتيح نشر سجل AAAA والاستماع على IPv6 مساراً مباشراً لهم. اختبر ذلك باستخدام dig AAAA your-server.example.com +short وطلب curl -6، وتوقع الحصول على HTTP 200 من كلتا عائلتي العناوين.