Wolne żądania Squida z awaryjnym rewriterem URL
Zbadaj pomocnik przepisywania URL, gdy proxy przyjmuje połączenia, ale żądania zatrzymują się przed przekazaniem dalej.
Jeśli Squid przyjmuje połączenia, ale długo wysyła żądania dalej, sprawdź każdy rewriter URL na tej ścieżce. W Squidzie 5–7 url_rewrite_program wskazuje zewnętrzny program wywoływany po wstępnych kontrolach dostępu. Może on opóźnić żądanie, zanim dotrze ono do celu.
- Odczytaj faktycznie używane polecenie przepisywania, wraz z nakładką i argumentami.
- Powiąż dotkniętą transakcję z diagnostyką pomocnika. Powtarzające się wyjścia procesów potomnych, zniekształcone odpowiedzi i rosnąca kolejka to odrębne tropy.
- Sprawdź, czy awaria zależy od jednego wzorca URL. Zachowaj zredagowany przykład tych danych wejściowych, zamiast zmieniać niepowiązane ustawienia resolvera.
Pomocnik ma liniowy kontrakt żądania i odpowiedzi. Tekst postępu nakładki na standardowym wyjściu może go zepsuć. Udane uruchomienie skryptu jako administrator także nie odtwarza strumienia wejściowego, środowiska ani uprawnień Squida. Ta ścieżka jest odrębna od weryfikacji hasła.
Dopiero gdy wymiana działa, można traktować to jako problem wydajności. url_rewrite_children steruje procesami i zachowaniem kolejki, ale więcej procesów potomnych nie naprawi awarii wywołanych danymi wejściowymi. Opcja współbieżności wprowadza identyfikatory kanałów i wymaga pomocnika realizującego taką rozmowę.
Autoryzowane porównanie bez rewritera pozwala wyizolować jego wkład. Pozostawienie go pominiętego przy przeciążeniu może zmienić routing lub filtrowanie, które wymusza, więc to decyzja polityki. Porównaj zaobserwowane oczekiwanie pomocnika z dowodami DNS i dalszego połączenia, zanim przypiszesz całe opóźnienie latencji sieci.