nginx چیست؟ وب‌سروری که جلوی نیمی از اینترنت نشسته است

nginx چیست و پنج کاری که انجام می‌دهد

nginx (که «انجین‌اکس» خوانده می‌شود) یک سرور و پروکسی HTTP متن‌باز است. ایگور سیسوئف آن را نوشت تا روی یک ماشین بتوان ده‌هزار اتصال همزمان را باز نگه داشت، در زمانی که همین کار اکثر سرورها را زمین‌گیر می‌کرد، و در سال 2004 منتشرش کرد. امروز nginx یکی از دو وب‌سروری است که بیشترین استقرار را در جهان دارد، در کنار Apache، و موتور داخل بسیاری از load balancerها، ingress controllerهای Kubernetes و CDNها. نسخهٔ متن‌باز در nginx.org قرار دارد؛ F5، که شرکت پشت آن را در سال 2019 خرید، نسخهٔ تجاری‌ای به نام NGINX Plus می‌فروشد.

این نام پنج نقش را پوشش می‌دهد، و یک پیکربندی می‌تواند همهٔ آن‌ها را با هم ترکیب کند:

وب‌سرور. فایل‌ها را از دیسک می‌خواند و می‌فرستد: HTML، CSS، JavaScript، تصویر، دانلود. این کاری است که سریع‌ترین انجامش می‌دهد، با sendfile که کپی‌کردن را به kernel می‌سپارد.

Reverse proxy. درخواست را می‌پذیرد و به اپلیکیشنی می‌سپارد که نباید خودش مستقیم روی اینترنت باشد: PHP-FPM، Node.js، Python، Go، Java، یک container. موضوع کامل، از جمله هدرهایی که باید forward شوند، در راهنمای reverse proxy ما آمده است.

Load balancer. درخواست‌ها را روی چند نسخه از همان اپلیکیشن پخش می‌کند و فرستادن ترافیک به نسخه‌ای که از کار افتاده را متوقف می‌کند.

Cache. پاسخ‌های upstream را روی دیسک نگه می‌دارد و به درخواست‌های تکراری بدون پرسیدن دوباره از اپلیکیشن پاسخ می‌دهد.

TLS terminator. گواهی‌ها را نگه می‌دارد، با مرورگر HTTPS، HTTP/2 و HTTP/3 صحبت می‌کند، و با اپلیکیشن روی یک آدرس خصوصی به HTTP ساده صحبت می‌کند.

چیزی که نیست: application server. nginx کد PHP، Python یا Ruby شما را اجرا نمی‌کند. آن درخواست‌ها را به فرآیندی که این کار را می‌کند می‌سپارد، و پاسخ را برمی‌گرداند.

رویدادمحور: چرا nginx این‌قدر اتصال نگه می‌دارد

وقتی nginx شروع می‌شود، یک master process پیکربندی را می‌خواند، پورت‌های گوش‌دادن را باز می‌کند و چند worker process راه می‌اندازد، معمولاً یکی به‌ازای هر هستهٔ CPU (worker_processes auto). master هیچ‌وقت ترافیک را سرویس نمی‌دهد. workerها را مدیریت می‌کند، و همین چیزی است که reload را بی‌دردسر می‌کند.

هر worker تک‌رشته‌ای (single-threaded) است و یک event loop اجرا می‌کند. از kernel، از طریق epoll در Linux یا kqueue در BSD و macOS، می‌پرسد کدام یک از اتصالاتش چیزی برای ارائه دارد: یک درخواست جدید، کلاینتی که می‌تواند بایت‌های بیشتری بگیرد، یک upstream که جواب داده است. روی هر اتصال آماده یک کار کوتاه انجام می‌دهد و می‌رود سراغ بعدی؛ هیچ‌چیز منتظر نمی‌ماند. یک اتصال keep-alive که بین درخواست‌ها بی‌کار است، یا یک کلاینت موبایل آهسته که درخواستش را قطره‌چکانی می‌فرستد، برای worker فقط چند کیلوبایت حافظه هزینه دارد و هیچ CPU.

مدل کلاسیک Apache برعکس این است. MPM به نام prefork به هر اتصال فرآیند خودش را می‌دهد و MPM به نام worker رشتهٔ خودش را، و آن فرآیند یا رشته تا وقتی اتصال برقرار است، مشغول باشد یا بی‌کار، اشغال می‌ماند. ده‌هزار اتصال keep-alive باز یعنی ده‌هزار فرآیند یا رشته، با حافظه و context switching که همراهش می‌آید. MPM جدیدتر Apache به نام event اتصالات keep-alive بی‌کار را با یک رشتهٔ listener پارک می‌کند، که فاصله را کم می‌کند، اما هر درخواست فعال همچنان یک رشته را نگه می‌دارد.

قاعده‌ای که از این نتیجه می‌شود: یک worker هرگز نباید block شود. کاری که واقعاً زمان می‌برد، مثل اجرای PHP یا کوئری‌زدن به یک دیتابیس، در فرآیند دیگری اتفاق می‌افتد، و nginx پاسخ را مثل یک رویداد دیگر می‌بیند. جمع ظرفیت برابر worker_processes × worker_connections است، و وقتی nginx پروکسی می‌کند، هر کلاینت دو تا از آن slotها را استفاده می‌کند: یکی برای مرورگر، یکی برای upstream.

بالای nginx.conf: یک master، یک worker به ازای هر هسته، یک event loop در هر کدام

user www-data;
worker_processes auto;            # one worker per CPU core
error_log /var/log/nginx/error.log warn;

events {
    worker_connections 1024;      # per worker: clients + upstream connections
}

http {
    include      mime.types;
    sendfile     on;
    keepalive_timeout 65s;

    include /etc/nginx/conf.d/*.conf;   # one file per site
}

nginx برای چه کاری استفاده می‌شود

در عمل nginx یکی از این جایگاه‌ها را می‌گیرد، اغلب چند تا را با هم.

سرویس‌دهی یک سایت استاتیک یا یک build فرانت‌اند. یک build با React، Vue یا Astro، یک مستندات، یک landing page: فایل‌هایی روی دیسک و nginx جلویش، هیچ‌چیز دیگر.

جلوی PHP. WordPress، Laravel و اکثر اپلیکیشن‌های PHP به‌شکل nginx به‌همراه PHP-FPM اجرا می‌شوند. nginx خودش تصاویر، CSS و JavaScript را سرویس می‌دهد و درخواست‌های .php را با fastcgi_pass روی یک Unix socket به FPM می‌سپارد.

جلوی یک application server. سرویس‌های Node.js، Python (Gunicorn، Uvicorn)، Ruby (Puma) و Go روی یک پورت محلی گوش می‌دهند. nginx اتصال HTTPS را خودش تمام می‌کند، کلاینت‌های آهسته را با بافرکردن درخواست جذب می‌کند، سپس آن را با proxy_pass فوروارد می‌کند، پس اپلیکیشن همیشه فقط درخواست‌های سریع و کامل را می‌بیند.

Load balancing روی چند نمونه از اپلیکیشن، که کمی پایین‌تر به‌طور خلاصه آمده است.

TLS و پروتکل‌های مدرن برای اپلیکیشنی که هیچ‌کدام را ندارد: گواهی (اکثر افراد آن‌ها را با certbot و Let's Encrypt می‌گیرند)، HTTP/2 با http2 on; و HTTP/3 با listen 443 quic; در nginx 1.25 و نسخه‌های بعدی. آنچه این پروتکل‌ها عوض می‌کنند در HTTP/2 در مقابل HTTP/3 آمده است.

قواعد دم در: ریدایرکت‌ها، rate limiting با limit_req، فهرست‌های اجازه و رد IP، فشرده‌سازی gzip و هدرهای پاسخ. اینکه کدام هدرها را بفرستید و چرا، در هدرهای امنیتی HTTP آمده است.

یک server block مینیمال، سطر به سطر

یک بلوک server یک سایت است. nginx آن را بر اساس پورتی که درخواست رویش رسیده و هدر Host که با server_name مقایسه می‌شود انتخاب می‌کند. درون آن، بلوک‌های location مسیرهای URL را مطابقت می‌دهند. بلوک زیر یک سایت استاتیک را سرویس می‌دهد و /api/ را به اپلیکیشنی روی پورت 3000 می‌فرستد.

listen پورت است، یک بار برای IPv4 و یک بار برای IPv6.

server_name نام‌میزبان‌هایی را فهرست می‌کند که این بلوک به آن‌ها پاسخ می‌دهد. درخواستی که Host آن با هیچ بلوکی مطابقت نداشته باشد به default server آن پورت می‌رود: بلوکی که default_server روی آن علامت خورده، یا در غیر این صورت اولین بلوکی که nginx خوانده است. همین دلیل آن است که یک نام‌میزبان ناشناخته که به IP شما اشاره می‌کند سایت دیگری را نشان می‌دهد. یک بلوک catch-all که return 444; (بستن اتصال) پاسخ می‌دهد این را متوقف می‌کند.

root جایی است که فایل‌ها در آن جست‌وجو می‌شوند: /about.html به /var/www/example/about.html تبدیل می‌شود.

try_files اول فایل را امتحان می‌کند، بعد یک دایرکتوری، بعد fallback را. برای یک single-page app، =404 را با /index.html جایگزین کنید تا route‌های سمت کلاینت اپلیکیشن را بار کنند.

تطبیق location ترتیبی دارد که افراد را غافلگیر می‌کند. یک تطبیق دقیق (=) کاملاً می‌برد. در غیر این صورت nginx طولانی‌ترین prefix مطابق را به‌خاطر می‌سپارد، سپس عبارت‌های باقاعده (~، ~*) را به ترتیب فایل امتحان می‌کند و اولین مورد مطابق را می‌گیرد؛ فقط اگر هیچ‌کدام مطابقت نداشت، همان prefix به‌خاطرسپرده‌شده استفاده می‌شود. یک prefix با ^~ مرحلهٔ regex را رد می‌کند. در این مثال /api/logo.png با regex تصویر سرویس می‌شود، نه با /api/، که پاسخ معمول به «چرا location من نادیده گرفته می‌شود» است.

expires مقادیر Cache-Control: max-age و Expires را روی asset‌های دارای fingerprint تنظیم می‌کند. مقادیر را با راهنمای Cache-Control انتخاب کنید.

این بلوک HTTP ساده است. گواهی را با certbot اضافه کنید، که بلوک را خودش برایتان ویرایش می‌کند، و پورت 80 را به 443 ریدایرکت کنید.

/etc/nginx/conf.d/example.conf: یک سایت استاتیک با یک API پشتش

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root  /var/www/example;
    index index.html;

    access_log /var/log/nginx/example.access.log;
    error_log  /var/log/nginx/example.error.log;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~* \.(?:css|js|woff2|png|jpg|webp|avif|svg)$ {
        expires 30d;
        access_log off;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:3000;
        # plus the forwarded headers from the reverse proxy guide
    }
}

نصب، تست، reload: فرمان‌هایی که هر روز استفاده می‌کنید

پکیج‌های توزیع فایل اصلی را در /etc/nginx/nginx.conf قرار می‌دهند. Debian و Ubuntu سایت‌ها را در /etc/nginx/sites-available/ نگه می‌دارند و آن‌ها را با یک symlink داخل sites-enabled/ فعال می‌کنند؛ RHEL، Rocky، Alpine و پکیج‌های nginx.org از /etc/nginx/conf.d/*.conf می‌خوانند. لاگ‌ها به /var/log/nginx/ می‌روند.

دو عادت اکثر قطعی‌های خودساخته را جلو می‌گیرد. پیش از هر reload، nginx -t را اجرا کنید: کل پیکربندی را پارس می‌کند و فایل و سطر هر اشتباهی را نام می‌برد. و reload کنید نه restart. در یک reload، master با پیکربندی جدید workerهای جدید را شروع می‌کند و می‌گذارد workerهای قدیمی درخواست‌های بازشان را تمام کنند، پس هیچ اتصالی قطع نمی‌شود؛ اگر پیکربندی جدید بار نشود، master workerهای قدیمی را در حال اجرا نگه می‌دارد و دلیلش را لاگ می‌کند.

nginx -T کل پیکربندی را همان‌طور که nginx می‌بیند چاپ می‌کند، با همهٔ includeها باز شده. وقتی یک تنظیم اثری ندارد، معمولاً در فایلی که فراموشش کرده‌اید override شده، و -T نشانتان می‌دهد در کدام.

# Debian / Ubuntu
sudo apt install nginx
nginx -v                                   # version; -V adds build options and modules

# check the syntax, then apply without dropping connections
sudo nginx -t && sudo systemctl reload nginx

# the whole effective configuration, includes expanded
sudo nginx -T | less

# which names and ports are configured
sudo nginx -T | grep -E '^\s*(server_name|listen)'

# watch errors while you test
sudo tail -f /var/log/nginx/error.log

nginx در برابر Apache

هر دو بالغ، رایگان و برای تقریباً هر سایتی به‌اندازهٔ کافی سریع‌اند. تفاوت‌هایی که واقعاً بین آن‌ها تصمیم می‌گیرند:

مدل اتصال. event loop nginx اتصالات بی‌کار و آهسته را تقریباً رایگان نگه می‌دارد؛ Apache یک فرآیند یا رشته را به هر درخواست فعال گیر می‌دهد و، بیرون از MPM به نام event، به هر اتصال بی‌کار هم. با اتصالات keep-alive همزمان زیاد، nginx حافظهٔ بسیار کمتری استفاده می‌کند.

پیکربندی. با AllowOverride روشن، Apache از هر دایرکتوری در مسیر هر درخواست فایل‌های .htaccess می‌خواند، پس یک کاربر می‌تواند قواعد را بدون دست‌زدن به پیکربندی سرور عوض کند. nginx معادلی ندارد: هر قاعده در پیکربندی مرکزی زندگی می‌کند و فقط یک بار، در لحظهٔ بارگذاری، پارس می‌شود. این سریع‌تر و راحت‌تر برای audit است، اما یک .htaccess وردپرس یا لاراول وقتی جابه‌جا می‌شوید باید به قواعد location و try_files بازنویسی شود.

PHP. Apache می‌تواند PHP را با mod_php درون فرآیندهای خودش اجرا کند؛ nginx همیشه با یک pool جدای PHP-FPM صحبت می‌کند. راه‌اندازی‌های فعلی Apache هم اغلب از PHP-FPM استفاده می‌کنند، پس این الان بیشتر یک تفاوت در پیش‌فرض‌هاست.

ماژول‌ها. Apache ماژول‌ها را در زمان اجرا از یک کاتالوگ بسیار بزرگ بار می‌کند. nginx از ماژول‌های dynamic پشتیبانی می‌کند، اما هر کدام باید دقیقاً روی نسخهٔ nginx‌ای که اجرا می‌کنید build شود، پس خیلی از افزونه‌ها یعنی کامپایل‌کردن.

فایل‌های استاتیک و پروکسی‌کردن جایی است که nginx قوی‌ترین است. برای همین یک ترکیب رایج این است که nginx را جلو می‌گذارند، فایل‌ها را سرویس می‌دهد و TLS را تمام می‌کند، و پشتش Apache یک اپلیکیشنی را اجرا می‌کند که به .htaccess وابسته است.

خلاصهٔ صادقانه: برای شروع از صفر، nginx انتخاب پیش‌فرض اکثر تیم‌هاست. اما جایگزین‌کردن یک Apache که کار می‌کند یک سایت آهسته را سریع نمی‌کند. بخش آهسته تقریباً همیشه اپلیکیشن است یا فاصلهٔ تا بازدیدکننده، نه وب‌سرور.

Reverse proxy، load balancer و cache: نسخهٔ خلاصه

پروکسی‌کردن یک directive است، proxy_pass، به‌همراه هدرهایی که به اپلیکیشن می‌گویند کلاینت واقعاً کیست. آن هدرها، پشتیبانی WebSocket و proxy_cache در راهنمای reverse proxy پوشش داده شده‌اند، پس این صفحه آن‌ها را تکرار نمی‌کند.

Load balancing یک بلوک upstream اضافه می‌کند که سرورها را نام می‌برد. پیش‌فرض round robin است. least_conn هر درخواست را به سروری می‌فرستد که کمترین اتصال فعال را دارد، که برای درخواست‌های با طول نامتساوی مناسب است، و ip_hash یا hash یک کلاینت را روی همان سرور نگه می‌دارد. health checking در nginx متن‌باز passive است: بعد از max_fails شکست درون fail_timeout، یک سرور برای همان مدت رد می‌شود، و proxy_next_upstream درخواست را روی سروری دیگر دوباره امتحان می‌کند. چک‌های active که یک URL را طبق زمان‌بندی probe می‌کنند یک ویژگی NGINX Plus‌اند. برای تصویر بزرگ‌تر، کاری که یک load balancer می‌کند را ببینید.

Caching خوب کار می‌کند، با یک شکاف که باید از پیش بدانید: nginx متن‌باز هیچ فرمانی برای purge‌کردن یک URL cache‌شده ندارد. باید منتظر بمانید entry منقضی شود یا فایل‌ها را از دایرکتوری cache روی هر سرور حذف کنید. این شکاف یکی از رایج‌ترین دلایلی است که تیم‌ها cache عمومی را به یک CDN منتقل می‌کنند.

سه application server پشت یک nginx

upstream app {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=10s;
    server 10.0.0.13:3000 backup;     # used only when the others are down
    keepalive 32;                     # reuse connections to the app
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;
        proxy_set_header Connection "";          # required for upstream keepalive
        proxy_next_upstream error timeout http_502;
        # plus the forwarded headers from the reverse proxy guide
    }
}

502، 504 و 413: nginx چه می‌گوید

کد وضعیتی که بازدیدکننده می‌بیند خلاصه است؛ error log توضیح است. هر یک از این خطاها سطری متمایز در آن می‌گذارد.

502 Bad Gateway یعنی nginx هیچ پاسخ قابل‌استفاده‌ای از upstream نگرفته است. connect() failed (111: Connection refused) می‌گوید هیچ‌چیز روی آدرسی که در proxy_pass است گوش نمی‌دهد: اپلیکیشن خاموش است یا روی پورت دیگری. connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) یک مسیر socket PHP-FPM است که با نسخهٔ PHP نصب‌شده مطابقت ندارد، و (13: Permission denied) روی همان سطر یعنی socketی است که کاربر nginx شاید نتواند بازش کند. upstream prematurely closed connection یعنی اپلیکیشن crash کرده یا وسط درخواست kill شده است؛ لاگ خودش و پیام‌های out-of-memory kernel را بخوانید. upstream sent too big header یعنی هدرهای پاسخ، اغلب انبوهی از کوکی، در بافر جا نمی‌شوند: proxy_buffer_size را بالا ببرید، یا برای PHP fastcgi_buffer_size را. تشخیص کامل، از جمله حالتی که یک CDN جلویش باشد، در 502 Bad Gateway آمده است.

504 Gateway Timeout یعنی upstream درخواست را پذیرفته و در بازهٔ proxy_read_timeout (یا fastcgi_read_timeout)، که پیش‌فرضش 60 ثانیه است، پاسخ نداده است. لاگ می‌گوید upstream timed out (110: Connection timed out) while reading response header from upstream. timeout طولانی‌تر برای یک export یا report شناخته‌شدهٔ آهسته درست است؛ برای صفحات معمولی فقط یک کوئری آهسته یا یک worker pool پر را پنهان می‌کند. هر پروکسی در زنجیره محدودیت خودش را دارد، پس یک load balancer یا CDN جلویی ممکن است زودتر از nginx تسلیم شود.

413 Request Entity Too Large یعنی بدنهٔ درخواست بزرگ‌تر از client_max_body_size است، که پیش‌فرضش 1 مگابایت است: آپلود کلاسیک تصویر یا بکاپی که شکست می‌خورد. لاگ می‌گوید client intended to send too large body. محدودیت را در server یا location که آپلودها را می‌گیرد بالا ببرید نه به‌صورت سراسری، و برای PHP مقدار upload_max_filesize و post_max_size را هم به همان اندازه بالا ببرید، وگرنه PHP چیزی را که nginx اجازهٔ عبورش را داده رد می‌کند.

یک 503 از nginx معمولاً limit_req یا limit_conn خودش است که یک درخواست را پس می‌زند؛ این و دلایل دیگر در 503 Service Unavailable آمده‌اند. و directory index of "/var/www/..." is forbidden یک 403 برای دایرکتوری بدون فایل index است، که در 403 Forbidden پوشش داده شده.

سطرهای error log و directiveای که هر کدام به آن اشاره می‌کند

# /var/log/nginx/error.log (abridged)
connect() failed (111: Connection refused) while connecting to upstream        -> 502
upstream prematurely closed connection while reading response header          -> 502
upstream sent too big header while reading response header from upstream       -> 502
upstream timed out (110: Connection timed out) while reading response header   -> 504
client intended to send too large body: 52428800 bytes                         -> 413

# the matching fixes, in the server or location that needs them
client_max_body_size 64m;     # PHP: raise upload_max_filesize and post_max_size too
proxy_read_timeout   300s;    # only for a known slow endpoint
proxy_buffer_size    16k;     # large response headers and cookies
proxy_buffers        8 16k;

چه زمانی یک CDN جلوی nginx بگذاریم

یک nginx ترافیک زیادی را سرویس می‌دهد. چیزی که نمی‌تواند عوض کند جای آن است. بازدیدکننده‌ای در کشوری دیگر در هر رفت‌وبرگشت منتظر datacentre تنها شما می‌ماند؛ یک spike ترافیکی که بیشترش درخواست تکراری است باز هم روی همان یک ماشین شما فرود می‌آید؛ حمله‌ای که IP شما را هدف گرفته به همان سروری می‌رسد که سایتتان را اجرا می‌کند. این‌ها لحظه‌هایی هستند که باید یک CDN اضافه کنید: مخاطبتان از سرور دور است، سهم بزرگی از بار ترافیک cache‌پذیر است، به purge‌کردن cache روی بیش از یک ماشین نیاز دارید، یا origin باید دیگر مستقیم در دسترس نباشد.

nginx را نگه می‌دارید؛ نقشش عوض می‌شود. CDN درِ ورودی عمومی می‌شود و nginx origin می‌شود، فایل‌ها را سرویس می‌دهد و به اپلیکیشن مسیر می‌دهد در حالی که edge فاصله، cache و فیلترکردن را مدیریت می‌کند. سه چیز باید سمت nginx تنظیم شود. هدرهای Cache-Control درست بفرستید، چون edge از آن‌ها پیروی می‌کند. IP بازدیدکننده را با ماژول realip بازگردانید (set_real_ip_from برای آدرس‌های CDN، real_ip_header برای هدری که می‌فرستد)، وگرنه هر سطر لاگ و هر zone limit_req به‌جای بازدیدکننده edge را می‌بیند. و فقط اجازه دهید CDN به origin برسد، تا حمله‌ها نتوانند دور آن بزنند.

edge CDN.com.tr خودش روی nginx اجرا می‌شود: پیکربندی آن اندازهٔ فایل پکیج شما را به‌عنوان client_max_body_size اعمال می‌کند، پس آپلودی که از CDN عبور می‌کند به‌اندازهٔ کافی بزرگ‌بودن آن محدودیت را هم لازم دارد، نه فقط محدودیت خودتان. جلوی origin شما، شبکهٔ edge، با سرورهایی در ترکیه و خارج از آن، بر اساس قوانین تحویل به‌ازای هر مسیر cache می‌کند و با مسیر یا پوشهٔ دقیق، از پنل، خط فرمان cdnctl یا REST API، فوری purge می‌کند. یک WAF، محافظت DDoS، محافظت در برابر bot با یک چالش JavaScript، قواعد کشور و IP و rate limiting پیش از رسیدن یک درخواست به سرور شما اجرا می‌شوند، و گواهی‌های Let's Encrypt برای هر دامنهٔ متصل صادر و تمدید می‌شوند.

دو جزئیات این تغییر را راحت‌تر قابل‌تأیید می‌کنند. صفحاتی که از قبل در cache edge هستند حتی وقتی origin شما خاموش است سرویس‌دهی را ادامه می‌دهند، و هدر پاسخ X-Proxy-Cache-MT مقدار HIT یا MISS را نشان می‌دهد، پس می‌توانید بفهمید آیا یک درخواست اصلاً به nginx شما رسیده یا نه. edge همچنین SNI را به origin می‌فرستد، پس یک nginx با چند بلوک server از نوع HTTPS گواهی درست را نشان می‌دهد.