REMOTE_ADDR vs CF-Connecting-IP: Cloudflare Arkasında Gerçek Ziyaretçi IP'sini Bulma

Bir WordPress güvenlik eklentisi sizi "IP algılama ayarları" konusunda uyarıyorsa ya da PHP uygulamanız birden her ziyaretçi için aynı birkaç IP'yi loglamaya başladıysa, sebep neredeyse her zaman aynıdır: ziyaretçileriniz ile sunucunuz arasında Cloudflare gibi bir ters proxy duruyordur. Kısacası — varsayılan olarak REMOTE_ADDR'ı kullanın, HTTP_CLIENT_IP'ye asla körü körüne güvenmeyin ve CF-Connecting-IP'yi yalnızca isteğin gerçekten Cloudflare üzerinden geldiğini doğruladıktan sonra okuyun. İşte bunların her birinin arkasındaki mantık.

Her değer aslında ne anlama geliyor

PHP'de bunlar $_SERVER kayıtları olarak gelir. Birbirinin yerine kullanılamazlar — tamamen farklı yerlerden gelirler ve işin tüm özü de bu farkta yatar:

• REMOTE_ADDR — sunucunuza TCP bağlantısını kim açtıysa onun IP adresi. Web sunucusu bunu doğrudan soketin kendisinden doldurur, dolayısıyla bir istemci bunu taklit edemez. Güvenebileceğiniz tek değer budur.
• HTTP_CLIENT_IP ve HTTP_X_FORWARDED_FOR — sıradan HTTP istek başlıkları. $_SERVER içindeki herhangi bir HTTP_* kaydı, istemcinin gönderdiği bir başlıktan ibarettir; yani herkes bunu tek satır curl ile istediği değere ayarlayabilir.
• HTTP_CF_CONNECTING_IP — Cloudflare'in eklediği, gerçek ziyaretçi IP'sini taşıyan CF-Connecting-IP başlığı. Yalnızca isteğin Cloudflare üzerinden geçtiğini garanti edebildiğinizde güvenilirdir.

Cloudflare arkasında REMOTE_ADDR neden "yanlış"

Cloudflare alan adınıza proxy yaptığında ziyaretçileriniz Cloudflare'in uç sunucusuna bağlanır ve Cloudflare de origin sunucunuza taze bir bağlantı açar. Sunucunuzun bakış açısından ziyaretçi tam olarak Cloudflare'dir — bu yüzden REMOTE_ADDR bir Cloudflare uç IP'sidir ve binlerce farklı insan için aynıdır. Bozulan bir şey yok; proxy yalnızca işini yapıyor.

Asıl ziyaretçiyi size iletmek için Cloudflare her isteğe CF-Connecting-IP başlığını ekler. Yani Cloudflare arkasında doğru kaynak $_SERVER['HTTP_CF_CONNECTING_IP']'dir; bu başlık yoksa REMOTE_ADDR'a geri düşülür.

Güvenlik tuzağı: başlığa neden öylece güvenemezsiniz

"HTTP_CLIENT_IP veya X-Forwarded-For oku, yoksa REMOTE_ADDR kullan" deyip geçmek cazip gelir. İşte siteleri ele geçirten kalıp tam olarak budur. Bunlar istemcinin sağladığı başlıklar olduğundan, bir saldırgan şunu gönderebilir:

curl https://your-site.example/wp-login.php \
  -H "X-Forwarded-For: 8.8.8.8" \
  -H "Client-IP: 1.1.1.1"

Giriş hız sınırlamanız, güvenlik duvarınız veya denetim günlüğünüz bu başlıkları okuyorsa, saldırgan her istekte sahte bir IP döndürebilir — hız sınırlarını aşar, IP yasaklarını atlatır ve loglarınızı kirletir. İyi bir güvenlik eklentisinin algılama yöntemini değiştirmeden önce sizi uyarmasının sebebi budur: "daha kolay" ayar çoğu zaman güvensiz olandır.

CF-Connecting-IP bundan yalnızca tek bir ek koşul sayesinde korunur: origin'iniz trafiği sadece Cloudflare'den kabul etmelidir. Sunucunuza genel IP'si üzerinden doğrudan da erişilebiliyorsa, bir saldırgan Cloudflare'i atlayıp CF-Connecting-IP'yi kendisi uydurabilir. Origin'i Authenticated Origin Pulls ile ya da yalnızca Cloudflare'in IP aralıklarına izin veren bir güvenlik duvarıyla kilitleyin; o zaman başlık güvenilir hale gelir.

Doğru ayar, sade anlatımla

• Düz sunucu, proxy yok: REMOTE_ADDR kullanın. Bitti.
• Cloudflare arkasında: CF-Connecting-IP (HTTP_CF_CONNECTING_IP) kullanın ve başlığın taklit edilememesi için origin'inizi Cloudflare ile sınırlandırın.
• Başka bir proxy/CDN veya yük dengeleyici arkasında: o proxy'nin belgelediği başlığı kullanın (genelde X-Forwarded-For, en sağdaki güvenilir atlamayı alarak) ve yine origin'in yalnızca o proxy'den trafik kabul ettiğinden emin olun.

All-In-One Security gibi WordPress güvenlik eklentilerinde "IP algılama" ayarının kontrol ettiği şey tam olarak bu seçimdir. Cloudflare arkasında değilseniz REMOTE_ADDR'da bırakın; Cloudflare arkasındaysanız CF-Connecting-IP'ye geçirin.

Doğru yaptığınızı nasıl doğrularsınız

En hızlı akıl yürütme kontrolü, sunucunuzun algıladığı şeyi gerçek genel IP'nizle karşılaştırmaktır. Aynı makineden whatsmy.fyi adresini açın: dış dünyanın sizi gördüğü tam genel IP'yi gösterir. Eklentinizin veya uygulamanızın kendi ziyaretiniz için logladığı IP buna uyuyorsa algılama çalışıyordur. (whatsmy.fyi'nin kendisi Cloudflare üzerinde çalışır, dolayısıyla adresinizi tıpkı doğru yapılandırılmış bir origin gibi CF-Connecting-IP'den okur — ve hiçbir şey saklamaz.)

Programatik olarak hata ayıklıyorsanız, anahtar gerektirmeyen uç nokta script'ler için aynı değeri döner:

curl https://whatsmy.fyi/ip
# → your real public IP, as seen at the edge

Birbirine uyan iki IP, algılamanızın doğru olduğu anlamına gelir. Sunucunuz bir Cloudflare IP'si loglarken whatsmy.fyi gerçek IP'nizi gösteriyorsa, proxy arkasında hâlâ REMOTE_ADDR okuyorsunuz demektir — CF-Connecting-IP'ye geçin. Başka bir şekilde farklılık gösteriyorlarsa, yolda bir VPN, IPv4/IPv6 ayrımı veya ikinci bir proxy vardır — bir IP'nin neden yanlış konum gösterebileceği üzerine notumuz bu durumları kapsıyor.

Tek cümlelik özet

REMOTE_ADDR sunucunuzun kandırılamayacağı gerçektir; HTTP_CLIENT_IP ise herkesin yapabileceği bir iddiadır. Cloudflare arkasında CF-Connecting-IP'yi tercih edin ve güvenilir kalması için origin'inizi kilitleyin — ardından sonucu whatsmy.fyi adresindeki gerçek adresinizle karşılaştırarak doğrulayın.