صفحه چت بارگذاری میشود اما اتصال زنده شکست میخورد: کجا را نگاه کنیم
صفحه و انتقال چت دو درخواست متفاوتاند. WebSocket، جریان رویداد یا نظرسنجی طولانی را بررسی کنید، سپس راهاندازی، تحویل و عمر را از هم جدا کنید.
پیش از بارگذاری صفحه چت، پنل شبکه را باز کنید و سپس درخواستی را بیابید که پیامها را حمل میکند، نه آن که پوسته را ترسیم میکند. سند، اسکریپتها، تبادل ورود و انتقال چت میتوانند همه به میزبانهای متفاوت بروند. بیشتر گزارشهایی که میگویند VPN چت را خراب کرد، در واقع شکست یکی از آن چهار درخواست را توصیف میکنند. آنها را به ترتیب دنبال کنید و پاسخ معمولاً در دو دقیقه نخست دیده میشود.
درخواستی را پیدا کنید که پیامها را حمل میکند
وقتی صفحه آرام شد بر اساس نوع فیلتر کنید: WebSocket بهعنوان یک ورودی جداگانه ظاهر میشود، جریان رویداد با پاسخ روبهرشد باز میماند و نظرسنجی طولانی در فاصله منظم تکرار میشود. طرح، میزبان، درگاه و وضعیت آن را که بهروزرسانیها را حمل میکند ثبت کنید. توجه کنید که پیش از ورود آغاز شد یا پس از آن، زیرا انتقالی که پیش از احراز هویت باز میشود معمولاً طراحی متفاوتی از یکی دارد که پس از آن باز میشود. سرآیندهای درخواست ارتقا یا نوع محتوای پذیرفتهشده را بخوانید، زیرا آنها انتقالی را مشخص میکنند که صفحه مستقرشده واقعاً برگزیده است.
پستهای قدیمی انجمن انتقالهایی را توصیف میکنند که محصولات سالها پیش کنار گذاشتند، پس به آنچه مرورگر ثبت کرده اعتماد کنید نه به مقاله. اگر ورودی کاملاً غایب باشد، ممکن است کد کلاینت هرگز اتصالی را امتحان نکرده باشد، که به شکست زودتر یک اسکریپت یا پیکربندی اشاره دارد. صفحهای که بارگذاری میشود تنها ثابت میکند سند رسیده است، و همین تمایز تعیین میکند که اصلاً شبکه را اشکالزدایی میکنید یا نه.
راهاندازی، تحویل و عمر به شکلهای متفاوت شکست میخورند
WebSocket با ارتقای HTTP باز میشود که با وضعیت 101 پاسخ داده میشود، و همه چیز پس از آن پیامهای قاببندیشده است نه واکشی صفحه، دو مرحلهای که RFC 6455 آنها را صریحاً جدا نگه میدارد. جریان رویداد با نوع محتوای جریانی پاسخ میدهد و بدنه پاسخ را باز نگه میدارد. هر دو میتوانند در باز شدن شکست بخورند، باز شوند و چیزی تحویل ندهند، یا باز شوند، تحویل دهند و سپس بیصدا بمیرند.
wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events
نخستین شکست معنادار را پیش از دست زدن به هر پروفایلی ثبت کنید، زیرا سه زمانبندی به لایههای متفاوت اشاره میکنند. اگر دستدادن هرگز کامل نشود، آن را با یک درخواست ساده HTTPS به همان میزبان مقایسه کنید تا ببینید اصلاً چیزی به آن میرسد. اگر کامل شود و پیامی نرسد، در حالی که کسی از حساب دیگری پیام آزمایشی میفرستد قابها یا بدنه جریان را تماشا کنید. اگر کار کند و سپس متوقف شود، زمان دقیق و کد بستن را یادداشت کنید، زیرا همان جفت مشخص میکند کدام سمت تسلیم شده است.
کد 1006 یعنی سوکت بدون قاب بستن بسته شد، که همان چیزی است که یک واسطه یا یک مهلت بیکاری از داخل مرورگر به نظر میرسد. ضربان VPN ثابت نمیکند که نشست درونی برنامه هنوز زنده است.
میزبان زنده یک مقصد جداگانه است
بکاندهای چت غالباً روی نام میزبان خودشان زندگی میکنند، گاهی روی درگاهی متفاوت یا پشت گواهی جداگانه. آن مقصد به حل، مسیر و رفتار پراکسی خودش نیاز دارد، و تونلسازی تقسیمشده میتواند صفحه را شامل شود و سوکت را کنار بگذارد. نام میزبان زنده را از ماشین کلاینت حل کنید و تأیید کنید که با نشانی که در آن شبکه انتظار دارید پاسخ میدهد. زنجیره گواهی را بهطور خاص برای همان نام میزبان بررسی کنید، زیرا یک گواهی عام که سایت را پوشش میدهد همیشه نقطه پایانی سوکت را پوشش نمیدهد.
اگر پراکسی در مسیر است، تأیید کنید که ارتقا یا پاسخ دیرپا را مجاز میکند و آن را بافر نمیکند. پراکسیهای سازمانی که HTML را بازنویسی میکنند اغلب ارتقاهای WebSocket را بد مدیریت میکنند، که صفحهای را پدید میآورد که نمایش داده میشود در حالی که چت هرگز وصل نمیشود. بنابراین دو درخواست به یک محصول، دو درخواست به یک میزبان نیست.
فهرست مقصدها را درست کنید، نه بررسیهای امنیتی
درست کردن فهرست مقصدها یک تغییر مسیریابی است و به کسی تعلق دارد که مسیر را در اختیار دارد. شل کردن اعتبارسنجی گواهی یا حذف سرآیند Origin یک تغییر امنیتی است و به کسی تعلق دارد که سیاست را در اختیار دارد، که بهندرت همان کسی است که بلیت را اشکالزدایی میکند. سریعترین راه برای ظاهر کردن یک اتصال معمولاً سریعترین راه برای ممکن کردن یک رخداد است.
پیش از تغییر هر چیزی از مالک برنامه بپرسید بکاند کدام مبدأها را میپذیرد، و آن پاسخ را به کسی بدهید که پراکسی را کنترل میکند. اگر خطای گواهی فقط از طریق تونل ظاهر میشود، دستگاه رهگیر را بررسی کنید نه اینکه یک دور زدن نصب کنید.
به اندازه کافی برای تحویل ثبت کنید
سند مفید کوتاه است: نشانی صفحه، نقطه پایانی زنده، نتیجه دستدادن، زمان نخستین شکست، و اینکه آیا اتصال دوباره امتحان شده است. نام پروفایل VPN و شبکهای را که در آن بودید اضافه کنید، و هر خواننده میتواند آزمون را بدون پرسیدن شش پرسش تکرار کند. کوکیها، سرآیندهای مجوز و بدنه پیامها را پنهان کنید، و اسکرینشات ستون زمانبندی را به خروجی کامل آرشیو ترجیح دهید. قابها و آرشیوهای شبکه میتوانند پیامهای خصوصی و نشانههای نشست داشته باشند، پس پیش از پیوست کردن هر چیزی بررسی کنید.
اگر شکست یک بستن بیصدا است، کد بستن و فاصله بیکاری پیش از آن را وارد کنید، زیرا آن جفت معمولاً صاحب مهلت را مشخص میکند. سند را به مالک برنامه یا دروازه بدهید نه اینکه خودتان مقدار مهلت را حدس بزنید. پاسخ آنها درباره رفتار حفظ اتصال پشتیبانیشده همان چیزی است که بلیت را میبندد.