ویونیکس
گفت‌وگو با کارشناس
← شروع آموزش

WIUNIX ACADEMY

آموزش نصب وردپرس با Nginx و کش FastCGI در اوبونتو و دبیان

صفحهٔ 4 از 4؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Ubuntu 26.04 LTSبررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

ویرایش 4 مقدار این آموزش
24

قدم بعدی

اثبات جداسازی محتوای رمزدار

برگهٔ locked-test در فهرست مجاز نیست. رمز آزمایشی آن را در مرورگر امن وارد و کوکی واقعی post-password را خصوصی صادر کنید. مهمان باید فرم را بدون متن محافظت‌شده ببیند؛ نشست دارای رمز متن را ببیند؛ مهمان تازه باز هم آن را نبیند. پیش از توسعهٔ تنظیمات، گردش خرید و حساب و افزونه‌های واقعی را با کاربران مجزا بسنجید. این آموزش WooCommerce نصب نمی‌کند و رفتار افزونهٔ دیگر را اثبات نمی‌کند.

Bash

کلاینت مجاز staging، Bash/curl؛ فایل کوکی خصوصی و محلی همان سیستم است.

(
set -euo pipefail
umask 077
work=$(mktemp -d)
base=https://blog.example.com
code=$(curl -sS --connect-timeout 5 --max-time 20 -D "$work/locked.h" -o "$work/locked.html" -w '%{http_code}' "$base/locked-test/")
[ "$code" = 200 ]
grep -Eiq '^X-WP-Cache: BYPASS[[:space:]]*$' "$work/locked.h"
grep -F 'post-password-form' "$work/locked.html"
if grep -Fq LOCKED_CONTENT_MARKER "$work/locked.html"; then
  echo 'Unexpected cached/private content or status' >&2; exit 1
else
  rc=$?; [ "$rc" = 1 ] || exit "$rc"
fi
# Existing private jar from entering this test post password in your browser.
jar=$HOME/wp-staging-postpass.cookies
[ -s "$jar" ]
chmod 0600 "$jar"
code=$(curl -sS --connect-timeout 5 --max-time 20 -b "$jar" -D "$work/unlocked.h" -o "$work/unlocked.html" -w '%{http_code}' "$base/locked-test/")
[ "$code" = 200 ]
grep -Eiq '^X-WP-Cache: BYPASS[[:space:]]*$' "$work/unlocked.h"
grep -F LOCKED_CONTENT_MARKER "$work/unlocked.html"
code=$(curl -sS --connect-timeout 5 --max-time 20 -D "$work/again.h" -o "$work/again.html" -w '%{http_code}' "$base/locked-test/")
[ "$code" = 200 ]
if grep -Fq LOCKED_CONTENT_MARKER "$work/again.html"; then
  echo 'Unexpected cached/private content or status' >&2; exit 1
else
  rc=$?; [ "$rc" = 1 ] || exit "$rc"
fi
)
از کجا بدانم درست انجام شد؟

همه BYPASS هستند و فقط نشست دارای رمز، نشانگر متن محافظت‌شده را می‌بیند.

25

قدم بعدی

بازکردن سایت آماده برای بازدیدکنندگان

پس از موفقیت نصب و آزمون‌های staging، فقط خطوط allow/deny موقتِ سطح server در HTTPS را حذف کنید. محافظت location برای تنظیمات و فایل مخفی و تمام قواعد bypass باقی بمانند. پنل قبلی اعتبارسنجی و reload را اجرا و از اتصال مستقل، پاسخ عمومی ۲۰۰ و ورود را بررسی کنید. کش بیرونی CDN نباید نتیجهٔ آزمون مبدأ را بپوشاند.

Bash

ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.

sudo nano /etc/nginx/sites-available/wordpress
از کجا بدانم درست انجام شد؟

سایت کامل HTTPS عمومی است؛ نشست و مسیر خصوصی همچنان کش نمی‌شوند.

آماده‌سازی hook تمدید

مسیر چالش HTTP حفظ شود. timer موجود بستهٔ Certbot مسئول تمدید است؛ زمان‌بند موازی نسازید. hook بعدی پیش از reload گواهی جدید، Nginx را اعتبارسنجی می‌کند.

Bash

ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.

sudo install -d -m 0755 /etc/letsencrypt/renewal-hooks/deploy
sudo nano /etc/letsencrypt/renewal-hooks/deploy/20-nginx-validated
از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

اعتبارسنجی استقرار گواهی تمدیدشده

این متن محتوای فایل است؛ آن را در نشست پوستهٔ نامرتبط اجرا نکنید.

Shell · /etc/letsencrypt/renewal-hooks/deploy/20-nginx-validated

محتوای فایل؛ در فایل مشخص‌شده ذخیره شود، نه در پوسته.

#!/bin/sh
set -eu
/usr/sbin/nginx -t
/bin/systemctl reload nginx
از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

26

قدم بعدی

آزمون تمدید و زمان‌بندی

اجرای مستقیم hook فقط پس از اعتبارسنجی reload می‌کند. dry-run با ACME آزمایشی ممکن است طول بکشد و معمولاً deploy hook را اجرا نمی‌کند؛ فراخوانی مستقیم، رفتار hook را جدا می‌سنجد.

Bash

ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.

(
set -euo pipefail
sudo chmod 0750 /etc/letsencrypt/renewal-hooks/deploy/20-nginx-validated
sudo /etc/letsencrypt/renewal-hooks/deploy/20-nginx-validated
sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot
)
از کجا بدانم درست انجام شد؟

hook و dry-run موفق‌اند و timer موجود زمان اجرا دارد.

بی‌اعتبارکردن کش بدون حذف فایل فعال

وجود API یا ماژول purge را فرض نمی‌کنیم. برای تغییر فوری، پیش از عوض‌شدن حریم صفحه، کش را خاموش یا URL را از فهرست حذف کنید؛ سپس نسل استفاده‌نشدهٔ پنل بعدی را بگذارید و اعتبارسنجی و reload کنید. کل سایت کوچک بی‌اعتبار می‌شود، نه یک URL. فایل قدیمی با کلید تازه خوانده نمی‌شود و با محدودیت حجم و زمان بی‌استفاده منقضی می‌شود. به نسل قدیمی برنگردید. انتشار عادی وردپرس این کش را پاک نمی‌کند؛ محتوا تا TTL واقعی می‌تواند بماند. در staging نشانگر را به PUBLIC_CACHE_MARKER_V2 عوض کنید، نسل تازه بدهید و آزمون مهمان را با نشانگر جدید تکرار کنید؛ متن قبلی نباید باشد.

Bash

ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.

sudo nano /etc/nginx/sites-available/wordpress
از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

تغییر نسل کلید کش

خط کلید قبلی را جایگزین کنید؛ خط تکراری اضافه نکنید. نسل قبلاً استفاده‌نشده باشد و سپس اعتبارسنجی و reload کنید.

Nginx · /etc/nginx/sites-available/wordpress (existing PHP location)

محتوای فایل؛ در فایل مشخص‌شده ذخیره شود، نه در پوسته.

# Replace the previous key directive with this NEW generation:
fastcgi_cache_key "$scheme|$request_method|$host|$request_uri|wp-v2";
از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

خاموش‌کردن کش با حفظ سایت

اگر کاربری محتوای دیگری را دید، با خط بعدی کش را فوراً خاموش و اعتبارسنجی و reload کنید. نسخه‌های CDN یا توزیع بیرونی را هم از روند مسئول آن بی‌اعتبار و دامنهٔ افشا را بررسی کنید. فایل وردپرس، دیتابیس، uploads، حساب و گواهی را حفظ کنید. پوشهٔ کش فعال حذف نشود.

Bash

ترمینال Bash سرور وردپرس، حساب مدیر دارای sudo.

sudo nano /etc/nginx/sites-available/wordpress
از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

27

قدم بعدی

بازگشت به PHP مستقیم بدون حذف داده

فقط خط انتخاب کش را جایگزین کنید؛ تا وجود ارجاع، zone بماند. پس از اعتبارسنجی و reload، بدنه و نشست باید درست باشند؛ این بار X-WP-Cache غایب است. پیش از فعال‌سازی دوباره سیاست را اصلاح و نسل تازه انتخاب کنید. فایل‌های قبلی می‌توانند عادی منقضی شوند.

Nginx · /etc/nginx/sites-available/wordpress (existing PHP location)

محتوای فایل؛ در فایل مشخص‌شده ذخیره شود، نه در پوسته.

# In the PHP location, replace WORDPRESS with off:
fastcgi_cache off;
از کجا بدانم درست انجام شد؟

وردپرس از PHP کار می‌کند؛ کش خاموش و همهٔ داده‌ها حفظ شده‌اند.

28

قدم بعدی

پشتیبان‌گیری پیش از نگه‌داری

مرحلهٔ اختیاری نگه‌داری: ابتدا از روند موجود برای توقف ویرایش محتوا، افزونه، تغییر ساختار و uploads استفاده کنید. dump برای InnoDB سازگاری تراکنشی دارد، اما فایل بارگذاری و جدول غیرتراکنشی افزونه را هم‌زمان نمی‌کند. تغییر درخت فایل، مقایسه را با خطا متوقف می‌کند. این پشتیبان اتمی آنلاین کل سایت نیست؛ پنجرهٔ نگه‌داری یا روند سازگار موجود لازم است. اصل فایل و داده باقی می‌ماند. checksum و خوانایی و مقایسهٔ محلی، قابلیت بازیابی SQL را اثبات نمی‌کند. پیش از بازنشستگی یا مهاجرت مخرب، در محیط بازیابی جدا restore و ورود و محتوا و uploads را بررسی و نسخهٔ رمزگذاری‌شدهٔ خارج از سرور نگه دارید. آزمون restore را روی دیتابیس زنده انجام ندهید. به‌روزرسانی مدیریتی هسته و افزونه از منابع رسمی منظم باشد و پس از آن آزمون حریم خصوصی تکرار شود.

Bash

ترمینال 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 مسیر اشتباه را درست نمی‌کند.

Bash
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
اتصال دیتابیس ناموفق است

ورود محلی، مجوز دیتابیس و خوانایی فایل را بدون چاپ رمز بررسی کنید.

Bash
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 عمومی را گرم کند.

Bash
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، دسترسی چالش و تطبیق گواهی را بررسی کنید؛ علت را اصلاح کنید و کنترل گواهی را دور نزنید.

Bash
getent ahosts blog.example.com
sudo nginx -t
sudo certbot certificates
sudo journalctl -u nginx -n 50 --no-pager

حفظ محدودهٔ روشن بهره‌برداری

ظرفیت PHP، فضای کش و inode و بازیابی تأییدشده را پایش کنید و فهرست مجاز کوچک بماند. object cache، CDN، چندسایتی، اشتراک و WooCommerce طراحی و آزمون گردش واقعی جدا می‌خواهند. HIT عمومی، صحت خرید یا امنیت ورود را ثابت نمی‌کند.

از کجا بدانم درست انجام شد؟

بررسی موفق است؛ در صورت خطا، پیش از ادامه علت را برطرف کنید.

پشتوانهٔ این آموزش

منابع رسمی

وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.

ادامهٔ مسیر

قدم بعدی تو

زیرساخت وب

راه‌اندازی Caddy و HTTPS خودکار، قدم‌به‌قدم

نسخهٔ لینوکس خودت را انتخاب کن؛ Caddy را نصب کن، برنامه را پشت reverse proxy قرار بده و HTTPS را با دستورهای قابل کپی و بررسی نتیجهٔ هر مرحله راه بینداز.

ادامهٔ آموزش ↗زیرساخت وب

راه‌اندازی Nginx با HTTP/3 و بررسی واقعی QUIC

از نصب Nginx تا اثبات HTTP/3 واقعی، قدم‌به‌قدم.

ادامهٔ آموزش ↗
همهٔ آموزش‌های آکادمی ↗