۱۶ راهکار تضمینی برای رفع خطای متداول وب سرور انجینکس

انجینیکس یکی از محبوب‌ترین وب‌سرورها در جهان است. این وب‌سرور یک سری خطاهای رایج و ارورهای متداول دارد که ممکن است شما را با مشکل مواجه کند. در این مقاله قصد داریم روش مرتفع کردن ارورهای متداول از وب‌سرور انجینیکس را به شما آموزش دهیم.

توجه داشته باشید که این فهرست کامل نیست و راه‌حل‌های گفته شد به احتمال زیاد مشکل شما را برطرف خواهند کرد. در صورتی که نتوانستید مشکلات وب‌سرور Nginx خود را با استفاده از این راه‌حل‌ها برطرف کنید، باید به دنبال روش‌های دیگر باشید.

وب‌سرور انجینیکس چیست؟

انجینیکس جزء دو وب‌سرور قدرتمند و پرکاربر در جهان است. در صورتی که بتوانید پیکربندی را درست انجام دهید، می‌توانید از کاربردهای این وب‌سرور پرطرفدار بهره بگیرید.

وب‌سرور انجینیکس به صورت اپن سورس یا همان متن باز طراحی شده و قابلیت‌های فراوانی دارد. به طور کلی، کاربران زیادی در حال استفاده از آن هستند و بسیاری از کارهایشان را به وسیله این وب‌سرور انجام می‌دهند.

Nginx بر روی سیستم عامل‌های مختلفی اجرا می‌شود و همین مسئله نیز بر محبوبیت این وب‌سرور افزوده است. به دلیل استفاده کم از منابع و البته پایداری بالا، این وب‌سرور را می‌توان جزء مشهورترین‌ها هم دانست.

برای رفع خطای متداول وب سرور انجینکس باید مانند یک ناخدای کشتی باشید، ابتدا علت خطای ایجادشده را پیدا و بهترین و ساده‌ترین راهکار را برای آن به‌کار بگیرید. نگران نباشید! خطاهای انجین‌ایکس با یک خط کد یا با چند کلیک رفع می‌شوند و باز هم می‌توانید با سرعت بالایی میزبان بازدیدکننده‌های زیادی باشید.

1. خطای Unable to connect/Refused to Connect در انجینکس

اگر هنگام تلاش برای دسترسی به وب‌سایت خود با خطاهای زیر مواجه شدید:

Firefox can’t establish a connection to the server at www.example.com

 

www.example.com refused to connect

 

The site can't be reached, www.example.com unexpectedly closed the connection

رفع مشکل unable to connect در فایرفاکس

به احتمال زیاد می‌توان با راه‌حل‌های زیر مشکل را برطرف کرد.

1. Nginx isn’t running

در این شرایط می‌توانید وضعیت انجینیکس را با sudo systemctl status nginx بررسی کنید. برای این کار ابتدا Nginx را با

sudo systemctl start nginx

شروع کنید.

در صورتی که انجینیکس شروع به کار نکرد.

sudo nginx -t

را اجرا کنید. ببینید آیا مشکلی در فایل پیکربندی‌ شما وجود دارد یا خیر.

2. Firewall blocking ports 80 and 443

اگر از فایروال UFW در Debian/Ubuntu استفاده می‌کنید، اجازه دهید تا

sudo ufw allow 80,443/tcp

پورت‌های TCP 80 و 443 را باز نماید.

در صورتی که از فایروالد در RHEL/CentOS/Rocky Linux/AlmaLinux استفاده می‌کنید،

sudo firewall-cmd --permanent --add-service={http,https}

را اجرا کنید.

و سپس

sudo systemctl reload firewalld

را اجرا کنید تا پورت‌های TCP 80 و 443 باز شوند.

3. Fail2ban

اگر سرور شما از fail2ban برای مسدود کردن درخواست‌های مخرب استفاده می‌کند، ممکن است fail2ban آدرس IP شما را بن کرده باشد.

در چنین حالتی

sudo journalctl -eu fail2ban

را اجرا کنید. این کار برای بررسی بن بودن IP شما انجام خواهد شد. می‌توانید آدرس IP خود را به لیست fail2ban ignoreip اضافه کنید، بنابراین IP شما دوباره ban نخواهد شد.

4. Nginx isn’t listening on the right network interface

به عنوان مثال، Nginx به پابلیک‌آ‌یدی سرور گوش نمی‌دهد.

2. خطای انجینکس The Connection Has Timed Out

اگر به چنین اروری برخورد کردید، باید بدانید که یا سرور شما آفلاین است و یا انجینیکس به درستی کار نمی‌کند. کمبود حافظه می‌تواند یکی از اصلی‌ترین دلایل به وجود آمدن این ارور باشد.

در صورتی که پیام ارور زیر را در فایل /var/log/nginx/error.log خود مشاهده کردید، بدانید که سرورتان با کمبود حافظه مواجه است:

fork() failed while spawning "worker process" (12: Cannot allocate memory)

3. خطای 404Not Found در انجینکس

404Not Found به این معنی است که انجینیکس نمی‌تواند منابع درخواستی توسط مرورگر وب‌ را پیدا کند. به طور کلی این ارور به دلایل زیر رخ می‌دهد:

1. web root directory بر روی سرور شما وجود ندارد.

در Nginx، دایرکتوری web root با استفاده از دستور root پیکربندی می‌شود، مانند: root /usr/share/nginx/linuxbabe.com/; در این شرایط باید اطمینان پیدا کنید که فایل‌های وب‌سایت شما (HTML، CSS، جاوا اسکریپت، PHP) در دایرکتوری صحیح ذخیره شده‌اند.

2. PHP-FPM در حال اجرا نیست.

در این شرایط شما می‌توانید وضعیت PHP-FPM خود را با استفاده از

sudo systemctl status php7.4-fpm

(کد بالا در اوبونتو و دبیان کاربرد دارد) و یا

sudo systemctl status php-fpm

بررسی کنید.

3. فراموش کرده‌ا‌ید که کد زیر را وارد کنید؛

این یک دستورالعمل در فایل پیکربندی سرور شما است و برای پردازش کد PHP مورد نیاز خواهد بود.

try_files $uri /index.php$is_args$args;

4. سرور شما فضای خالی دیسک ندارد.

در این شرایط باید مقداری از فضای دیسک را آزاد کنید. برای انجام این کار از ابزار ncdu:

sudo apt install ncdu

یا

sudo dnf install ncdu

استفاده نمایید تا بفهمید کدام دایرکتوری‌ها فضای زیادی از دیسک را اشغال می‌کنند.

4. خطای 403Forbidden 

این خطا به معنی این است که شما اجازه دسترسی به request resources (منابع درخواست) را ندارید.

این ارور در شرایطی رخ می‌دهد که:

• مدیر وب‌سایت دسترسی عمومی به منابع درخواستی را با لیست سفید IP یا روش‌های دیگر مسدود کرده است.
• وب‌سایت از یک فایروال برنامه وب مانند ModSecurity برای شناسایی حملات و مسدود ساختن چنین درخواست‌هایی استفاده می‌کند.

در برخی شرایط هم ممکن است سایت‌ها پیام خطای متفاوتی را در صورت وقوع 403 Forbidden نشان دهند. برای مثال ممکن است که به شما گفته شود، “secure connection failed” در حالی که علت این ارور با خطای 403 یکسان می‌باشد.

حل خطای secure connection failed در انجینکس

5. Internal Server Error 500 در nginx

این ارور به دلیل وجود خطاها در برنامه وب باشد. به طور کلی، خطای 500 به دلایل زیر به نمایش در خواهد آمد:

1. سرور دیتابیس از کار افتاده است(down شده).

در این شرایط باید وضعیت MySQL/MariaDB را با

sudo systemctl status mysql

بررسی کنید. آن را با

sudo systemctl start mysql

شروع کنید و

sudo journalctl -eu mysql

را اجرا نمایید.

البته توجه داشته باشید که فرآیند MySQL/MariaDB ممکن است به دلیل مشکلاتی خارج از حافظه، از بین برود.

2. عدم پیکربندی انجینیکس

عدم پیکربندی انجینیکس برای استفاده از PHP-FPM می‌تواند دلیل به وجود آمدن این ارور باشد. در این شرایط، Nginx نمی‌داند که چگونه کد PHP را اجرا کند.

3. پاک نکردن Cache داخلی

در صورتی که برنامه وب شما دارای کش داخلی باشد، می‌توانید برای برطرف کردن این ارور کش برنامه را پاک کنید.

4. ایجاد error log توسط برنامه وب

وب اپلیکیشن شما ممکن است گزارش خطای خود را ایجاد کند. برای برطرف کردن اشکال این خطا، فایل لاگ‌های آن را بررسی کنید.

5. وب اپلیکیشن دارای debugging mode باشد

اگر اپلیکیشن شما دارای چنین گزینه‌ای هست، آن را روشن کنید تا جزئیات بیشتری از پیام‌های خطا را بر وب‌پیج خود ببینید. برای مثال می‌توانید با تنظیم DEBUG = True در فایل srv/modoboa/instance/instance/settings.py/ حالت debugging یا همان اشکال زدایی را در پلتفرم میزبانی سرور ایمیل Modoboa روشن کنید.

6. اورلود PHP-FPM

اورلودِ PHP-FPM هم امکان‌پذیر هست. بنابراین لاگ‌های آن را نیز بررسی کنید گاهی ریلود PHP-FPM این خطا را مرتفع می‌کند.

6. Nginx Shows the default page (انجینیکس صفحه پیش‌فرض را نشان می‌دهد)

زمانی که قصد setup یک هاست مجازی Nginx را دارید و زمانی‌که نام دامنه را در مرورگر تایپ می‌کنید، احتمالا صفحه default انجینیکس نمایش داده شود.

این ارور ممکن است به دلایل زیر به وجود آمده باشد:

1. Real domain 

از یک نام دامنه واقعی (Real domain) برای دستور server_name در هاست مجازی انجینیکس خود استفاده نکرده‌اید.

2. ریلود Nginx را فراموش کرده‌اید!

وقتی انجینکس صفحه نمایش پیشفرض را نمایش می دهد، مشکل از کجاست؟

7. The page isn’t redirecting properly

به طور کلی این ارور در مرورگر Firefox نمایش داده می‌شود.

اما در مرورگر Chrome پیام www.example.com redirected you too many times را معادل خواهید دید.

این بدان معنی است که شما بارها ریدایرکشن انجینیکس را پیکربندی کرده‌اید. برای مثال ممکن است یک دستورالعمل غیرضروری return 301 را در سرور بلوک https اضافه کرده باشید تا HTTP را به اتصال HTTPS هدایت کنید.

اگر یک کش صفحه مانند کش Nginx FastCGI را setup کرده‌اید، باید کش صفحه سرور خود را پاک کنید.

خطای The page isn’t redirecting properly در فایرفاکس را چطور حل کنیم؟

8. 504Gateway time-out

Gateway Timeout در انجینکس بدان معنا است که upstream مانند PHP-FPM/MySQL/MariaDB قادر به پردازش سریع ریکوئست نخواهد بود. برای رفع موقت این ارور می‌توانید PHP-FPM را مجدد ریستارت کنید. البته برای عملکرد سریع‌تر، بهتر است که تنظیمات PHP-FPM/MySQL/MariaDB را مجددا انجام دهید.

در پایین پیکربندی InnoDB در فایل etc/mysql/mariadb.conf.d/50-server.cnf/ آمده است:

innodb_buffer_pool_size = 1024M
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M

#Improving disk I/O performance
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 400
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_buffer_pool_instances = 3

در بالا داریم:

• InnoDB buffer pool size باید حداقل نصف RAM شما باشد، انجام خواهد شد. (برای VPS با مقدار کمی RAM، توصیه می‌شود که اندازه buffer pool را روی مقدار کوچک‌تری مانند 400M تنظیم کنید، در غیر این صورت رمِ VPS شما به اتمام خواهد رسید.)
• اندازه فایل لاگ InnoDB باید 25٪ از پول سایزِ buffer باشد.
• threadهای IO برای read و write را حداکثر بر ۶۴ تنظیم کنید
• کاری کنید MariaDB از 3 نمونه پول بافر InnoDB استفاده کند. تعداد نمونه‌ها باید به همان تعداد هسته‌های CPU در سیستم شما باشد.

بعد از ذخیره تغییرات، MariaDB را مجددا ریستارت کنید:

sudo systemctl restart mariadb

همچنین می‌توانید مقدار timeout طولانی‌تری را در Nginx تنظیم کنید تا امکان gateway timeout را کاهش دهید. فایل هاست مجازی Nginx خود را ویرایش کنید و خطوط زیر را در server {…} بلوک خود اضافه کنید:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

اگر از Nginx با PHP-FPM استفاده می‌کنید، سپس fastcgi_read_timeout را بر روی یک مقدار بزرگتر مانند 300 ثانیه تنظیم نمایید(توجه داشته باشید که پیش‎فرض 60 ثانیه است).

location ~ \.php$ {
try_files $uri /index.php$is_args$args;
include snippets/fastcgi-php.conf;
fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_read_timeout 300;
}

سپس Nginx را reload کنید:

sudo systemctl reload nginx

PHP-FPM حداکثر زمان اجرا برای هر اسکریپت را دارد. فایل php.ini را ویرایش کنید:

sudo nano /etc/php/7.4/fpm/php.ini

می توانید مقدار را به 300 ثانیه افزایش دهید:

max_execution_time = 300

سپس PHP-FPM را ریستارت کنید:

sudo systemctl restart php7.4-fpm

9. خطای Memory Size Exhausted در Nginx

اگر خط زیر را در ارور لاگ Nginx مشاهده کردید، یعنی PHP به محدودیت حافظه 128 مگابایتی رسیده است:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

می‌توانید فایل php.ini (/etc/php/7.4/fpm/php.ini) را ویرایش کنید و محدودیت حافظه PHP را افزایش دهید:

memory_limit = 512M

سپس PHP7.4-FPM را ریستارت کنید:

sudo systemctl restart php7.4-fpm

اگر خطا همچنان وجود داشت، احتمال کدی در وب‌اپلیکیشن شما وجود دارد که مقداری زیادی از رم را مصرف می‌کند.

10. خطای PR_END_OF_FILE_ERROR

این ارور به 3 دلیل ممکن است به نمایش درآید:

1. شما Nginx را برای ریدایرکت ریکوئست HTTP به HTTPS پیکربندی کرده‌اید. اما هیچ بلوک سروری در Nginx وجود ندارد که درخواست HTTPS را ارائه کند.
2. شاید انجینیکس در حال اجرا نمی‌باشد!
3. گاهی اوقات Nginx در حال اجرا است اما یک فرآیند در حال کار می تواند به دلایل مختلف fail و exit شود. برای دیباگ، log خطاNginx؛ (/var/log/nginx/error.log) را بررسی کنید.

11. خطای PHP-FPM Upstream Time Out در انجینکس

برخی از افراد به خطای زیر در فایل log خطای Nginx (در /var/log/nginx/) برمی‌خورند:

[error] 7553#7553: *2234677 upstream timed out (110: Connection timed out) while reading response header from upstream

راه‌حل‌های ممکن:

1. PHP-FPM را ریستارت کنید.
2. رم را ارتقا دهید.

12. خطای انجینکس Resource temporarily unavailable

اگر خطای زیر را در فایل log خطای Nginx (در /var/log/nginx/) مشاهده کردید:

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

این معمولاً بدان معنی است که وب‌سایت شما بازدیدکنندگان زیادی دارد و PHP-FPM قادر به پردازش حجم عظیمی از ریکوئست‌ها نیست.

می‌توانید تعداد پردازش چایلد PHP-FPM child را طوری تنظیم کنید که درخواست‌های بیشتری را پردازش کند.

فایل PHP-FPM www.conf خود را ویرایش کنید. (مسیر فایل بسته به توزیع لینوکس شما متفاوت است.)

sudo /etc/php/7.4/fpm/pool.d/www.conf

پیکربندی فرآیند چایلد پیش فرض به شرح زیر است:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

پیکربندی بالا به این معنی است:

• PHP-FPM به صورت داینامیک فرآیندهای چایلد را ایجاد می‌کند. تعداد ثابتی از فرآیندهای چایلد وجود ندارد.
• حداکثر 5 فرآیند چایلد ایجاد می‌کند.
• شروع 2 فرآیند چایلد زمانی‌که PHP-FPM استارت می‌شود.
• حداقل 1 فرآیند idle وجود دارد.
• حداکثر 3 فرآیند idle وجود دارد.

پیش‌فرض‌ها مبتنی بر سروری بدون منابع کافی می‌باشند، مانند سروری که تنها 1 گیگابایت رم دارد. در صورتی که وب‌سایت پربازدیدی دارید، احتمالا قصد دارید که تعداد پردازش‌های چایلد را افزایش دهید(تا بتوانید ریکوئست‌های بیشتری ارائه دهد):

pm = dynamic
pm.max_children = 20
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

مطمئن شوید که RAM کافی برای اجرای فرآیندهای child بیشتری دارید و سپس ذخیره کنید و فایل را ببندید. در مرحله بعد PHP-FPM را ریستارت نمایید. (شاید لازم باشد شماره نسخه (version number) را تغییر دهید.)

sudo systemctl restart php7.4-fpm

برای نظارت بر سلامت PHP-FPM، می‌توانید صفحه وضعیت (Status Page) را فعال کنید. خط زیر را در فایل PHP-FPM www.conf پیدا نمایید:

;pm.status_path = /status

برای فعال کردن صفحه وضعیت PHP-FPM، نقطه ویرگول را بردارید. سپس PHP-FPM را ریستارت کنید:

sudo systemctl restart php7.4-fpm

سپس فایل هاست مجازی انجینیکس خودتان را ویرایش و خطوط زیر را اضافه کنید. دستورات allow و deny برای محدود کردن دسترسی استفاده می‌شوند. توجه داشته باشید که فقط آدرس‌های IP در لیست سفید می‌توانند به Status Page دسترسی داشته باشند:

location ~ ^/(status|ping)$ {
allow 127.0.0.1;
allow your_other_IP_Address;
deny all;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

در این مرحله فقط باید ذخیره کنید و فایل را ببندید و سپس تنظیمات انجینیکس را تست نمایید:

sudo nginx -t

در صورتی که تست شما موفقیت آمیز بود، Nginx را ریلود کنید تا تغییرات اعمال شوند:

sudo systemctl reload nginx

نمونه PHP-FPM status page در nginx

فایل PHP-FPM www.conf به شما توضیح خوبی در مورد معنای هر پارامتر خواهد داد.

بررسی و تست PHP-FPM در nginx

اگر PHP-FPM نتواند یک درخواست را بلافاصله ارائه دهد، آن را در queue قرار خواهد داد. به صورت پیش‌فرض تا حداکثر 511 درخواست در queue قرار می‌گیرد که توسط پارامتر listen.backlog تعیین خواهد شد:

listen.backlog = 511

اگر مقدار زیر را در صفحه وضعیت PHP-FPM مشاهده کردید، به این معنی است که هرگز درخواستی در queue قرار داده نشده است. در واقع PHP-FPM شما می‌تواند درخواست‌ها را با سرعت بالایی پردازش کند.

listen queue: 0
max listen queue: 0

در صورتی که 511 ریکوئست pending در queue وجود داشته باشد، به این معنی است که PHP-FPM شلوغی زیادی دارد. به همین دلیل باید تعداد پردازش‌های Child خود را افزایش دهید.

همچنین ممکن است لازم باشد که تنظیمات هسته لینوکس net.core.somaxconn را تغییر دهید. این کار حداکثر تعداد اتصالات مجاز به یک سوکت فایل در لینوکس مانند سوکت یونیکس PHP-FPM را تعیین می‌کند.

به صورت پیش‌فرض مقدار آن 128 قبل از kernel 5.4 و 4096 است که با kernel 5.4 شروع می‌شود:

parspack@ubuntu:~$ sysctl net.core.somaxconn
net.core.somaxconn = 128

اگر یک وب‌سایت پربازدید دارید و کاربران زیادی در طول شبانه روز به سایتتان مراجعه می‌کنند، فایل /etc/sysctl.conf را ویرایش کنید:

sudo nano /etc/sysctl.cnf

سپس دو خط زیر را اضافه کنید:

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

در مرحله بعد فقط کافی است تا ذخیره کنید و فایل را ببندید. سپس تنظیمات را اعمال نمایید:

sudo sysctl -p

توجه داشته باشید: در صورتی که سرور شما رم کافی داشته باشد، می‌توانید تعداد ثابتی از پردازش‌های child (مانند زیر) را برای PHP-FPM اختصاص دهید:

pm = static
pm.max_children = 50

13. Two Virtual Host file For the Same Website

در صورتی که sudo nginx -t را اجرا کنید و ارور زیر را ببینید:

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

این بدان معنی است که دو فایل هاست مجازی وجود دارد که شامل یک پیکربندی server_name هستند. توصیه می‌شود که دو فایل هاست مجازی برای یک وب‌سایت ایجاد نکنید.

14. PHP-FPM Connection reset by peer

فایل ارور log انجینیکس پیام زیر را نشان خواهد داد:

recv() failed (104: Connection reset by peer) while reading response header from upstream

این ارور ممکن است به دلیل ریستارت PHP-FPM باشد. در صورتی که به شکل منوال ریستارت PHP-FPM را انجام می‌دهید، می‌توانید این ارور را نادیده بگیرید.

15. Nginx Socket Leaks

اگر به پیام زیر در فایل /var/log/nginx/error.log برخورد کردید، بدانید که Nginx شما مشکل Socket Leaks دارد:

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163
2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188
2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213
2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217
2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244
2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245
2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255
2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258
2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269
2021/09/28 13:27:41 [alert] 321#321: aborting

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

16. Cloudflare Errors

اگر وب‌سایت شما در بستر Cloudflare CDN (شبکه تحویل محتوا) اجرا می‌شود، در ادامه برخی از خطاها و راه‌حل‌های رایج را به شما خواهیم گفت.

1. 521Web Server is Down

با مشاهده این اخطار باید بدانید که یا انجینیکس در حال اجرا نیست یا پورت‌های TCP 80 و 443 را در فایروال باز نکردید.

البته یک احتمال دیگر وجود دارد که نشان می‌دهد شما آدرس IP سرور را تغییر دادید؛ اما فراموش کرده‌اید که رکورد DNS را در Cloudflare به روز کنید.

2. The page isn’t redirecting properly

در صورتی که تنظیمات SSL شما در برنامه SSL/TLS روی Flexible تنظیم شده باشد اما سرور اصلیتان برای ریدایرکت درخواست‌های HTTP به HTTPS پیکربندی شده‌ است، سرور انجینیکس شما پاسخ را به Cloudflare در اتصال رمزگذاری شده و امن ارسال خواهد کرد.

به دلیل اینکه Cloudflare انتظار ترافیک HTTP را دارد، به ارسال مجدد همان درخواست ادامه می‌دهد و در نتیجه یک ریدایرکت لوپ ایجاد خواهد کرد. در این شرایط باید از گزینه Full (strict) SSL/TLS در تنظیمات Cloudflare خود استفاده کنید.

رفع خطای کلودفلر در انجینکس

سخن آخر

امیدواریم این مقاله به شما در رفع ارورهای متداول وب‌سرور انجینیکس کمک کرده باشد. همانطور که در ابتدای مقاله هم گفته شد، تمام این راه‌حل‌ها مشکل را به احتمال زیاد حل خواهند کرد. (هیچ تضمینی برای برطرف شدن قطعی مشکل با این راه‌حل‌ها وجود ندارد)

راه‌حل‌های زیادی برای برطرف کردن ارورهای متداول وب‌سرور انجینیکس وجود دارد که در این مقاله بهترین آن‌ها جمع‌آوری و ارائه شده‌اند.

سوالات متداول

1. انجینیکس چیست؟

انجینیکس یکی از معروف‌ترین و محبوب‌ترین وب‌سرورهای موجود در جهان است که کاربردهای زیادی دارد و افراد بی‌شماری از آن استفاده می‌کنند.

2. چند ارور در وب‌سرور Nginx وجود دارد؟

مقدار دقیقی از تعداد ارورهای وب‌سرور انجینیکس در دسترس نیست اما رایج‌ترین آن‌ها در این مقاله به همراه راه‌حل برطرف کردنشان گفته شده‌اند.

3. آیا مشکل من با اجرای این کدها به صورت قطعی رفع خواهد شد؟

هیچ تضمینی برای برطرف شدن صد در صدی ارورها با استفاده از کدهایی که گفته شد وجود ندارد. تمام این کدها ارورهای رایج مربوط به خودشان را به احتمال زیاد برطرف خواهند کرد.