‫چالش‌های متداول توسعه‌دهندگان ASP.NET Core هنگام استفاده از Nginx - قسمت سوم - پیکربندی Nginx به عنوان Reverse Proxy

• /etc/nginx/sites-available/: تمام کانفیگ‌های سایت شما در این پوشه قرار می‌گیرند (چه فعال باشند چه غیرفعال).
• /etc/nginx/sites-enabled/: برای فعال کردن یک سایت، یک لینک نمادین (Symbolic Link) از فایل کانفیگ آن در sites-available به این پوشه ایجاد می‌کنیم.

sudo nano /etc/nginx/sites-available/kestrel-mywebapp

server {
    # به درخواست‌های HTTP روی پورت 80 گوش بده
    listen 80;
    listen [::]:80;

    # دامنه‌هایی که این کانفیگ برای آن‌ها اعمال می‌شود
    server_name your-domain.com www.your-domain.com;

    # بلاک اصلی برای Reverse Proxy
    location / {
        # آدرس سرویس ASP.NET Core ما
        proxy_pass         http://localhost:5000;
        
        # --- هدرهای ضروری برای حفظ اطلاعات کلاینت ---
        # ارسال هدر هاست اصلی به برنامه
        proxy_set_header   Host $host;
        # ارسال IP واقعی کلاینت به برنامه
        proxy_set_header   X-Real-IP $remote_addr;
        # ارسال لیست IP های پراکسی‌های مسیر (برای شناسایی IP اصلی)
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        # ارسال پروتکل اصلی (http یا https) به برنامه
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

• علامت: در لاگ‌های برنامه، تمام درخواست‌ها از طرف localhost ثبت می‌شوند. ویژگی‌هایی مانند محدود کردن درخواست بر اساس IP یا نمایش موقعیت جغرافیایی کاربر کار نمی‌کنند.
• علت: از دید Kestrel، تمام درخواست‌ها مستقیماً از Nginx (که روی همان سرور است) می‌آیند.
• راه‌حل: هدرهای X-Real-IP و X-Forwarded-Forproxy_set_header X-Real-IP $remote_addr;: این هدر، IP اصلی کاربر را در خود نگه می‌دارد.
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;: این هدر یک لیست از IPهایی است که درخواست از آن‌ها عبور کرده. فریم‌ورک ASP.NET Core به صورت خودکار از این هدر برای تشخیص IP واقعی کلاینت استفاده می‌کند.

• علامت: در برنامه از app.UseHttpsRedirection() استفاده کرده‌اید، اما یا کاربر در یک حلقه ریدایرکت بی‌پایان گیر می‌کند، یا لینک‌های تولید شده در صفحه (مثلاً در تگ‌های ) با http شروع می‌شوند و باعث خطای Mixed-Content در مرورگر می‌شوند.
• علت: ارتباط بین Nginx و Kestrel روی پروتکل HTTP (ناامن) انجام می‌شود. بنابراین، برنامه شما فکر می‌کند که درخواست اصلی نیز HTTP بوده است.
• راه‌حل: هدر X-Forwarded-Protoproxy_set_header X-Forwarded-Proto $scheme;: این هدر به برنامه اطلاع می‌دهد که پروتکل اصلی که کاربر استفاده کرده چه بوده است (http یا https که توسط متغیر $scheme در Nginx مشخص می‌شود). میدل‌ور ASP.NET Core با دیدن https در این هدر، متوجه می‌شود که ارتباط امن است و رفتار درستی از خود نشان می‌دهد.

• علامت: کاربر هنگام آپلود یک فایل نسبتاً بزرگ، با یک صفحه خطای سفید از طرف Nginx مواجه می‌شود.
• علت: Nginx به صورت پیش‌فرض یک محدودیت بسیار پایین (معمولاً 1 مگابایت) برای حجم بدنه درخواست (Request Body) دارد.
• راه‌حل: افزایش client_max_body_size این دستور را باید در بلاک server (خارج از location) اضافه کنید.

server {
    listen 80;
    server_name your-domain.com;

    # اجازه آپلود فایل تا حجم ۱۰۰ مگابایت
    client_max_body_size 100M;

    location / {
        # ... بقیه تنظیمات پراکسی
    }
}

server {
    # ... تنظیمات قبلی
    server_name your-domain.com;
    client_max_body_size 100M;

    # این بلاک برای فایل‌های استاتیک است
    location / {
        # ... تنظیمات پراکسی برای Kestrel
    }

    # این بلاک جدید، درخواست برای فایل‌های استاتیک را می‌گیرد
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg)$ {
        # مسیر پوشه wwwroot برنامه شما
        root /var/www/mywebapp/wwwroot;
        
        # تنظیم هدرهای کش در مرورگر کاربر (مثلا ۷ روز)
        expires 7d;
    }
}

sudo ln -s /etc/nginx/sites-available/kestrel-mywebapp /etc/nginx/sites-enabled/

sudo nginx -t

• اگر خروجی syntax is ok و test is successful را دیدید، همه چیز مرتب است.

sudo systemctl reload nginx