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

اتصال WebSocket از پشت Nginx برقرار نمی‌شود؛ راهنمای مرحله‌به‌مرحله

آموزش تشخیص خطای WebSocket، تنظیم Upgrade در Nginx و آزمون امن مسیر و پایداری اتصال.

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله اتصال WebSocket از پشت Nginx برقرار نمی‌شود؛ راهنمای مرحله‌به‌مرحله در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
صفحه سایت باز می‌شود، اما چت زنده یا داشبورد لحظه‌ای وصل نمی‌شود. ممکن است درخواست معمولی HTTP سالم باشد ولی مسیر WebSocket از پراکسی عبور نکند. Nginx در نقش پراکسی میان مرورگر و برنامه قرار می‌گیرد؛ برای ارتقای اتصال به WebSocket باید تنظیمات مسیر و سرآیندهای لازم با برنامه سازگار باشند.
این راهنما برای مدیر مجاز سرور لینوکسی است. پیش از تغییر، از فایل پیکربندی فعال نسخه پشتیبان بگیرید، دسترسی کنسول یا SSH سالم داشته باشید و تغییر را ابتدا در محیط آزمایشی امتحان کنید. در هاست اشتراکی ممکن است ویرایش Nginx در اختیار شما نباشد؛ در آن صورت جزئیات خطا را به مدیر هاست بدهید.

۱. خطا را از مرورگر ببینید

در مرورگر صفحه مشکل‌دار را باز کنید، ابزار توسعه‌دهنده را با F12 باز و تب Network را انتخاب کنید. فیلتر WS یا WebSocket را بزنید و صفحه را تازه کنید. درخواست اتصال، نشانی و کد پاسخ آن را ببینید. در اتصال معمول WebSocket مبتنی بر HTTP/1.1، پاسخ موفق آغاز ارتقا معمولاً 101 Switching Protocols است. کدهایی مانند 404، 403 یا 502 سرنخ متفاوتی دارند. کد 101 به‌تنهایی موفقیت ورود کاربر یا تبادل همه پیام‌ها را تضمین نمی‌کند.
اگر سایت با HTTPS باز است، برنامه معمولاً باید از wss:// استفاده کند تا مرورگر اتصال ناامن را مسدود نکند. نام دامنه، مسیر مثل /socket/، زمان خطا و پیام Console را یادداشت کنید؛ توکن یا کوکی کاربر را در جایی منتشر نکنید.

۲. برنامه پشت پراکسی را جدا کنید

با SSH وارد سرور شوید و وضعیت همان برنامه را از ابزار مدیریت خودش ببینید. اگر برنامه با systemd اجرا می‌شود، نام واقعی سرویس را جایگزین myapp کنید:
کد / دستورsudo systemctl status myapp --no-pager
این فرمان وضعیت سرویس را نشان می‌دهد. اگر سرویس نصب نیست یا نام دیگری دارد، از روش مدیریت همان برنامه استفاده کنید. گزارش برنامه در زمان درخواست مشخص می‌کند آیا اتصال به آن رسیده و چرا رد شده است. اگر مقصد روی پورت محلی گوش نمی‌دهد، ابتدا خود برنامه، پورت و مسیر آن را اصلاح کنید؛ تغییر Nginx برنامه خاموش را روشن نمی‌کند.
آدرس 127.0.0.1 در پیکربندی زیر به همان میزبان Nginx اشاره دارد. اگر Nginx و برنامه در کانتینرهای جدا هستند، این آدرس ممکن است به کانتینر اشتباه اشاره کند؛ نام شبکه و مقصد را طبق معماری همان پروژه تعیین کنید.

۳. تنظیم مسیر پراکسی را اصلاح کنید

نمونه زیر باید داخل بلوک server مناسب قرار گیرد و فقط وقتی کاربرد دارد که برنامه شما در همان سرور، روی 127.0.0.1:3000 و مسیر /socket/ WebSocket ارائه کند. مسیر و پورت را با مستندات برنامه خود جایگزین کنید و تنظیمات TLS و سایر مسیرهای سایت را نگه دارید:
کد / دستورlocation /socket/ { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 120s; }
proxy_pass مقصد برنامه را تعیین می‌کند. دو سرآیند Upgrade و Connection درخواست تغییر پروتکل را به برنامه می‌رسانند. Host نام درخواستی را منتقل می‌کند و زمان انتظار خواندن را در این مثال افزایش داده‌ایم. چون در این نمونه proxy_pass مسیر اضافه‌ای ندارد، مسیر درخواست به شکل معمول به upstream منتقل می‌شود؛ اگر برنامه مسیر دیگری انتظار دارد، تنظیم را براساس راهنمای Nginx و برنامه تغییر دهید. این بلوک را جای کل پیکربندی موجود نگذارید.
از آنجا که پورت برنامه در این نمونه محلی است، نیازی به بازکردن عمومی پورت 3000 نیست. اعتبارسنجی هویت و Origin باید متناسب با برنامه انجام شود؛ سرآیند Upgrade به‌خودی‌خود مجوز دسترسی نمی‌دهد.

۴. پیش از اعمال، پیکربندی را آزمایش کنید

در ترمینال سرور اجرا کنید:
کد / دستورsudo nginx -t
پیام موفقیت نشان می‌دهد پیکربندی از نظر نحوی و فایل‌های لازم قابل قبول است. اگر خطا دریافت کردید، مسیر و شماره خط را بخوانید و نسخه قبلی را برگردانید؛ تا رفع خطا reload نکنید. پس از آزمون موفق و در زمان مناسب:
کد / دستورsudo systemctl reload nginx
این فرمان از systemd می‌خواهد تنظیمات Nginx را دوباره بخواند. در محیطی که Nginx داخل کانتینر یا با روش دیگری اجرا می‌شود، روش reload همان محیط را به کار ببرید. وضعیت سرویس و گزارش خطا را بعد از آن کنترل کنید.

۵. اتصال و پایداری را از مرورگر بسنجید

صفحه را تازه کنید و درخواست WS را دوباره ببینید. اگر 101 دریافت شد، یک پیام آزمایشی یا تغییر بی‌خطر در برنامه انجام دهید و پاسخ واقعی را ببینید. اگر بعد از مدتی بیکاری ارتباط قطع می‌شود، timeout همه لایه‌ها و پیام‌های نگه‌دارنده برنامه را بررسی کنید؛ زیادکردن یک timeout بدون شناسایی لایه قطع‌کننده کافی نیست. اگر 403 دارید، تنظیم Origin و مجوز برنامه را با آدرس واقعی مقایسه کنید. برای 502، وضعیت و نشانی upstream و گزارش Nginx را دنبال کنید.
جزئیات تنظیم ارتقای اتصال در مستندات رسمی Nginx آمده است. برای اجرای برنامه مستقل، منابع و دسترسی مدیریتی سرور مجازی ایران نت‌آرام را با نیاز خود بسنجید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام