WIUNIX ACADEMY
آموزش نصب وردپرس با Nginx و کش FastCGI در اوبونتو و دبیان
صفحهٔ 7 از 8؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من4 مقدار قابل‌تغییر
بی‌اعتبارکردن کش بدون حذف فایل فعال
وجود API یا ماژول purge را فرض نمی‌کنیم. برای تغییر فوری، پیش از عوض‌شدن حریم صفحه، کش را خاموش یا URL را از فهرست حذف کنید؛ سپس نسل استفاده‌نشدهٔ پنل بعدی را بگذارید و اعتبارسنجی و reload کنید. کل سایت کوچک بی‌اعتبار می‌شود، نه یک URL. فایل قدیمی با کلید تازه خوانده نمی‌شود و با محدودیت حجم و زمان بی‌استفاده منقضی می‌شود. به نسل قدیمی برنگردید. انتشار عادی وردپرس این کش را پاک نمی‌کند؛ محتوا تا TTL واقعی می‌تواند بماند. در staging نشانگر را به PUBLIC_CACHE_MARKER_V2 عوض کنید، نسل تازه بدهید و آزمون مهمان را با نشانگر جدید تکرار کنید؛ متن قبلی نباید باشد.
ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.
sudo nano /etc/nginx/sites-available/wordpress
بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.
تغییر نسل کلید کش
خط کلید قبلی را جایگزین کنید؛ خط تکراری اضافه نکنید. نسل قبلاً استفاده‌نشده باشد و سپس اعتبارسنجی و reload کنید.
محتوای فایل؛ در فایل مشخص‌شده ذخیره شود، نه در پوسته.
# Replace the previous key directive with this NEW generation:
fastcgi_cache_key "$scheme|$request_method|$host|$request_uri|wp-v2";
بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.
خاموش‌کردن کش با حفظ سایت
اگر کاربری محتوای دیگری را دید، با خط بعدی کش را فوراً خاموش و اعتبارسنجی و reload کنید. نسخه‌های CDN یا توزیع بیرونی را هم از روند مسئول آن بی‌اعتبار و دامنهٔ افشا را بررسی کنید. فایل وردپرس، دیتابیس، uploads، حساب و گواهی را حفظ کنید. پوشهٔ کش فعال حذف نشود.
ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.
sudo nano /etc/nginx/sites-available/wordpress
بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.
قدم بعدی
بازگشت به PHP مستقیم بدون حذف داده
فقط خط انتخاب کش را جایگزین کنید؛ تا وجود ارجاع، zone بماند. پس از اعتبارسنجی و reload، بدنه و نشست باید درست باشند؛ این بار X-WP-Cache غایب است. پیش از فعال‌سازی دوباره سیاست را اصلاح و نسل تازه انتخاب کنید. فایل‌های قبلی می‌توانند عادی منقضی شوند.
محتوای فایل؛ در فایل مشخص‌شده ذخیره شود، نه در پوسته.
# In the PHP location, replace WORDPRESS with off:
fastcgi_cache off;
وردپرس از PHP کار می‌کند؛ کش خاموش و همهٔ داده‌ها حفظ شده‌اند.
قدم بعدی
پشتیبان‌گیری پیش از نگهداری
مرحلهٔ اختیاری نگهداری: ابتدا از روند موجود برای توقف ویرایش محتوا، افزونه، تغییر ساختار و uploads استفاده کنید. dump برای InnoDB سازگاری تراکنشی دارد، اما فایل بارگذاری و جدول غیرتراکنشی افزونه را هم‌زمان نمی‌کند. تغییر درخت فایل، مقایسه را با خطا متوقف می‌کند. این پشتیبان اتمی آنلاین کل سایت نیست؛ پنجرهٔ نگهداری یا روند سازگار موجود لازم است. اصل فایل و داده باقی می‌ماند. checksum و خوانایی و مقایسهٔ محلی، قابلیت بازیابی SQL را اثبات نمی‌کند. پیش از بازنشستگی یا مهاجرت مخرب، در محیط بازیابی جدا restore و ورود و محتوا و uploads را بررسی و نسخهٔ رمزگذاری‌شدهٔ خارج از سرور نگه دارید. آزمون restore را روی دیتابیس زنده انجام ندهید. به‌روزرسانی مدیریتی هسته و افزونه از منابع رسمی منظم باشد و پس از آن آزمون حریم خصوصی تکرار شود.
ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.
sudo sh -eu <<'BACKUP'
umask 077
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/wordpress-XXXXXXXX)
mariadb-dump --single-transaction --quick --databases wordpress > "$backup/wordpress.sql"
test -s "$backup/wordpress.sql"
tar -C / -cpf "$backup/wordpress-files.tar" var/www/wordpress etc/nginx/sites-available/wordpress etc/nginx/conf.d/wordpress-cache.conf etc/php/8.5/fpm/pool.d/wordpress.conf
cd "$backup"
sha256sum wordpress.sql wordpress-files.tar > SHA256SUMS
sha256sum -c SHA256SUMS
tar -tf wordpress-files.tar >/dev/null
tar -C / -df wordpress-files.tar
printf 'Verified local files and dump: %s\n' "$backup"
BACKUP
آرشیو و dump خصوصی از کنترل محلی عبور می‌کنند و اصل داده حفظ می‌شود؛ آزمون restore جدا لازم است.
عیب‌یابی در مرز خطا
گزارش خصوصی و کوکی محلی بماند. هر بخش، پنل تشخیصی اجرایی جدا دارد.
بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.
PHP پاسخ ۵۰۲ می‌دهد
سوکت واقعی، سرویس نسخهٔ انتخابی و مجوز را مقایسه کنید؛ restart مسیر اشتباه را درست نمی‌کند.
sudo nginx -t
sudo systemctl status php8.5-fpm --no-pager
sudo journalctl -u php8.5-fpm -n 50 --no-pager
sudo stat /run/php/wordpress.sock
sudo -u www-data test -w /run/php/wordpress.sockاتصال دیتابیس ناموفق است
ورود محلی، مجوز دیتابیس و خوانایی فایل را بدون چاپ رمز بررسی کنید.
sudo systemctl status mariadb --no-pager
sudo journalctl -u mariadb -n 50 --no-pager
mariadb -u wp_site -p wordpress -e 'SELECT 1;'
sudo -u wp-php test -r /var/www/wordpress/wp-config.phpنبود HIT یا بدنهٔ اشتباه
برای بدنهٔ غلط ابتدا کش را خاموش کنید. کوکی، پارامتر یا هدر خصوصی می‌تواند به‌درستی مانع ذخیره شود. حجم و inode را ببینید؛ برای HIT هدر را حذف نکنید. درخواست ممکن است URL عمومی را گرم کند.
sudo nginx -t
sudo df -h /var/cache/nginx/wordpress
sudo df -i /var/cache/nginx/wordpress
sudo du -sh /var/cache/nginx/wordpress
curl -sS --connect-timeout 5 --max-time 20 -D - -o /dev/null https://blog.example.com/sample-page/خطای TLS یا تمدید
DNS، دسترسی چالش و تطبیق گواهی را بررسی کنید؛ علت را اصلاح کنید و کنترل گواهی را دور نزنید.
getent ahosts blog.example.com
sudo nginx -t
sudo certbot certificates
sudo journalctl -u nginx -n 50 --no-pager