تنظیمات را عوض کرده‌ای و می‌خواهی بدون قطع اتصال‌های جاری اعمالش کنی. ترتیب درست؟
sudo systemctl restart nginx sudo systemctl stop nginx && sudo systemctl start nginx sudo nginx -t و اگر موفق بود sudo systemctl reload nginx sudo kill -9 $(pidof nginx)
reload پروسه‌ی master را نگه می‌دارد و workerهای قدیمی درخواست‌های جاری را تمام می‌کنند.
جواب درست: sudo nginx -t و اگر موفق بود sudo systemctl reload nginx — reload پروسه‌ی master را نگه می‌دارد و workerهای قدیمی درخواست‌های جاری را تمام می‌کنند.
بعد از نصب Nginx روی سرور تازه، از بیرون صفحه باز نمی‌شود ولی curl localhost روی خود سرور کار می‌کند. اولین چیزی که بررسی می‌کنی؟
نسخه‌ی Nginx فایل index.html فایروال (sudo ufw status) و باز بودن پورت ۸۰ و ۴۴۳ لاگ دسترسی
وقتی محلی کار می‌کند، مشکل بین اینترنت و سرور است.
جواب درست: فایروال (sudo ufw status) و باز بودن پورت ۸۰ و ۴۴۳ — وقتی محلی کار می‌کند، مشکل بین اینترنت و سرور است.
فایل سایت را در sites-available ساختی ولی Nginx آن را نمی‌بیند. چه کم است؟
لینک در sites-enabled (ln -s) و reload restart chmod 777 نام فایل باید .conf باشد
nginx.conf در Ubuntu فقط sites-enabled/* را include می‌کند.
جواب درست: لینک در sites-enabled (ln -s) و reload — nginx.conf در Ubuntu فقط sites-enabled/* را include می‌کند.
دو سایت روی یک سرور داری و درخواست به دامنه‌ای که هیچ server_name ای ندارد می‌رسد. کدام server جواب می‌دهد؟
هیچ‌کدام؛ ۴۰۴ تصادفی آخرین فایل الفبایی server ای که default_server دارد، و اگر نباشد اولین server روی آن پورت
برای همین یک default_server با return 444 تمیزترین کار است.
جواب درست: server ای که default_server دارد، و اگر نباشد اولین server روی آن پورت — برای همین یک default_server با return 444 تمیزترین کار است.
برای درخواست /images/logo.png، کدام location برنده است: location / ، location /images/ ، location ~ \.png$ ؟
location / location ~ \.png$ (regex بعد از پیشوندی بلندتر بررسی می‌شود و اگر جور شد برنده است) location /images/ اولین در فایل
مگر اینکه location /images/ با ^~ نوشته شده باشد.
جواب درست: location ~ \.png$ (regex بعد از پیشوندی بلندتر بررسی می‌شود و اگر جور شد برنده است) — مگر اینکه location /images/ با ^~ نوشته شده باشد.
تفاوت root /var/www/site; و alias /var/www/files/; در location /static/ برای /static/a.css؟
هیچ root: /var/www/site/a.css؛ alias: /var/www/files/static/a.css alias فقط برای regex است root: /var/www/site/static/a.css؛ alias: /var/www/files/a.css
root مسیر location را اضافه می‌کند؛ alias جایگزینش می‌کند.
جواب درست: root: /var/www/site/static/a.css؛ alias: /var/www/files/a.css — root مسیر location را اضافه می‌کند؛ alias جایگزینش می‌کند.
سایت تک‌صفحه‌ای (React) با رفرش روی /dashboard ۴۰۴ می‌دهد. راه‌حل؟
error_page 404 =200 try_files $uri $uri/ /index.html; rewrite ^ /index.html permanent; autoindex on
مسیرهای اپ وجود فیزیکی ندارند؛ همه باید به index.html برسند.
جواب درست: try_files $uri $uri/ /index.html; — مسیرهای اپ وجود فیزیکی ندارند؛ همه باید به index.html برسند.
می‌خواهی ۱۰ IP پرتکرار امروز را از لاگ دربیاوری. کدام؟
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head grep -c IP access.log tail -n 10 access.log cat error.log | head
sort قبل از uniq لازم است چون uniq فقط تکرارهای پشت‌سرهم را می‌شمارد.
جواب درست: awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head — sort قبل از uniq لازم است چون uniq فقط تکرارهای پشت‌سرهم را می‌شمارد.
صفحه‌ای ۴۰۳ می‌دهد. error.log می‌گوید «Permission denied». محتمل‌ترین علت؟
server_name کاربر www-data اجازه‌ی خواندن فایل یا عبور (x) از یکی از پوشه‌های مسیر را ندارد gzip ریدایرکت
namei -l مسیر را پوشه‌به‌پوشه نشان می‌دهد.
جواب درست: کاربر www-data اجازه‌ی خواندن فایل یا عبور (x) از یکی از پوشه‌های مسیر را ندارد — namei -l مسیر را پوشه‌به‌پوشه نشان می‌دهد.
اپ Node پشت Nginx IP همه را 127.0.0.1 می‌بیند و لینک‌های ایمیل به http://127.0.0.1:3000 اشاره می‌کنند. چه کم است؟
proxy_buffering keepalive proxy_set_header برای Host، X-Real-IP، X-Forwarded-For و X-Forwarded-Proto (یا include proxy_params) listen 3000
و اپ باید به proxy اعتماد کند تا این هدرها را بخواند.
جواب درست: proxy_set_header برای Host، X-Real-IP، X-Forwarded-For و X-Forwarded-Proto (یا include proxy_params) — و اپ باید به proxy اعتماد کند تا این هدرها را بخواند.
فرق ۵۰۲ و ۵۰۴ پشت proxy؟
هیچ ۵۰۲: timeout؛ ۵۰۴: اپ خاموش ۵۰۲: اتصال به اپ ناموفق (خاموش یا پورت اشتباه)؛ ۵۰۴: اپ وصل است ولی در proxy_read_timeout جواب نداد هر دو یعنی Nginx خراب است
error log: connect() failed (111) در برابر upstream timed out (110).
جواب درست: ۵۰۲: اتصال به اپ ناموفق (خاموش یا پورت اشتباه)؛ ۵۰۴: اپ وصل است ولی در proxy_read_timeout جواب نداد — error log: connect() failed (111) در برابر upstream timed out (110).
location /api/ با proxy_pass http://127.0.0.1:3000/; درخواست /api/users را چطور به اپ می‌فرستد؟
/api/users /users /api/ //users
با مسیر در proxy_pass (حتی فقط /)، بخش جورشدهی location جایگزین می‌شود.
جواب درست: /users — با مسیر در proxy_pass (حتی فقط /)، بخش جورشدهی location جایگزین می‌شود.
چت WebSocket پشت Nginx دست‌دادن را با ۴۰۰ رد می‌کند. کدام سه خط کم است؟
gzip off; sendfile off; tcp_nodelay on; listen 443 ssl; ssl_certificate; ssl_certificate_key; keepalive 16; zone ws 64k; least_conn; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
Upgrade و Connection هدرهای hop-by-hop هستند و خودبه‌خود منتقل نمی‌شوند.
جواب درست: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; — Upgrade و Connection هدرهای hop-by-hop هستند و خودبه‌خود منتقل نمی‌شوند.
certbot برای صدور گواهی با چالش HTTP-01 به چه چیزی نیاز دارد؟
پورت ۲۲ باز دامنه به IP سرور اشاره کند و پورت ۸۰ از اینترنت باز باشد گواهی قبلی Nginx خاموش باشد
CA به http://دامنه/.well-known/acme-challenge/TOKEN سر می‌زند.
جواب درست: دامنه به IP سرور اشاره کند و پورت ۸۰ از اینترنت باز باشد — CA به http://دامنه/.well-known/acme-challenge/TOKEN سر می‌زند.
سه ماه بعد سایت با «گواهی منقضی شده» باز شد. کدام کار از اول جلویش را می‌گرفت؟
گواهی ۳۶۵ روزه restart ماهانه sudo certbot renew --dry-run بعد از نصب و اطمینان از certbot.timer و باز ماندن پورت ۸۰ HSTS
تمدید از همان مسیر چالش HTTP-01 انجام می‌شود.
جواب درست: sudo certbot renew --dry-run بعد از نصب و اطمینان از certbot.timer و باز ماندن پورت ۸۰ — تمدید از همان مسیر چالش HTTP-01 انجام می‌شود.
هدرهای امنیتی روی صفحه‌ی ۴۰۴ نیستند ولی روی ۲۰۰ هستند. چه چیزی جا افتاده؟
server_tokens off پارامتر always در add_header include proxy_params listen 443
بدون always فقط کدهای ۲۰۰، ۲۰۱، ۲۰۴، ۲۰۶، ۳۰۱، ۳۰۲، ۳۰۳، ۳۰۴، ۳۰۷ و ۳۰۸.
جواب درست: پارامتر always در add_header — بدون always فقط کدهای ۲۰۰، ۲۰۱، ۲۰۴، ۲۰۶، ۳۰۱، ۳۰۲، ۳۰۳، ۳۰۴، ۳۰۷ و ۳۰۸.
در یک location، add_header Cache-Control گذاشتی و HSTS و CSP آن صفحه ناپدید شدند. چرا؟
هر سطحی که add_header داشته باشد، add_header های سطح بالاتر را به ارث نمی‌برد Cache-Control با HSTS تداخل دارد باید reload کامل کرد HSTS فقط روی صفحه‌ی اصلی است
snippet هدرهای امنیتی را در آن location هم include کن.
جواب درست: هر سطحی که add_header داشته باشد، add_header های سطح بالاتر را به ارث نمی‌برد — snippet هدرهای امنیتی را در آن location هم include کن.
HSTS با includeSubDomains و max-age یک‌ساله گذاشتی و intranet.example.com فقط HTTP دارد. نتیجه؟
هیچ کاربرانی که هدر را دیده‌اند تا یک سال intranet را نمی‌توانند با HTTP باز کنند intranet سریع‌تر می‌شود مرورگر هشدار نمی‌دهد
HSTS را با max-age کوتاه شروع کن و اول همه‌ی زیردامنه‌ها را HTTPS کن.
جواب درست: کاربرانی که هدر را دیده‌اند تا یک سال intranet را نمی‌توانند با HTTP باز کنند — HSTS را با max-age کوتاه شروع کن و اول همه‌ی زیردامنه‌ها را HTTPS کن.
CSS سایت ۸۴ کیلوبایت است و با gzip ۱۸ کیلوبایت می‌شود، ولی روی سرور Ubuntu فشرده نمی‌آید. چه اضافه می‌کنی؟
gzip_types text/css application/javascript ...; gzip on; gzip_static on; expires 1y;
gzip on در Ubuntu روشن است ولی پیشفرض gzip_types فقط text/html است.
جواب درست: gzip_types text/css application/javascript ...; — gzip on در Ubuntu روشن است ولی پیشفرض gzip_types فقط text/html است.
بعد از هر دیپلوی، بعضی کاربرها تا یک ماه نسخه‌ی قدیمی سایت را می‌بینند. محتمل‌ترین اشتباه؟
gzip HTTP/2 HSTS HTML یا فایل بدون hash کش طولانی (expires 30d) دارد
HTML: no-cache؛ کش طولانی فقط برای اسم‌های hashدار.
جواب درست: HTML یا فایل بدون hash کش طولانی (expires 30d) دارد — HTML: no-cache؛ کش طولانی فقط برای اسم‌های hashدار.
در upstream سه سرور داری و بارها نامتوازن پخش می‌شود. اولین خطی که اضافه می‌کنی؟
weight=1 zone backend 64k; backup ip_hash
بدون zone هر worker شمارنده و وضعیت سلامت جدا دارد.
جواب درست: zone backend 64k; — بدون zone هر worker شمارنده و وضعیت سلامت جدا دارد.
اپ سبد خرید را در حافظه‌ی پروسه نگه می‌دارد و با round robin سبد کاربرها «گم و پیدا» می‌شود. بهترین راه‌حل بلندمدت؟
ip_hash یک سرور کافی است least_conn نگه‌داشتن session در انباره‌ی مشترک (Redis یا دیتابیس) تا هر سروری هر درخواستی را جواب دهد
چسبندگی (hash) وصله است: اگر سرور کاربر بمیرد، session به‌هرحال می‌رود.
جواب درست: نگه‌داشتن session در انباره‌ی مشترک (Redis یا دیتابیس) تا هر سروری هر درخواستی را جواب دهد — چسبندگی (hash) وصله است: اگر سرور کاربر بمیرد، session به‌هرحال می‌رود.
یکی از اعضای upstream خاموش است و max_fails=2 fail_timeout=10s. در error log چه می‌بینی و کاربر چه؟
کاربر ۵۰۲؛ لاگ خالی کاربر ۵۰۴؛ upstream timed out Nginx متوقف می‌شود کاربر ۲۰۰ (درخواست به عضو بعدی رفت)؛ در لاگ چند خط connect() failed و سرور خراب ۱۰ ثانیه کنار می‌رود
اگر همه خراب باشند: ۵۰۲ و no live upstreams.
جواب درست: کاربر ۲۰۰ (درخواست به عضو بعدی رفت)؛ در لاگ چند خط connect() failed و سرور خراب ۱۰ ثانیه کنار می‌رود — اگر همه خراب باشند: ۵۰۲ و no live upstreams.
ربات‌ها روزی ده‌ها هزار رمز روی /login امتحان می‌کنند. کدام تنظیم؟
limit_conn login 5; deny all; proxy_read_timeout 1s; limit_req_zone ... rate=5r/m; و در location = /login: limit_req zone=login burst=4 nodelay; + limit_req_status 429;
۵ تلاش فوری و بعد یکی هر ۱۲ ثانیه؛ بقیه‌ی سایت آزاد.
جواب درست: limit_req_zone ... rate=5r/m; و در location = /login: limit_req zone=login burst=4 nodelay; + limit_req_status 429; — ۵ تلاش فوری و بعد یکی هر ۱۲ ثانیه؛ بقیه‌ی سایت آزاد.
پشت یک CDN هستی و با اولین هجوم همه‌ی کاربرها ۴۲۹ می‌گیرند. علت؟
rate کم است nodelay لازم است $binary_remote_addr برای همه IP CDN است؛ همه یک سطل مشترک دارند. IP واقعی را با realip بازیابی کن zone کوچک است
set_real_ip_from و real_ip_header X-Forwarded-For.
جواب درست: $binary_remote_addr برای همه IP CDN است؛ همه یک سطل مشترک دارند. IP واقعی را با realip بازیابی کن — set_real_ip_from و real_ip_header X-Forwarded-For.
می‌خواهی محدودیت جدید را روی سایت واقعی امتحان کنی بی‌آنکه کسی رد شود. کدام؟
limit_req_status 200; burst=100000 limit_req_dry_run on; و بررسی خط‌های dry run در error log limit_req off;
چند روز dry run، بعد تنظیم rate و burst، بعد روشن کردن واقعی.
جواب درست: limit_req_dry_run on; و بررسی خط‌های dry run در error log — چند روز dry run، بعد تنظیم rate و burst، بعد روشن کردن واقعی.
Nginx در Compose با «host not found in upstream "api:8080"» خارج می‌شود و کل سایت پایین است. راه‌حلی که سایت را بالا نگه دارد؟
depends_on restart: always resolver 127.0.0.11 valid=5s; و upstream با zone و server api:8080 resolve; (یا proxy_pass با متغیر) links:
آن وقت Nginx بالا می‌آید و فقط /api/ تا برگشتن سرویس ۵۰۲ می‌دهد.
جواب درست: resolver 127.0.0.11 valid=5s; و upstream با zone و server api:8080 resolve; (یا proxy_pass با متغیر) — آن وقت Nginx بالا می‌آید و فقط /api/ تا برگشتن سرویس ۵۰۲ می‌دهد.
در داکر، کدام دستور تنظیمات را بدون ریستارت کانتینر اعمال می‌کند؟
docker compose restart nginx docker compose up -d --force-recreate docker compose exec nginx nginx -s reload (بعد از nginx -t) docker kill nginx
restart کانتینر را کامل متوقف و اجرا می‌کند و اتصال‌ها قطع می‌شوند.
جواب درست: docker compose exec nginx nginx -s reload (بعد از nginx -t) — restart کانتینر را کامل متوقف و اجرا می‌کند و اتصال‌ها قطع می‌شوند.
در استقرار، نسخه‌ی جدید خراب بود. با ساختار releases/ و symlink current، برگشت چقدر طول می‌کشد؟
به اندازه‌ی build دوباره باید از بکاپ بازگردانی کرد یک لحظه: symlink را به نسخه‌ی قبلی برگردان (ln -sfn + mv -T) reload کامل لازم است
برای همین نسخه‌ی قبلی هیچ‌وقت پاک نمی‌شود.
جواب درست: یک لحظه: symlink را به نسخه‌ی قبلی برگردان (ln -sfn + mv -T) — برای همین نسخه‌ی قبلی هیچ‌وقت پاک نمی‌شود.
nginx -t موفق است. آیا یعنی سایت درست کار می‌کند؟
نه؛ فقط syntax و فایل‌ها را می‌سنجد. رفتار (ریدایرکت، هدرها، کش، محدودیت) را با یک اسکریپت بررسی مثل shop-check بعد از هر تغییر بسنج و error log را بعد از reload ببین بله، همیشه فقط اگر reload هم موفق باشد فقط برای HTTPS نه
مثلاً عوض شدن کلید یک zone از nginx -t رد می‌شود ولی reload را بی‌صدا شکست می‌دهد.
جواب درست: نه؛ فقط syntax و فایل‌ها را می‌سنجد. رفتار (ریدایرکت، هدرها، کش، محدودیت) را با یک اسکریپت بررسی مثل shop-check بعد از هر تغییر بسنج و error log را بعد از reload ببین — مثلاً عوض شدن کلید یک zone از nginx -t رد می‌شود ولی reload را بی‌صدا شکست می‌دهد.
