إذا حذّرك أحد إضافات الأمان في ووردبريس بشأن "إعدادات اكتشاف عنوان IP،" أو إذا بدأ تطبيق PHP فجأةً يُسجّل الحفنة نفسها من العناوين لكل زائر، فالسبب يكاد يكون واحداً دائماً: وجود وكيل عكسي (reverse proxy) مثل Cloudflare بين زوّارك وخادمك. الخلاصة باختصار — أبقِ REMOTE_ADDR هو القيمة الافتراضية، ولا تثق أبداً بـ HTTP_CLIENT_IP دون تحقّق، ولا تقرأ CF-Connecting-IP إلا بعد أن تتأكد أن الطلب مرّ فعلاً عبر Cloudflare. وفيما يلي السبب وراء كل نقطة من هذه النقاط.
ماذا تعني كل قيمة فعلياً
في PHP تصلك هذه القيم كمدخلات ضمن $_SERVER. وهي ليست متكافئة — فهي تأتي من أماكن مختلفة تماماً، وهذا الفرق هو جوهر الحكاية كلها:
REMOTE_ADDR— عنوان IP الخاص بمن فتح اتصال TCP بخادمك. يملأ خادم الويب هذه القيمة من المقبس (socket) نفسه، لذا لا يستطيع العميل تزويرها. هذه هي القيمة الوحيدة الجديرة بالثقة.HTTP_CLIENT_IPوHTTP_X_FORWARDED_FOR— مجرّد ترويسات HTTP عادية. أي مدخل من نوعHTTP_*في$_SERVERليس سوى ترويسة أرسلها العميل، ما يعني أن بإمكان أي شخص ضبطها على أي قيمة بسطر واحد منcurl.HTTP_CF_CONNECTING_IP— وهي ترويسةCF-Connecting-IPالتي يضيفها Cloudflare، وتحتوي على عنوان IP الحقيقي للزائر. وهي جديرة بالثقة فقط حين تستطيع ضمان أن الطلب مرّ عبر Cloudflare.
لماذا يكون REMOTE_ADDR "خاطئاً" خلف Cloudflare
حين يعمل Cloudflare كوكيل لنطاقك، يتصل زوّارك بحافة Cloudflare، ثم يفتح Cloudflare اتصالاً جديداً بخادم الأصل (origin) الخاص بك. ومن وجهة نظر خادمك، فإن الزائر هو Cloudflare — لذا يكون REMOTE_ADDR عنوان حافة تابع لـ Cloudflare، وهو ذاته لآلاف الأشخاص المختلفين. لا شيء معطّل هنا؛ فالوكيل ببساطة يؤدي عمله.
ولكي يسلّمك الزائر الأصلي، يُرفق Cloudflare ترويسة CF-Connecting-IP مع كل طلب. وبذلك يكون المصدر الصحيح خلف Cloudflare هو $_SERVER['HTTP_CF_CONNECTING_IP']، مع الرجوع إلى REMOTE_ADDR عند غياب تلك الترويسة.
الفخ الأمني: لماذا لا يمكنك أن تثق بالترويسة وحسب
من المغري أن تكتب "اقرأ HTTP_CLIENT_IP أو X-Forwarded-For، وإلا فاقرأ REMOTE_ADDR" ثم تمضي في حال سبيلك. لكن هذا بالضبط هو النمط الذي يؤدي إلى اختراق المواقع. فلأن هذه ترويسات يوفّرها العميل، يستطيع المهاجم أن يرسل:
curl https://your-site.example/wp-login.php \
-H "X-Forwarded-For: 8.8.8.8" \
-H "Client-IP: 1.1.1.1"إذا كان خنق محاولات تسجيل الدخول، أو الجدار الناري، أو سجل التدقيق لديك يقرأ تلك الترويسات، فبإمكان المهاجم تدوير عنوان IP مزيّف في كل طلب — متجاوزاً حدود المعدّل، ومتهرّباً من حظر العناوين، ومُلوِّثاً سجلّاتك. ولهذا السبب تُحذّرك إضافة الأمان الجيدة قبل تغيير طريقة الاكتشاف: فالإعداد "الأكثر راحةً" هو غالباً الإعداد غير الآمن.
إن CF-Connecting-IP آمن من هذا فقط بفضل شرط إضافي واحد: يجب أن يقبل خادم الأصل لديك حركة المرور حصراً من Cloudflare. فإذا كان خادمك متاحاً أيضاً بشكل مباشر عبر عنوانه العام، فبإمكان المهاجم تخطّي Cloudflare وتزوير CF-Connecting-IP بنفسه. أحكِم إغلاق خادم الأصل عبر Authenticated Origin Pulls أو عبر جدار ناري يسمح فقط بنطاقات عناوين Cloudflare، وعندها تصبح الترويسة جديرة بالثقة.
الإعداد الصحيح، بعبارات بسيطة
- خادم عادي بلا وكيل: استخدم
REMOTE_ADDR. انتهى الأمر. - خلف Cloudflare: استخدم
CF-Connecting-IP(HTTP_CF_CONNECTING_IP)، واقصُر خادم الأصل لديك على Cloudflare حتى لا يمكن انتحال الترويسة. - خلف وكيل/شبكة توصيل محتوى أخرى أو موازِن أحمال: استخدم الترويسة التي يوثّقها ذلك الوكيل (وغالباً ما تكون
X-Forwarded-For، مع أخذ القفزة الموثوقة الأقصى إلى اليمين)، وتأكّد مرة أخرى أن خادم الأصل لا يقبل حركة المرور إلا من ذلك الوكيل.
في إضافات أمان ووردبريس مثل All-In-One Security، هذا تحديداً هو الخيار الذي يتحكّم به إعداد "اكتشاف عنوان IP". أبقِه على REMOTE_ADDR ما لم تكن خلف Cloudflare، وفي تلك الحالة بدّله إلى CF-Connecting-IP.
كيف تتحقق من أنك ضبطته بشكل صحيح
أسرع فحص منطقي هو مقارنة ما يكتشفه خادمك بعنوان IP العام الحقيقي الخاص بك. افتح whatsmy.fyi من الجهاز نفسه: فهو يعرض عنوان IP العام الدقيق الذي يراك به العالم الخارجي. فإذا تطابق العنوان الذي تُسجّله إضافتك أو تطبيقك لزيارتك أنت مع ذلك العنوان، فالاكتشاف يعمل بشكل سليم. (يعمل whatsmy.fyi نفسه على Cloudflare، لذا يقرأ عنوانك من CF-Connecting-IPبالطريقة نفسها التي يفعلها خادم أصل مُهيّأ بشكل صحيح — وهو لا يخزّن شيئاً.)
وإن كنت تُنقّح الأخطاء برمجياً، فإن نقطة النهاية التي لا تتطلب مفتاحاً تُعيد القيمة نفسها للسكربتات:
curl https://whatsmy.fyi/ip
# → your real public IP, as seen at the edgeتطابق العنوانين يعني أن اكتشافك صحيح. أما إذا سجّل خادمك عنوان Cloudflare بينما يعرض whatsmy.fyi عنوانك الحقيقي، فأنت ما زلت تقرأ REMOTE_ADDR خلف الوكيل — بدّل إلى CF-Connecting-IP. وإن اختلفا بأي شكل آخر، فهناك شبكة افتراضية خاصة (VPN)، أو انقسام بين IPv4/IPv6، أو وكيل ثانٍ في المسار — وملاحظتنا حول لماذا قد يُظهر عنوان IP موقعاً خاطئاً تغطّي هذه الحالات.
الخلاصة في سطر واحد
REMOTE_ADDR هو الحقيقة التي لا يمكن الكذب على خادمك بشأنها؛ أما HTTP_CLIENT_IP فهو ادّعاء يستطيع أي أحد أن يدّعيه. خلف Cloudflare، فضّل CF-Connecting-IP وأحكِم إغلاق خادم الأصل لديك ليبقى جديراً بالثقة — ثم تأكّد من النتيجة بمقارنتها بعنوانك الحقيقي على whatsmy.fyi.
