Cloudflare Arkasında Gerçek Ziyaretçi IP Adresini Geri Getirme

Loglarda neden Cloudflare IP'si görünüyor?

Turuncu bulutlu (Proxied) bir kayıtta bağlantı zinciri "ziyaretçi - Cloudflare - sunucunuz" şeklindedir. Sunucunuz TCP bağlantısını Cloudflare'in bir veri merkezinden alır, bu yüzden REMOTE_ADDR değeri Cloudflare'in IP'sidir. Bu mimarinin genel mantığı için reverse proxy nedir ve Proxied ve DNS only farkı yazılarına bakabilirsiniz.

Çözüm, web sunucusuna "bağlantı bu güvenilir proxy'lerden geliyorsa gerçek istemci adresini şu başlıktan al" demektir. Bu işlem sunucu düzeyinde yapıldığında loglar, PHP'deki REMOTE_ADDR ve IP tabanlı erişim kuralları otomatik olarak doğru adresi görür.

Cloudflare hangi başlıkları gönderir?

Cloudflare belgesi, log ve uygulamalarınızın X-Forwarded-For yerine CF-Connecting-IP (Enterprise'da isterseniz True-Client-IP) başlığına bakmasını önerir. Sebebi basit: X-Forwarded-For bir zincirdir ve ziyaretçi bu başlığa kendi istediği değeri yazarak isteğe başlayabilir.

Apache: mod_remoteip ile gerçek IP

Cloudflare eskiden mod_cloudflare modülünü sunuyordu; bugün bu modülün Debian 9 ve Ubuntu 18.04 LTS için güncellenmediğini, Apache 2.4 için Apache'nin kendi mod_remoteip modülünün kullanılmasını öneriyor. Aşağıdaki adımlar Debian/Ubuntu dizin yapısına göredir; RHEL tabanlı sistemlerde dosya yolları farklıdır.

1. Cloudflare IP listesini hazırlayın

Cloudflare IP aralıkları zaman zaman değişir; bu yüzden burada listelemiyoruz. Güncel liste cloudflare.com/ips sayfasında, düz metin olarak da /ips-v4 ve /ips-v6 adreslerinde yayınlanır. mod_remoteip, RemoteIPTrustedProxyList ile güvenilir proxy'leri bir dosyadan okuyabilir; her satır bir RemoteIPTrustedProxy girdisi gibi işlenir.

# Cloudflare IP listesini cloudflare.com/ips adresinden indirip dosyaya yazın
sudo sh -c 'curl -s https://www.cloudflare.com/ips-v4 > /etc/apache2/cloudflare-ips.lst; echo >> /etc/apache2/cloudflare-ips.lst; curl -s https://www.cloudflare.com/ips-v6 >> /etc/apache2/cloudflare-ips.lst'
cat /etc/apache2/cloudflare-ips.lst

2. remoteip yapılandırmasını yazın

# /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxyList /etc/apache2/cloudflare-ips.lst

# Alternatif: her aralık için ayrı satır (cloudflare.com/ips listesindeki her aralık)
# RemoteIPTrustedProxy 192.0.2.0/24

RemoteIPTrustedProxy (ve liste sürümü) dış proxy'ler içindir: bu proxy'lerden gelen başlıkta özel ağ adresleri (10/8, 172.16/12, 192.168/16 gibi) varsa istemci adresi olarak kabul edilmez. Cloudflare için doğru direktif budur.

3. Log formatında %h yerine %a kullanın

Apache belgesine göre mod_remoteip'in değiştirdiği adres %a biçimiyle loglanır. Varsayılan combined formatta %h kullanıldığı için Cloudflare'in tavsiyesi bu satırı düzenlemektir:

# /etc/apache2/apache2.conf içindeki combined LogFormat satırında %h yerine %a
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

4. Etkinleştirin ve test edin

sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

configtest çıktısı "Syntax OK" olmalıdır. Değiştirilen adres ayrıca Require ip kurallarında da kullanılır, yani .htaccess ile yaptığınız IP kısıtlamaları artık gerçek ziyaretçi adresine göre çalışır. .htaccess ayrıntıları için .htaccess rehberine bakabilirsiniz.

Nginx: set_real_ip_from ve real_ip_header

Nginx'te bu iş ngx_http_realip_module ile yapılır. set_real_ip_from doğru adres göndermesine güvenilen proxy'leri, real_ip_header ise gerçek adresin okunacağı başlığı tanımlar. Her iki direktif de http, server ve location bağlamlarında kullanılabilir. Modül kaynak koddan derlemede varsayılan olarak gelmez; kurulu olup olmadığını nginx -V ile kontrol edin.

Cloudflare aralıklarını elle yazmak yerine bir include dosyası üretebilirsiniz. Debian/Ubuntu paketlerinde /etc/nginx/conf.d/*.conf dosyaları genellikle http bloğu içine dahil edilir; kendi nginx.conf dosyanızda bunu doğrulayın.

# Cloudflare aralıklarından nginx include dosyası üretin
{
  for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
    echo "set_real_ip_from $ip;"
  done
  echo "real_ip_header CF-Connecting-IP;"
} | sudo tee /etc/nginx/conf.d/cloudflare-realip.conf

Oluşan dosya aşağıdakine benzer (örnekteki adresler belgeleme amaçlı ayrılmış aralıklardır, gerçek Cloudflare adresleri değildir):

# /etc/nginx/conf.d/cloudflare-realip.conf (örnek görünüm)
set_real_ip_from 192.0.2.0/24;      # cloudflare.com/ips listesindeki her aralık için bir satır
set_real_ip_from 2001:db8::/32;
real_ip_header CF-Connecting-IP;

nginx -V 2>&1 | grep -o with-http_realip_module
sudo nginx -t && sudo systemctl reload nginx

CF-Connecting-IP tek bir adres içerdiği için real_ip_recursive ayarına ihtiyaç yoktur. Nginx, ziyaretçinin asıl bağlantı adresini $realip_remote_addr değişkeninde saklar; teşhis için bunu log formatına ekleyebilirsiniz. Server block yapısı için Nginx server block rehberine bakın.

LiteSpeed ve cPanel tarafı

LiteSpeed Web Server'da ayar WebAdmin Console'da Server Configuration > General Settings altındaki Use Client IP in Header seçeneğidir. LiteSpeed belgesi bu değerin Trusted IP Only olmasını, asla Yes yapılmamasını söyler; çünkü Yes seçildiğinde istemciler sahte X-Forwarded-For başlığıyla IP adreslerini taklit edebilir. Aynı belgeye göre LiteSpeed, Cloudflare ve QUIC.cloud IP adreslerini otomatik olarak güvenilir listeye alır. Değişiklikten sonra Graceful Restart gerekir.

Bu ayar sunucu düzeyindedir. Paylaşımlı cPanel hostingde siz değil hosting sağlayıcınız yönetir; loglarınızda hâlâ Cloudflare IP'leri görünüyorsa sağlayıcınıza bu ayarın durumunu sorun. LiteSpeed belgesi ayrıca gerçek IP'nin erişim loglarında göründüğünü, hata loglarında ise proxy adreslerinin kalabileceğini belirtir. Cloudflare'in cPanel/EasyApache için anlattığı mod_cloudflare yöntemi kullanımdan kaldırılmış (deprecated) olarak işaretlidir.

WordPress ve uygulama tarafındaki etkiler

Gerçek IP sunucu düzeyinde geri getirildiğinde PHP'deki $_SERVER['REMOTE_ADDR'] de doğru değeri gösterir. WordPress yorumlarındaki IP alanı, giriş denemesi sınırlayıcı eklentiler, güvenlik eklentileri ve istatistik araçları bu değeri kullandığı için ek bir ayar gerekmez. Sunucu ayarı yapılmadan bu araçlar tüm ziyaretçileri birkaç Cloudflare adresi olarak görür; bir saldırganı engellemek isteyen bir eklenti yanlışlıkla bir Cloudflare adresini engelleyip çok sayıda gerçek ziyaretçiyi etkileyebilir.

Cloudflare belgesinde uygulama düzeyinde REMOTE_ADDR değerini HTTP_CF_CONNECTING_IP ile değiştiren bir PHP örneği de vardır. Bu yöntem yalnızca betikleri etkiler, sunucu loglarını değiştirmez. Daha önemlisi, isteğin gerçekten Cloudflare'den gelip gelmediğini kontrol etmezseniz sunucunuza doğrudan bağlanan biri bu başlığı kendisi yazabilir. Mümkünse sunucu düzeyindeki yöntemi tercih edin.

Güvenlik: başlıklara yalnızca Cloudflare'den geldiğinde güvenin

CF-Connecting-IP sıradan bir HTTP başlığıdır. Sunucunuza Cloudflare'i atlayarak doğrudan bağlanan biri bu başlığı istediği değerle gönderebilir. Yukarıdaki yapılandırmaların hepsinin ortak noktası, başlığı yalnızca bağlantı Cloudflare IP aralıklarından geldiğinde dikkate almasıdır. Bu yüzden güvenilir proxy listesini her zaman cloudflare.com/ips sayfasındaki güncel aralıklarla sınırlayın ve listeyi belirli aralıklarla güncelleyin.

Sunucu güvenlik duvarını Cloudflare IP'leriyle sınırlayın

Bir adım daha ileri giderek web portlarınızı (80 ve 443) yalnızca Cloudflare aralıklarına açabilirsiniz. Böylece sunucu IP'nizi bir şekilde öğrenen biri Cloudflare'in WAF ve DDoS korumasını atlayarak doğrudan sunucunuza bağlanamaz. Ubuntu'da UFW ile örnek:

# 80 ve 443 portlarını yalnızca Cloudflare aralıklarına açın
for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443
done

# Daha önce herkese açtığınız genel kuralları kaldırın (kendi kurallarınıza göre)
sudo ufw status numbered
sudo ufw delete allow 80/tcp
sudo ufw delete allow 443/tcp

Sunucu IP'nizi gizli tutmak da bu korumanın parçasıdır: aynı sunucuya işaret eden DNS only bir kayıt (örneğin ftp veya mail alt alan adı) sunucu adresini herkese gösterir. Kayıt türleri için DNS kayıt türleri rehberine bakabilirsiniz. Daha sıkı bir doğrulama isterseniz SSL modları rehberinde anlattığımız Authenticated Origin Pulls ile sunucunuz isteğin Cloudflare'den geldiğini sertifikayla da doğrulayabilir.

Kurulumu nasıl doğrularım?

• Kendi IP adresinizi öğrenin ve siteyi tarayıcıdan açın.
• Erişim logunun son satırına bakın: sudo tail -n 5 /var/log/apache2/access.log veya sudo tail -n 5 /var/log/nginx/access.log.
• Satırın başında Cloudflare adresi yerine kendi IP'niz görünüyorsa yapılandırma çalışıyordur.
• Hâlâ Cloudflare adresi görünüyorsa: modül etkin mi, yapılandırma dosyası gerçekten yüklendi mi, log formatında %a var mı ve Managed Transforms içinde "Remove visitor IP headers" kapalı mı kontrol edin.

Sık Sorulan Sorular

CF-Connecting-IP mi, X-Forwarded-For mu kullanmalıyım?

Cloudflare, CF-Connecting-IP başlığını önerir. Tek bir adres içerir ve Cloudflare tarafından yazılır. X-Forwarded-For bir zincirdir ve baş kısmı istemci tarafından yazılmış olabilir.

True-Client-IP ücretsiz planda kullanılabilir mi?

Hayır. Cloudflare belgelerine göre True-Client-IP ve onu ekleyen "Add True-Client-IP header" Managed Transform yalnızca Enterprise planda vardır. Diğer planlarda CF-Connecting-IP kullanın.

Cloudflare IP listesini ne sıklıkla güncellemeliyim?

Liste sık değişmez ama değişir; cloudflare.com/ips sayfası geçmiş değişiklikleri tarihleriyle gösterir. Listeyi indiren komutları periyodik çalışan bir göreve bağlamak veya belirli aralıklarla elle kontrol etmek iyi bir alışkanlıktır.

Paylaşımlı hostingde bunu kendim yapabilir miyim?

Genellikle hayır, çünkü mod_remoteip, Nginx realip ve LiteSpeed ayarları sunucu düzeyindedir. LiteSpeed kullanan sunucularda LiteSpeed belgesine göre Cloudflare adresleri otomatik güvenilir kabul edilir. Emin değilseniz hosting sağlayıcınıza sorun.

Gerçek IP'yi geri getirmek SEO'yu etkiler mi?

Doğrudan etkilemez. Ancak bot tespiti ve IP tabanlı engellemelerin doğru çalışmasını sağlar. Sahte botları ayırt etmek için Googlebot doğrulama rehberine bakabilirsiniz.

Cloudflare ve adı geçen diğer hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; Cloudflare ile ortaklık veya bayilik ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Cloudflare nasıl kurulur · Proxied ve DNS only farkı · Cloudflare WAF ve bot koruması · Cloudflare SSL modları · UFW güvenlik duvarı · Reverse proxy nedir · Nginx yapılandırma