چگونه Nginx را برای وردپرس کانفیگ کنیم؟ ساختار امن، PHP-FPM و آزمون Production

کانفیگ Nginx برای وردپرس باید سه کار را درست انجام دهد: فایل static را مستقیم تحویل دهد، permalinkهای ناموجود را به front controller وردپرس بفرستد و فقط فایل PHP معتبر را به PHP-FPM تحویل دهد. بیشتر خطاهای 404، download شدن PHP، redirect loop یا 502 از اشتباه در root، location، socket یا headerهای proxy می‌آیند.

پاسخ سریع: document root و PHP-FPM socket واقعی همان سرور را پیدا کنید، یک server block جدا با server_name صحیح بسازید، برای وردپرس try_files تعریف کنید و مسیر PHP را به FPM بدهید. پیش از reload همیشه nginx -t، سپس با Host واقعی صفحه، permalink، login، upload و PHP را smoke test کنید.

قبل از نوشتن Config

• دامنه اصلی و aliasهای مجاز
• document root واقعی وردپرس
• user وب‌سرور و permission فایل‌ها
• نسخه فعال PHP-FPM و socket/port واقعی
• حد upload و timeout موردنیاز برنامه
• محل certificate و روش تمدید
• وجود CDN یا reverse proxy بالادست

مسیر socket را از سرویس فعال و config همان محیط بخوانید؛ نامی مثل php8.x-fpm.sock فقط placeholder است و نباید حدس زده شود.

یک اسکلت قابل تطبیق

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/PHP_FPM_SOCKET;
    }
}

دامنه، root و socket نمونه‌اند. قبل از استفاده آن‌ها را با واقعیت سرور جایگزین کنید. این اسکلت تمام نیازهای امنیت، TLS، cache یا multisite را پوشش نمی‌دهد و نقطه شروع است. فایل config فعلی را backup و تغییر را در staging یا virtual host آزمایشی تست کنید.

server_name و Default Server

دامنه‌های مجاز را صریح بنویسید. default server نباید درخواست هر Host ناشناخته را به وردپرس production تحویل دهد. canonical hostname را مشخص و alias را با redirect محدود به همان دامنه هدایت کنید. استفاده مستقیم از Host ارسالی کاربر در redirect می‌تواند مشکل امنیتی بسازد.

Document Root و مالکیت

root باید پوشه‌ای باشد که index.php وردپرس در آن قرار دارد. اشتباه یک سطحی می‌تواند 404 یا افشای ساختار ایجاد کند. وب‌سرور معمولاً به کد read و به upload از مسیر برنامه write نیاز دارد؛ کل tree را با 777 باز نکنید. deploy user و runtime user را آگاهانه جدا کنید.

Permalink با try_files

ترتیب بالا ابتدا فایل و directory واقعی را بررسی و سپس request را با query string به index.php می‌فرستد. اگر $args حذف یا rewrite اشتباه شود، جست‌وجو، preview یا پارامترهای برنامه آسیب می‌بینند. Nginx فایل .htaccess را نمی‌خواند؛ ruleهای plugin باید جدا ترجمه شوند.

ارسال امن PHP به PHP-FPM

SCRIPT_FILENAME باید به فایل واقعی map شود و fastcgi_pass به socket یا port فعال برسد. permission socket نیز باید با user Nginx سازگار باشد. اگر upstream وجود ندارد یا connection رد می‌شود، 502 رخ می‌دهد. socket را با حدس نسخه PHP تغییر ندهید.

جلوگیری از اجرای PHP ناخواسته

فقط routeهای لازم باید به PHP-FPM برسند. مسیر upload نباید محل اجرای script کاربر باشد. پیاده‌سازی rule به layout سایت و location precedence وابسته است؛ پس از اعمال، یک فایل آزمایشی بی‌خطر و درخواست مسیرهای ممنوع را بررسی کنید. صرف پسوند یا MIME در upload جای validation برنامه را نمی‌گیرد.

فایل‌های حساس و Hidden

دسترسی وب به فایل config، backup، dotfile، log و artifact deployment را مسدود کنید. rule فراگیر ممکن است مسیر well-known موردنیاز certificate را نیز ببندد، بنابراین exception لازم را آگاهانه طراحی کنید. secret نباید داخل document root نگهداری شود حتی اگر Nginx آن را block کند.

Upload Size و Timeout

client_max_body_size سقف request body در Nginx است، اما PHP و وردپرس نیز سقف خود را دارند. همه لایه‌ها را با نیاز واقعی هماهنگ کنید. سقف بسیار بزرگ بدون authentication و rate limit ریسک منابع دارد. افزایش timeout نیز پردازش کند را حل نمی‌کند و worker را بیشتر نگه می‌دارد.

FastCGI Timeout و Buffer

مقادیر پیش‌فرض ممکن است برای workload کافی باشند. تغییر buffer و timeout باید بر اساس response header/body و زمان PHP باشد، نه نسخه عمومی اینترنت. 504 را با timeout بی‌نهایت پنهان نکنید؛ Query، external API یا job طولانی را از request تعاملی خارج کنید.

فایل Static و Header Cache

تصویر، CSS و JavaScript نسخه‌دار می‌توانند cache طولانی‌تر داشته باشند، اما HTML، feed و فایل بدون fingerprint نیاز متفاوت دارند. rule extensionمحور ممکن است فایل dynamic یا asset بدون version را stale کند. cache policy را با deployment و invalidation هماهنگ کنید.

Page Cache وردپرس

Nginx می‌تواند در معماری‌های مختلف cache داشته باشد، اما cookie، login، preview، Cart و Checkout باید درست bypass شوند. پاسخ شخصی عمومی خطر حریم خصوصی دارد. پیش از فعال‌سازی hit/miss header، cache key، purge و failure behavior را طراحی کنید.

TLS و Redirect HTTPS

server block صدور/اعتبارسنجی گواهی و بلوک HTTPS را متناسب با ابزار خود طراحی کنید. زنجیره گواهی، hostname و تمدید را تست کنید. redirect به HTTPS باید loop نسازد، به‌ویژه پشت CDN. HSTS را فقط پس از آمادگی دامنه و زیردامنه‌ها فعال کنید.

پشت Reverse Proxy یا CDN

IP و scheme واقعی را فقط از proxyهای مورد اعتماد قبول کنید. اگر Nginx همیشه درخواست origin را HTTP تصور کند، وردپرس ممکن است redirect loop یا cookie ناامن بسازد. اعتماد به header از هر client امکان جعل IP و دور زدن ruleها را ایجاد می‌کند. فهرست proxyهای معتبر باید نگهداری شود.

WordPress Multisite

multisite subdirectory و subdomain rewrite و DNS متفاوت می‌خواهند. config تک‌سایت را کور استفاده نکنید. نوع network، upload path، domain mapping و cookie را طبق مستندات نسخه بررسی و همه سایت‌ها را تست کنید. تغییر معماری multisite در production پروژه جداست.

Log برای عیب‌یابی

access log باید host، status، upstream status، request time و upstream time لازم را بدون secret ثبت کند. error log سطح مناسبی داشته باشد و rotation مانع پر شدن disk شود. query string یا header حساس را بی‌دلیل log نکنید. request ID مشترک ارتباط Nginx و PHP را ساده می‌کند.

اعتبارسنجی و Reload

sudo nginx -t
sudo systemctl reload nginx
systemctl status nginx --no-pager

ابتدا از config backup بگیرید. فقط اگر syntax test موفق است reload کنید؛ reload معمولاً connectionهای موجود را graceful نگه می‌دارد، اما صحت منطقی route را تضمین نمی‌کند. session دوم SSH و rollback config را آماده نگه دارید.

Smoke Test بعد از Reload

• صفحه اصلی و یک permalink داخلی
• فایل CSS، تصویر و 404 واقعی
• ورود و خروج مدیر
• آپلود کنترل‌شده
• فرم، cron و REST API لازم
• HTTPS، canonical redirect و دامنه alias
• Cart، Checkout و callback برای فروشگاه

بررسی Performance

قبل و بعد، TTFB، p95، status، CPU، memory، PHP queue و upstream time را با سناریوی ثابت مقایسه کنید. سریع شدن static file ثابت نمی‌کند PHP یا Checkout سریع شده است. اگر bottleneck در PHP-FPM است، راهنمای تنظیم PHP-FPM را دنبال کنید.

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

• حدس زدن PHP socket
• کپی config بدون تطبیق root
• انتظار اثر از .htaccess
• reload بدون nginx -t
• cache کردن صفحه شخصی
• اعتماد به header proxy از همه
• timeout بسیار بزرگ برای پنهان کردن کندی
• مجوز 777 برای حل 403

Nginx یا Apache؟

اگر هنوز انتخاب انجام نشده، مقایسه Nginx و Apache را بر اساس سازگاری، عملیات و workload بخوانید. مهاجرت صرفاً برای ادعای سرعت، بدون benchmark و تبدیل ruleها، ممکن است خطاهای بیشتری بسازد.

چه زمانی کمک تخصصی لازم است؟

اگر سایت فروشگاهی، multisite، CDN یا rule امنیتی پیچیده دارد، config عمومی کافی نیست و خطا می‌تواند login یا پرداخت را قطع کند. نصب و کانفیگ سرور لینوکس می‌تواند Nginx، PHP-FPM، TLS، log و rollback را بر اساس معماری واقعی تنظیم کند.

پرسش‌های متداول

چرا بعد از نصب Nginx لینک‌های داخلی 404 هستند؟

معمولاً front-controller rewrite یا try_files ناقص است؛ root و config فعال را بررسی کنید.

چرا فایل PHP دانلود می‌شود؟

PHP handler فعال نیست یا request به FPM ارسال نمی‌شود. سایت را فوراً از exposure خارج و config را اصلاح کنید.

چرا Nginx خطای 502 می‌دهد؟

socket/port، permission، وضعیت PHP-FPM و log upstream را بررسی کنید؛ نام socket را حدس نزنید.

آیا باید Config آماده اینترنت را کپی کنم؟

خیر؛ root، نسخه، socket، proxy و نیاز امنیتی متفاوت است. از آن فقط برای فهم الگو استفاده کنید.