Przewodnik rozwiązywania problemów z przesyłaniem dużych zdjęć i filmów przez odwrotne proxy

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Reverse Proxy Upload Troubleshooting Guide for Large Photos and Videos - Zima Store Online

Bezpieczne podejście polega na potraktowaniu kontrolowanego testu rozmiaru i czasu, który identyfikuje wadliwą warstwę przed zmianą limitów, buforowania lub ustawień sieci, jako sekwencji obserwowalnych etapów, a nie pojedynczego polecenia.

W przypadku samodzielnie hostowanej aplikacji do zdjęć lub multimediów działającej za jednym lub kilkoma serwerami proxy praktyczne ryzyko polega na tym, że małe przesyłane pliki kończą się powodzeniem, natomiast duże zdjęcia lub filmy kończą się niepowodzeniem, są resetowane albo przekraczają limit czasu przez odwrotny serwer proxy. Zapisz bieżącą tożsamość i punkt przywracania, zacznij od najmniej inwazyjnego testu rozróżniającego, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby ujawniona. Poniższy proces kończy się dopiero po pomyślnym wykonaniu pierwotnego zadania albo po osiągnięciu przez dowody granicy eskalacji.

Odtwórz jedno przesyłanie z użyciem drabiny rozmiarów

Użyj jednego klienta, konta, połączenia sieciowego, hosta i typu pliku. Prześlij mały plik kontrolny, a następnie coraz większe pliki testowe, zapisując dokładną liczbę bajtów, czas trwania, błąd przeglądarki, status HTTP, znaczniki czasu wpisów dostępu i błędów proxy, logi aplikacji oraz informację, czy pojawia się jakikolwiek częściowy obiekt.

Jeśli jest dostępny zaufany bezpośredni punkt końcowy aplikacji, przetestuj przez niego ten sam największy plik. Jeśli przesyłanie bezpośrednie kończy się powodzeniem, a przez proxy nie, problem dotyczy ścieżki proxy; jeśli oba warianty kończą się niepowodzeniem przy tym samym rozmiarze lub etapie, przed zmianą konfiguracji proxy sprawdź działanie aplikacji, pamięci masowej lub klienta.

Nie zwiększaj jednocześnie wszystkich limitów rozmiaru i czasu. Zachowaj bieżącą konfigurację i odczyty wolnego miejsca oraz przerwij, jeśli testowanie zapełnia wolumin danych aplikacji lub ujawnia niezabezpieczony punkt końcowy backendu.

Odróżnij odrzucenie z powodu rozmiaru od niepowodzenia wskutek upływu czasu

Natychmiastowy status 413 lub odrzucenie przy powtarzalnym progu liczby bajtów wskazuje na politykę rozmiaru treści w pierwszej warstwie zwracającej ten status. Status 408, 499, 502, 504 lub reset połączenia po powtarzalnym czasie wskazuje raczej na limit czasu klienta, proxy, serwera nadrzędnego, tunelu lub aplikacji.

Przypadek społeczności Traefik dotyczący problemu z limitem czasu podczas dużych przesyłań pokazuje, dlaczego znaczenie ma czas trwania i kompletna ścieżka od proxy do aplikacji: duże przesyłanie może zakończyć się niepowodzeniem przez tunel, nawet gdy zwykłe zdjęcia i przeglądanie działają. Traktuj ten przypadek jako sygnaturę diagnostyczną, a nie uniwersalną wartość limitu czasu.

Określ każdą warstwę, która może wymuszać limity: CDN lub tunel, proxy brzegowe, proxy uwierzytelniania, proxy aplikacji, serwer aplikacji, środowisko uruchomieniowe i punkt końcowy przesyłania. Pierwsza warstwa, która rejestruje lub zwraca błąd, wyznacza następny test.

Sprawdź buforowanie, pamięć tymczasową i transport

Podczas przesyłania kontrolowanego pliku obserwuj katalogi tymczasowe proxy, zapisywalne warstwy kontenerów, ścieżki przesyłania aplikacji, pojemność systemu plików, dostępność i-węzłów oraz pamięć. Buforowanie może zużywać miejsce na dysku lub pamięć, zanim aplikacja otrzyma treść, dlatego duży wolumin biblioteki końcowej nie dowodzi, że proxy ma przestrzeń roboczą.

Raport Nextcloud i Traefik dotyczący wielowarstwowego problemu z dużymi przesyłanymi plikami pokazuje, jak ten sam objaw związany z dużym plikiem może obejmować warstwy sieci, aplikacji i proxy. Wykorzystaj wniosek dotyczący wielu warstw, ale powiąż zmianę ze statusem, znacznikiem czasu w logu i zasobem, który faktycznie ulega awarii.

Jeśli błędy są zmienne i nie wyznaczają granicy rozmiaru ani czasu, porównaj trasy przez Ethernet, Wi-Fi, VPN i bezpośrednią sieć LAN. Zachowaj jedną stabilną trasę i osobno przetestuj MTU, utratę pakietów oraz działanie tunelu, zamiast zwiększać limity aplikacji, aby maskować resety transportu.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zastosuj jedną dopasowaną poprawkę i powtórz pierwotne przesyłanie

Zmień tylko potwierdzoną granicę: zakresowy limit rozmiaru treści, konkretny limit czasu żądania lub odpowiedzi, tryb buforowania albo przydział pamięci tymczasowej. Pozostaw bez zmian uwierzytelnianie, TLS i niezwiązane wirtualne hosty, następnie przeładuj proxy i sprawdź aktywną konfigurację.

Proces ZimaSpace dotyczący testu ścieżki bezpośredniej i przez proxy pokazuje, jak porównanie tych ścieżek pomaga odizolować problem z proxy po ponownym uruchomieniu. Zastosuj tutaj tę samą granicę, następnie dwukrotnie prześlij dokładnie ten sam duży plik i sprawdź jego końcowy rozmiar, sumę kontrolną, jeśli jest dostępna, przetwarzanie metadanych oraz usunięcie plików tymczasowych.

Uruchom proxy ponownie raz i powtórz przesyłanie z pierwotnej zdalnej ścieżki. Zamknij incydent dopiero wtedy, gdy małe i duże pliki przesyłają się pomyślnie bez nowego narażenia ani presji na pamięć masową; wycofaj zmianę, jeśli modyfikacja limitu wpływa na inne hosty, i eskaluj sprawę, podając dowody dotyczące statusu, czasu, warstwy i zasobów, gdy nie da się powtarzalnie wskazać żadnej granicy.