نمایش IP واقعی کاربر پشت Reverse Proxy و Cloudflare در Nginx

وقتی سایت یا API پشت Nginx Reverse Proxy، Load Balancer یا Cloudflare قرار می‌گیرد، سرور Origin دیگر همیشه مستقیماً IP کاربر را نمی‌بیند. در بسیاری از تنظیمات، به‌جای IP واقعی بازدیدکننده، IP پراکسی یا یکی از نودهای Cloudflare داخل لاگ Nginx، PHP، Laravel، WordPress یا برنامه Backend ثبت می‌شود.

چرا به‌جای IP کاربر، IP Cloudflare یا Reverse Proxy دیده می‌شود؟

در حالت عادی ارتباط مستقیم شبیه این است:

User: 203.0.113.25
       |
       v
     Nginx

Nginx در این حالت IP منبع TCP Connection را به‌عنوان $remote_addr می‌شناسد.

اما پشت Reverse Proxy:

User: 203.0.113.25
       |
       v
 Reverse Proxy
  10.0.0.10
       |
       v
     Nginx

از دید Nginx، اتصال TCP از 10.0.0.10 آمده است. بنابراین بدون تنظیم Real IP، این آدرس در $remote_addr دیده می‌شود.

در Cloudflare نیز وضعیت مشابه است:

Visitor
   |
   v
Cloudflare Edge
   |
   v
Origin Nginx

Origin اتصال شبکه را از IP نود Cloudflare دریافت می‌کند، نه مستقیماً از مرورگر کاربر.

Cloudflare IP واقعی کاربر را کجا قرار می‌دهد؟

Cloudflare برای Requestهایی که از Edge خود به Origin می‌فرستد Header زیر را اضافه می‌کند:

CF-Connecting-IP: 203.0.113.25

این Header یک IP را در اختیار Origin قرار می‌دهد و برای بازیابی IP اصلی بازدیدکننده پشت Cloudflare گزینه مناسبی است.

Cloudflare همچنین X-Forwarded-For را مدیریت می‌کند، اما این Header می‌تواند یک زنجیره شامل چند Proxy داشته باشد:

X-Forwarded-For:
203.0.113.25, 198.51.100.10, 198.51.100.20

برای یک Origin مستقیم پشت Cloudflare، استفاده از CF-Connecting-IP معمولاً ساده‌تر و قابل‌پیش‌بینی‌تر است.

هشدار امنیتی: هر Headerی را Trust نکنید

real_ip_header CF-Connecting-IP;

راه امن این است که فقط Proxyهایی که واقعاً کنترل می‌کنید مورد اعتماد قرار بگیرند.

برای Cloudflare:

set_real_ip_from CLOUDFLARE_NETWORK;
real_ip_header CF-Connecting-IP;

یعنی Nginx فقط زمانی Header را معتبر در نظر می‌گیرد که اتصال از یکی از IPهای مورد اعتماد Cloudflare آمده باشد.

مرحله اول: بررسی ماژول Real IP در Nginx

قابلیت موردنیاز در ماژول زیر قرار دارد:

ngx_http_realip_module

بررسی Build فعلی:

nginx -V 2>&1 | grep -- --with-http_realip_module

اگر عبارت زیر دیده شد:

--with-http_realip_module

ماژول داخل Build موجود است.

بسته‌های استاندارد Nginx در بسیاری از توزیع‌های رایج این قابلیت را ارائه می‌کنند، اما بهتر است به‌جای حدس زدن Build واقعی سرور خودتان را بررسی کنید.

سناریوی اول: Reverse Proxy معمولی بدون Cloudflare

فرض کنید معماری این است:

User
 |
 v
Nginx Proxy #1
10.10.0.10
 |
 v
Nginx / Application Server

Proxy اول باید IP را Forward کند:

location / {
    proxy_pass http://10.10.0.20:3000;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

$proxy_add_x_forwarded_for مقدار موجود X-Forwarded-For را نگه می‌دارد و IP فعلی Client از دید Proxy را به انتهای آن اضافه می‌کند.

سمت سرور مقصد چه تنظیمی لازم است؟

اگر فقط Proxy با IP 10.10.0.10 مجاز است IP واقعی را اعلام کند:

set_real_ip_from 10.10.0.10;

real_ip_header X-Forwarded-For;
real_ip_recursive on;

اگر Proxyها داخل یک Subnet خصوصی مشخص هستند:

set_real_ip_from 10.10.0.0/24;

real_ip_header X-Forwarded-For;
real_ip_recursive on;

real_ip_recursive on در زنجیره Proxyها باعث می‌شود Nginx به‌جای انتخاب یک IP Trusted، آخرین IP غیر Trusted در زنجیره را به‌عنوان Client در نظر بگیرد.

سناریوی اصلی: Nginx پشت Cloudflare

برای Cloudflare باید تمام Rangeهای رسمی IPv4 و IPv6 آن را Trusted کنید.

ساختار فایل پیشنهادی:

/etc/nginx/conf.d/cloudflare-realip.conf

داخل فایل:

# فقط نمونه ساختار است.
# تمام Rangeهای فعلی Cloudflare باید اینجا قرار بگیرند.

set_real_ip_from CLOUDFLARE_IPV4_CIDR;
set_real_ip_from CLOUDFLARE_IPV6_CIDR;

real_ip_header CF-Connecting-IP;

ساخت فایل Nginx از Rangeهای رسمی Cloudflare

می‌توانید Rangeها را دریافت و به فرمت Nginx تبدیل کنید.

ابتدا فایل موقت بسازید:

tmpfile=$(mktemp)

IPv4:

curl -fsSL https://www.cloudflare.com/ips-v4 \
  | sed 's/^/set_real_ip_from /; s/$/;/' \
  >> "$tmpfile"

IPv6:

curl -fsSL https://www.cloudflare.com/ips-v6 \
  | sed 's/^/set_real_ip_from /; s/$/;/' \
  >> "$tmpfile"

Header اصلی:

echo 'real_ip_header CF-Connecting-IP;' \
  >> "$tmpfile"

فایل را بررسی کنید:

cat "$tmpfile"

اگر صحیح بود:

sudo cp "$tmpfile" \
  /etc/nginx/conf.d/cloudflare-realip.conf

سپس:

sudo nginx -t

و فقط در صورت موفق بودن تست:

sudo systemctl reload nginx

مطمئن شوید Configuration واقعاً Load شده است

sudo nginx -T 2>&1 \
  | grep -E 'set_real_ip_from|real_ip_header'

باید Rangeهای Cloudflare و این مقدار دیده شوند:

real_ip_header CF-Connecting-IP;

بعد از فعال شدن Real IP چه اتفاقی می‌افتد؟

وقتی درخواست واقعاً از یک Proxy مورد اعتماد بیاید، Nginx مقدار Client Address را با Header انتخاب‌شده جایگزین می‌کند.

پس:

$remote_addr

می‌تواند IP واقعی کاربر شود.

در عین حال متغیر:

$realip_remote_addr

آدرس اصلی Peer را نگه می‌دارد؛ یعنی در سناریوی Cloudflare معمولاً می‌توانید IP Edge Cloudflare را هم برای عیب‌یابی حفظ کنید.

بهترین روش: IP کاربر و IP Proxy را هر دو Log کنید

در بخش http فایل Nginx یک Log Format سفارشی تعریف کنید:

log_format realip_combined
    '$remote_addr '
    'proxy=$realip_remote_addr '
    'cf=$http_cf_connecting_ip '
    'xff="$http_x_forwarded_for" '
    '- $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

و در Virtual Host:

access_log /var/log/nginx/access.log realip_combined;

بعد:

sudo nginx -t
sudo systemctl reload nginx

نمونه خروجی Log

203.0.113.25
proxy=172.64.10.20
cf=203.0.113.25
xff="203.0.113.25"
- - [05/Oct/2026:12:10:00 +0000]
"GET / HTTP/1.1" 200 18342

در این مثال:

• 203.0.113.25 IP واقعی کاربر است.
• 172.64.10.20 فقط یک نمونه IP از Proxy جلویی است.
• CF-Connecting-IP همان IP کاربر را حمل کرده است.

اگر Nginx دوباره درخواست را به Backend Forward می‌کند

بعد از اینکه Real IP Module مقدار $remote_addr را اصلاح کرد، می‌توانید همین IP را به Backend بفرستید:

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_set_header Host $host;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_set_header X-Forwarded-Proto $scheme;
}

در این ساختار، Backend یک مقدار تمیز و مشخص برای IP کاربر دریافت می‌کند.

IP واقعی در Laravel

بعد از اینکه Nginx Header درست را به Laravel Forward می‌کند، Application نیز باید Proxyهای مورد اعتماد را درست بشناسد.

در معماری‌های Proxyشده، Laravel یا Frameworkهای مشابه معمولاً تنظیم Trusted Proxy دارند. اگر Application به همه X-Forwarded-Forها بدون محدودیت اعتماد کند، همان مشکل Spoofing در سطح اپلیکیشن تکرار می‌شود.

بنابراین دو مرحله لازم است:

1. Nginx فقط Proxy معتبر را Trust کند.
2. Backend نیز فقط Headerهای Forward شده از Nginx معتبر را قبول کند.

بعد از تنظیم صحیح، IP‌ای که Application به‌عنوان Client می‌بیند باید با IP واقعی بازدیدکننده یکسان باشد.

IP واقعی در Node.js و Express

اگر Express مستقیماً پشت Nginx است، معمولاً Header زیر را دریافت می‌کند:

X-Forwarded-For: 203.0.113.25

اما Express نیز نباید بدون شناخت معماری به هر Proxy اعتماد کند.

تنظیم trust proxy باید متناسب با تعداد یا شبکه Proxyهای واقعی پروژه انجام شود؛ نه اینکه صرفاً برای رفع مشکل، تمام اینترنت Trusted شود.

IP واقعی در PHP

اگر Real IP Module در همان Nginx جلوی PHP-FPM اعمال شده باشد، مقدار REMOTE_ADDR معمولاً از آدرس اصلاح‌شده Nginx استفاده می‌کند.

برای بررسی موقت:

<?php

echo $_SERVER['REMOTE_ADDR'] ?? '';

این فایل را بعد از تست از سرور حذف کنید؛ صفحه Debug عمومی روی Production نگه ندارید.

WordPress پشت Cloudflare

اگر Nginx Real IP را در سطح Web Server درست بازیابی کرده باشد، بهتر است WordPress نیز همان REMOTE_ADDR اصلاح‌شده را ببیند.

این روش نسبت به دستکاری مستقیم Headerهای Cloudflare داخل wp-config.php تمیزتر است، چون Restore IP در لایه Web Server انجام شده و Logهای Nginx، PHP و Application همگی رفتار هماهنگ‌تری خواهند داشت.

Rate Limit و Fail2Ban بدون Real IP چه مشکلی پیدا می‌کنند؟

اگر Nginx فقط IP Cloudflare را ببیند، Rate Limit ممکن است تمام کاربران را یک Client حساب کند.

برای مثال:

limit_req_zone
    $binary_remote_addr
    zone=api_limit:10m
    rate=10r/s;

اگر $remote_addr IP Edge Cloudflare باشد، Rate Limit روی Cloudflare اعمال می‌شود، نه کاربران واقعی.

بعد از تنظیم امن Real IP، $binary_remote_addr نیز بر اساس IP بازیابی‌شده کار می‌کند.

تأثیر روی لاگ‌های امنیتی

IP واقعی برای موارد زیر اهمیت زیادی دارد:

• تشخیص Brute Force
• Fail2Ban
• Rate Limiting
• WAF داخلی
• Audit Log
• تحلیل حملات
• محدودیت دسترسی بر اساس IP

اما فقط زمانی می‌توان به IP بازیابی‌شده اعتماد کرد که Proxy Chain نیز مورد اعتماد و کنترل‌شده باشد.

یک مشکل مهم: دور زدن Cloudflare و اتصال مستقیم به Origin

حتی اگر Real IP Nginx را درست تنظیم کنید، اگر Origin از اینترنت مستقیماً قابل دسترسی باشد، مهاجم می‌تواند Cloudflare را دور بزند.

طراحی امن‌تر این است که در Firewall فقط ترافیک HTTP/HTTPS از Rangeهای Cloudflare به Origin اجازه داده شود.

در این صورت:

Internet
   |
   X  Direct access blocked
   |
Cloudflare
   |
   v
Origin

این کار علاوه بر جلوگیری از Spoof شدن Headerها، Origin IP را نیز بهتر در برابر دسترسی مستقیم محافظت می‌کند.

Pseudo IPv4 در Cloudflare

اگر ویژگی Pseudo IPv4 روی حالت Overwrite Headers تنظیم شود، Cloudflare می‌تواند مقادیر CF-Connecting-IP و X-Forwarded-For را با IPv4 مصنوعی جایگزین کند و IPv6 واقعی کاربر را در Header دیگری نگه دارد.

اگر IPهای مشاهده‌شده با انتظار شما همخوانی ندارند و کاربران IPv6 دارید، تنظیم Pseudo IPv4 در Cloudflare را نیز بررسی کنید.

تست Headerهای دریافتی

برای Debug موقت می‌توانید یک Log Format ساده ایجاد کنید:

log_format ipdebug
    'remote=$remote_addr '
    'peer=$realip_remote_addr '
    'cf=$http_cf_connecting_ip '
    'xff="$http_x_forwarded_for"';

و برای یک Virtual Host موقت:

access_log
    /var/log/nginx/ip-debug.log
    ipdebug;

سپس:

sudo tail -f /var/log/nginx/ip-debug.log

تست مستقیم Origin چه چیزی نشان می‌دهد؟

اگر Origin IP را مستقیماً صدا بزنید، درخواست از Cloudflare عبور نمی‌کند و طبیعتاً CF-Connecting-IP معتبر Cloudflare وجود نخواهد داشت.

به همین دلیل هنگام تست، تفاوت بین:

https://example.com

و دسترسی مستقیم به Origin را در نظر بگیرید.

اگر Cloudflare جلوی یک Reverse Proxy دیگر است

مثلاً:

User
 |
 v
Cloudflare
 |
 v
Public Nginx
 |
 v
Internal Nginx
 |
 v
Application

بهترین روش این است که Public Nginx ابتدا IP واقعی را با CF-Connecting-IP Restore کند.

سپس هنگام Forward به Internal Nginx:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;

و Internal Nginx فقط Public Nginx را Trust کند:

set_real_ip_from 10.10.0.10;
real_ip_header X-Forwarded-For;

این روش Trust Boundary مشخصی ایجاد می‌کند.

اگر Load Balancer از PROXY Protocol استفاده می‌کند

بعضی Load Balancerها به‌جای HTTP Header، اطلاعات Client IP را با PROXY Protocol ارسال می‌کنند.

در این سناریو Configuration متفاوت است:

server {
    listen 443 ssl proxy_protocol;

    set_real_ip_from 10.0.0.0/24;
    real_ip_header proxy_protocol;
}

PROXY Protocol را فقط زمانی فعال کنید که Load Balancer جلویی واقعاً آن را ارسال می‌کند؛ در غیر این صورت Connectionها خراب می‌شوند.

real_ip_recursive دقیقاً چه کاری می‌کند؟

وقتی از Header چندمقداری مثل X-Forwarded-For استفاده می‌کنید، این Directive اهمیت پیدا می‌کند:

real_ip_recursive on;

با حالت Recursive، Nginx در زنجیره به‌دنبال آخرین آدرسی می‌گردد که داخل لیست Proxyهای Trusted قرار ندارد.

برای CF-Connecting-IP که یک IP مشخص حمل می‌کند، معمولاً نیازی به تحلیل زنجیره چند IP وجود ندارد.

Rangeهای Cloudflare را چگونه به‌روز نگه داریم؟

چون Cloudflare توصیه می‌کند Prefixهای Trusted به‌روز باشند، می‌توانید یک Script دوره‌ای بسازید که:

1. Rangeهای IPv4 و IPv6 را دانلود کند.
2. یک فایل موقت Nginx بسازد.
3. با nginx -t Configuration را بررسی کند.
4. فقط در صورت موفقیت فایل قبلی را جایگزین کند.
5. Nginx را Reload کند.

این روش بهتر از جایگزینی مستقیم فایل بدون Validation است.

نمونه کامل Nginx پشت Cloudflare

فرض می‌کنیم فایل Rangeهای Cloudflare جداگانه در این مسیر Include شده است:

/etc/nginx/conf.d/cloudflare-realip.conf

و Virtual Host:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com;

    ssl_certificate
        /etc/letsencrypt/live/example.com/fullchain.pem;

    ssl_certificate_key
        /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;

        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

و داخل فایل Cloudflare:

# set_real_ip_from ...
# تمام IPv4/IPv6 Prefixهای رسمی Cloudflare

real_ip_header CF-Connecting-IP;

تست نهایی

اول Configuration:

sudo nginx -t

Reload:

sudo systemctl reload nginx

بعد Log را باز کنید:

sudo tail -f /var/log/nginx/access.log

حالا با اینترنت موبایل یا یک Connection دیگر سایت را باز کنید و IP عمومی دستگاه را با Log مقایسه کنید.

ترتیب پیشنهادی عیب‌یابی

1. مشخص کنید چند Proxy بین کاربر و Origin قرار دارد.
2. بررسی کنید ngx_http_realip_module فعال است.
3. Header معتبر Proxy را مشخص کنید.
4. فقط IP/Subnet Proxyهای معتبر را با set_real_ip_from Trust کنید.
5. برای Cloudflare از CF-Connecting-IP استفاده کنید.
6. Configuration را با nginx -t تست کنید.
7. هم $remote_addr و هم $realip_remote_addr را موقتاً Log کنید.
8. IP اصلاح‌شده را به Backend Forward کنید.
9. Trusted Proxy تنظیمات Application را نیز بررسی کنید.
10. در صورت امکان دسترسی مستقیم به Origin را در Firewall محدود کنید.

Rollback؛ اگر بعد از تنظیم Real IP مشکلی ایجاد شد

قبل از تغییر فایل:

sudo cp /etc/nginx/nginx.conf \
  /etc/nginx/nginx.conf.backup

اگر فایل جداگانه ساخته‌اید:

sudo cp /etc/nginx/conf.d/cloudflare-realip.conf \
  /etc/nginx/conf.d/cloudflare-realip.conf.backup

بازگردانی و تست:

sudo cp /etc/nginx/nginx.conf.backup \
  /etc/nginx/nginx.conf

sudo nginx -t
sudo systemctl reload nginx

اشتباه‌های رایج

• اعتماد کردن به CF-Connecting-IP از هر Source IP؛
• استفاده از X-Forwarded-For بدون تعریف Trusted Proxy؛
• Hard-code کردن Rangeهای قدیمی Cloudflare و به‌روز نکردن آن‌ها؛
• اعتماد به تمام اینترنت با set_real_ip_from 0.0.0.0/0؛
• استفاده اشتباه از real_ip_recursive بدون شناخت Proxy Chain؛
• دوباره Append کردن IP کاربر به X-Forwarded-For پشت Cloudflare؛
• اصلاح Nginx ولی تنظیم نکردن Trusted Proxy در Application؛
• استفاده از Cloudflare و باز گذاشتن Origin برای دسترسی مستقیم؛
• فعال کردن PROXY Protocol در حالی که Load Balancer آن را ارسال نمی‌کند؛
• Reload کردن Nginx بدون اجرای nginx -t.

سؤالات متداول