Naglo-load ang pahina ng chat pero nabigo ang live na koneksyon: saan titingin

Buksan ang panel ng network bago i-load ang pahina ng chat, pagkatapos hanapin ang kahilingang nagdadala ng mga mensahe at hindi ang nagguguhit ng balangkas ng pahina. Ang dokumento, mga script, ang palitan sa pag-sign in at ang transport ng chat ay maaaring pumunta sa magkaibang host. Karamihan ng ulat na sinira ng VPN ang chat ay talagang naglalarawan ng pagbigo ng isa sa apat na kahilingang iyon. Panoorin sila nang sunod-sunod at karaniwang makikita ang sagot sa unang dalawang minuto.

Hanapin ang kahilingang nagdadala ng mga mensahe

Salain ayon sa uri kapag huminahon na ang pahina: lumalabas ang WebSocket bilang sariling entry, nananatiling bukas ang stream ng mga pangyayari na may lumalaking tugon, at umuulit ang mahabang poll sa regular na agwat. Itala ang scheme, host, port at status para sa nagdadala ng mga update. Pansinin kung nagsimula ito bago o pagkatapos ng pag-sign in, dahil ang transport na binuksan bago ang pagpapatotoo ay karaniwang ibang disenyo kaysa sa binuksan pagkatapos. Basahin ang mga header ng kahilingan para sa kahilingan ng upgrade o sa tinanggap na uri ng nilalaman, dahil tinutukoy nila ang transport na aktwal na pinili ng naka-deploy na pahina.

Inilalarawan ng lumang mga post sa forum ang mga transport na iniwan ng mga produkto maraming taon na, kaya magtiwala sa naitala ng browser at hindi sa artikulo. Kung wala nang lubusan ang entry, maaaring hindi kailanman sinubukan ng code ng kliyente ang isang koneksyon, na tumuturo sa naunang pagbigo ng script o configuration. Ang paglo-load ng pahina ay nagpapatunay lamang na dumating ang dokumento, at ang pagkakaibang iyon ang nagtatakda kung nagde-debug ka talaga ng network.

Nabigo nang iba ang setup, paghahatid at tagal

Ang WebSocket ay bumubukas sa isang HTTP upgrade na sinasagot ng status 101, at lahat ng sumusunod ay mga mensaheng may frame at hindi pagkuha ng pahina, dalawang yugtong tahasang pinaghihiwalay ng RFC 6455. Ang stream ng mga pangyayari ay sumasagot sa isang streaming na uri ng nilalaman at pinananatiling bukas ang katawan ng tugon. Pareho silang maaaring mabigong bumukas, bumukas at walang maihatid, o bumukas, maghatid at pagkatapos ay tahimik na mamatay.

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

Hulihin ang unang makabuluhang pagbigo bago hawakan ang isang profile, dahil ang tatlong panahon ay tumuturo sa magkaibang antas. Kung hindi kailanman natapos ang handshake, ihambing ito sa ordinaryong kahilingang HTTPS sa parehong host para makita kung may nakakarating doon. Kung natapos ito at walang dumarating na mensahe, panoorin ang mga frame o ang katawan ng stream habang may nagpapadala ng test na mensahe mula sa ibang account. Kung gumagana ito at pagkatapos ay huminto, itala ang eksaktong oras at ang close code, dahil tinutukoy ng pares na iyon kung aling dulo ang sumuko.

Ang code 1006 ay nangangahulugang nagsara ang socket nang walang close frame, at ganoon ang hitsura ng isang middlebox o idle timeout mula sa loob ng browser. Ang heartbeat ng VPN ay hindi nagpapatunay na buhay pa ang panloob na sesyon ng aplikasyon.

Ang live na host ay hiwalay na destinasyon

Ang mga backend ng chat ay madalas nakatira sa sariling hostname, kung minsan sa ibang port o sa likod ng hiwalay na sertipiko. Kailangan ng destinasyong iyon ng sariling resolusyon, ruta at paghawak ng proxy, at ang split tunnelling ay maaaring isama ang pahina habang inaalis ang socket. I-resolve ang live na hostname mula sa kliyenteng makina at tiyakin na sumasagot ito sa address na inaasahan mo sa network na iyon. Suriin ang kadena ng sertipiko partikular para sa hostname na iyon, dahil ang wildcard na sumasaklaw sa site ay hindi laging sumasaklaw sa endpoint ng socket.

Kung may proxy sa landas, tiyakin na pinapayagan nito ang upgrade o ang pangmatagalang tugon sa halip na i-buffer ito. Ang mga corporate proxy na nagre-rewrite ng HTML ay madalas na hindi maganda ang paghawak sa mga upgrade ng WebSocket, na nagdudulot ng pahinang naguguhit habang hindi kailanman kumokonekta ang chat. Kaya ang dalawang kahilingan sa parehong produkto ay hindi dalawang kahilingan sa parehong host.

Ayusin ang listahan ng destinasyon, hindi ang mga pagsusuring panseguridad

Ang pag-aayos ng listahan ng destinasyon ay pagbabago sa routing at pag-aari ng may-ari ng ruta. Ang pagluwag sa validation ng sertipiko o pagtatanggal ng Origin header ay pagbabago sa seguridad at pag-aari ng may-ari ng patakaran, na bihirang ang taong nagde-debug ng ticket. Ang pinakamabilis na paraan para magmukhang matagumpay ang isang koneksyon ay karaniwang ang pinakamabilis na paraan para maging posible ang isang insidente.

Tanungin ang may-ari ng aplikasyon kung aling mga pinagmulan ang tinatanggap ng backend bago magbago ng anuman, at ipasa ang sagot na iyon sa kumokontrol ng proxy. Kung lumalabas ang error sa sertipiko sa pamamagitan lamang ng tunnel, siyasatin ang device na nanghihimasok sa halip na mag-install ng bypass.

Itala ang sapat para maipasa

Ang kapaki-pakinabang na artifact ay maikli: URL ng pahina, live na endpoint, resulta ng handshake, oras ng unang pagbigo at kung sinubukan ang muling pagkonekta. Idagdag ang pangalan ng profile ng VPN at ang network kung saan ka naroon, at kahit sino ang magbasa nito ay maaaring ulitin ang test nang hindi nagtatanong ng anim na katanungan. Itago ang cookies, authorization header at katawan ng mensahe, at piliin ang screenshot ng column ng oras kaysa sa buong export ng archive. Ang mga frame at network archive ay maaaring maglaman ng pribadong mensahe at session token, kaya suriin bago mag-attach ng anuman.

Kung ang pagbigo ay tahimik na pagsasara, isama ang close code at ang idle interval bago ito, dahil karaniwang tinutukoy ng pares na iyon ang may-ari ng timeout. Ipaubaya ang talaan sa may-ari ng aplikasyon o gateway sa halip na hulaan mo mismo ang halaga ng timeout. Ang sagot nila tungkol sa sinusuportahang pag-uugali ng keepalive ang sagot na nagsasara ng ticket.