۱۶ راهکار تضمینی برای رفع خطای متداول وب سرور انجینکس
در این مقاله میخوانید
- وبسرور انجینیکس چیست؟
- 1. خطای Unable to connect/Refused to Connect در انجینکس
- 2. خطای انجینکس The Connection Has Timed Out
- 3. خطای 404Not Found در انجینکس
- 4. خطای 403Forbidden
- 5. Internal Server Error 500 در nginx
- 6. Nginx Shows the default page (انجینیکس صفحه پیشفرض را نشان میدهد)
- 7. The page isn’t redirecting properly
- 8. 504Gateway time-out
- 9. خطای Memory Size Exhausted در Nginx
- 10. خطای PR_END_OF_FILE_ERROR
- 11. خطای PHP-FPM Upstream Time Out در انجینکس
- 12. خطای انجینکس Resource temporarily unavailable
- 13. Two Virtual Host file For the Same Website
- 14. PHP-FPM Connection reset by peer
- 15. Nginx Socket Leaks
- 16. Cloudflare Errors
- سخن آخر
- سوالات متداول
انجینیکس یکی از محبوبترین وبسرورها در جهان است. این وبسرور یک سری خطاهای رایج و ارورهای متداول دارد که ممکن است شما را با مشکل مواجه کند. در این مقاله قصد داریم روش مرتفع کردن ارورهای متداول از وبسرور انجینیکس را به شما آموزش دهیم.
توجه داشته باشید که این فهرست کامل نیست و راهحلهای گفته شد به احتمال زیاد مشکل شما را برطرف خواهند کرد. در صورتی که نتوانستید مشکلات وبسرور 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
به احتمال زیاد میتوان با راهحلهای زیر مشکل را برطرف کرد.
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 یکسان میباشد.
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 کردهاید، باید کش صفحه سرور خود را پاک کنید.
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 دلیل ممکن است به نمایش درآید:
- شما Nginx را برای ریدایرکت ریکوئست HTTP به HTTPS پیکربندی کردهاید. اما هیچ بلوک سروری در Nginx وجود ندارد که درخواست HTTPS را ارائه کند.
- شاید انجینیکس در حال اجرا نمیباشد!
- گاهی اوقات 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
راهحلهای ممکن:
- PHP-FPM را ریستارت کنید.
- رم را ارتقا دهید.
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 www.conf به شما توضیح خوبی در مورد معنای هر پارامتر خواهد داد.
اگر 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. آیا مشکل من با اجرای این کدها به صورت قطعی رفع خواهد شد؟
هیچ تضمینی برای برطرف شدن صد در صدی ارورها با استفاده از کدهایی که گفته شد وجود ندارد. تمام این کدها ارورهای رایج مربوط به خودشان را به احتمال زیاد برطرف خواهند کرد.