Strona czatu się ładuje, ale połączenie na żywo zawodzi: gdzie szukać
Strona i transport czatu to różne żądania. Sprawdź WebSocket, strumień zdarzeń lub długie odpytywanie, a następnie rozdziel konfigurację, dostarczanie i czas życia.
Otwórz panel sieci, zanim wczytasz stronę czatu, a następnie znajdź żądanie, które przenosi wiadomości, a nie to, które rysuje szkielet strony. Dokument, skrypty, wymiana przy logowaniu i transport czatu mogą trafiać na różne hosty. Większość zgłoszeń, że VPN zepsuł czat, w rzeczywistości opisuje niepowodzenie jednego z tych czterech żądań. Obserwuj je po kolei, a odpowiedź zwykle widać w pierwszych dwóch minutach.
Znajdź żądanie, które przenosi wiadomości
Filtruj według typu, gdy strona się uspokoi: WebSocket pojawia się jako osobny wpis, strumień zdarzeń pozostaje otwarty z rosnącą odpowiedzią, a długie odpytywanie powtarza się w regularnym odstępie. Zapisz schemat, hosta, port i status tego, które przenosi aktualizacje. Zanotuj, czy zaczął się przed logowaniem, czy po nim, ponieważ transport otwarty przed uwierzytelnieniem to zwykle inna konstrukcja niż ten otwarty po. Czytaj nagłówki żądania uaktualnienia lub akceptowanego typu treści, ponieważ wskazują transport, który wdrożona strona naprawdę wybrała.
Stare wpisy na forach opisują transporty, z których produkty zrezygnowały lata temu, więc ufaj temu, co zapisała przeglądarka, a nie artykułowi. Jeśli wpisu w ogóle nie ma, kod klienta mógł nigdy nie spróbować połączenia, co wskazuje na wcześniejszy błąd skryptu lub konfiguracji. Wczytanie strony dowodzi tylko, że dokument dotarł, i właśnie ta różnica decyduje, czy w ogóle debugujesz sieć.
Konfiguracja, dostarczanie i czas życia zawodzą inaczej
WebSocket otwiera się uaktualnieniem HTTP, na które odpowiada status 101, a wszystko później to wiadomości w ramkach, a nie pobieranie stron; te dwa etapy RFC 6455 wyraźnie rozdziela. Strumień zdarzeń odpowiada strumieniowym typem treści i utrzymuje treść odpowiedzi otwartą. Oba mogą się nie otworzyć, otworzyć i niczego nie dostarczyć albo otworzyć, dostarczyć, a potem cicho umrzeć.
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
Złap pierwszy istotny błąd, zanim dotkniesz profilu, ponieważ te trzy momenty wskazują na różne warstwy. Jeśli uścisk dłoni nigdy się nie kończy, porównaj go ze zwykłym żądaniem HTTPS do tego samego hosta, aby zobaczyć, czy cokolwiek do niego dociera. Jeśli kończy się, a wiadomości nie przychodzą, obserwuj ramki lub treść strumienia, gdy ktoś wysyła wiadomość testową z innego konta. Jeśli działa, a potem się zatrzymuje, zapisz dokładny czas i kod zamknięcia, ponieważ ta para wskazuje, która strona się poddała.
Kod 1006 oznacza, że gniazdo zamknęło się bez ramki zamknięcia, a tak właśnie wygląda pośrednik lub limit bezczynności z wnętrza przeglądarki. Puls VPN nie dowodzi, że wewnętrzna sesja aplikacji nadal żyje.
Host na żywo to osobny cel
Zaplecza czatu często działają pod własną nazwą hosta, czasem na innym porcie lub za osobnym certyfikatem. Ten cel wymaga własnego rozwiązania nazwy, trasy i obsługi przez proxy, a tunelowanie dzielone może obejmować stronę i wykluczać gniazdo. Rozwiąż nazwę hosta na żywo z maszyny klienta i potwierdź, że odpowiada adresem oczekiwanym w tej sieci. Sprawdź łańcuch certyfikatów specjalnie dla tej nazwy hosta, ponieważ symbol wieloznaczny obejmujący witrynę nie zawsze obejmuje punkt końcowy gniazda.
Jeśli na ścieżce stoi proxy, potwierdź, że pozwala na uaktualnienie lub długotrwałą odpowiedź, zamiast ją buforować. Firmowe proxy przepisujące HTML często źle obsługują uaktualnienia WebSocket, co daje stronę, która się rysuje, podczas gdy czat nigdy się nie łączy. Dwa żądania do tego samego produktu nie są więc dwoma żądaniami do tego samego hosta.
Napraw listę celów, a nie kontrole bezpieczeństwa
Naprawa listy celów to zmiana trasowania i należy do właściciela trasy. Poluzowanie walidacji certyfikatów lub usunięcie nagłówka Origin to zmiana bezpieczeństwa i należy do właściciela polityki, którym rzadko jest osoba debugująca zgłoszenie. Najszybszy sposób, by połączenie wyglądało na udane, to zwykle najszybszy sposób, by incydent stał się możliwy.
Zapytaj właściciela aplikacji, jakie źródła akceptuje zaplecze, zanim cokolwiek zmienisz, i przekaż tę odpowiedź osobie zarządzającej proxy. Jeśli błąd certyfikatu pojawia się tylko przez tunel, sprawdź urządzenie przechwytujące, zamiast instalować obejście.
Zapisz tyle, by można było przekazać sprawę
Przydatny artefakt jest krótki: adres URL strony, punkt końcowy na żywo, wynik uścisku dłoni, czas pierwszego błędu i czy podjęto próbę ponownego połączenia. Dodaj nazwę profilu VPN i sieć, w której byłeś, a każdy czytający odtworzy test bez zadawania sześciu pytań. Zamaskuj pliki cookie, nagłówki autoryzacji i treść wiadomości, i wybierz zrzut ekranu kolumny czasów zamiast pełnego eksportu archiwum. Ramki i archiwa sieci mogą zawierać prywatne wiadomości i tokeny sesji, więc sprawdź je przed dołączeniem czegokolwiek.
Jeśli błąd to ciche zamknięcie, dołącz kod zamknięcia i poprzedzający go okres bezczynności, ponieważ ta para zwykle wskazuje właściciela limitu czasu. Przekaż zapis właścicielowi aplikacji lub bramy, zamiast samodzielnie zgadywać wartość limitu. Ich odpowiedź o obsługiwanym zachowaniu keepalive jest tą, która zamyka zgłoszenie.