Niewiele rzeczy w IPTV potrafi tak wkurzyć, jak wklejenie nazwy użytkownika i hasła, o których wiesz, że są poprawne, i patrzenie, jak odtwarzacz zwraca „Authentication Failed”. Dwa fakty pogarszają sprawę:
- Ten sam komunikat błędu pochodzi od co najmniej ośmiu różnych przyczyn, z których kilka w ogóle nie ma związku z twoimi danymi logowania.
- Odtwarzacze prawie nigdy nie mówią, która to z nich.
Ten przewodnik przeprowadzi cię przez nie w kolejności, w jakiej warto je sprawdzać. Jeśli wkleisz dane logowania do weryfikatora danych Xtream jeszcze przed startem, pierwsze trzy kroki załatwiają się automatycznie — narzędzie powie ci, czy uwierzytelnienie faktycznie się nie udało, wygasło, czy trafiło na limit połączeń.
Jeden komunikat błędu, osiem przyczyn — odtwarzacz nie umie ich odróżnić, więc diagnostyka spada na ciebie.
1. Subskrypcja wygasła
To najczęstsza przyczyna, a w większości odtwarzaczy wygląda dokładnie tak samo jak złe hasło. Xtream w obu przypadkach zwraca tę samą odpowiedź auth: 0.
Rozwiązanie: poproś dostawcę o nową datę wygaśnięcia — albo, jeśli już przedłużyłeś, odczekaj godzinę i spróbuj ponownie. Niektóre panele dostawców aktualizują bazę według harmonogramu, a nie w czasie rzeczywistym, więc świeżo przedłużone konto może być raportowane jako wygasłe nawet przez pół godziny od zaksięgowania płatności.
Weryfikator danych zwróci w tym przypadku auth: expired, więc wykluczysz to jednym kliknięciem.
2. Limit połączeń jest wyczerpany
Większość subskrypcji Xtream sprzedaje się z limitem połączeń — zwykle 1, 2, 3 albo 5 jednoczesnych. Jeśli wszystkie są zajęte, nowa próba logowania jest odrzucana z tym samym błędem uwierzytelnienia, co złe hasło.
Pułapka: połączenie nie zawsze faktycznie streamuje. Odtwarzacze wychodzące bez czystego rozłączenia (większość tak robi) potrafią zostawić „duchowe” połączenie, które dostawca sprząta dopiero po timeoucie. Jeśli niedawno zmieniałeś urządzenie, restartowałeś TV albo padło ci Wi-Fi i się wznowiło, jest prawdopodobne, że wszystkie sloty są zajęte przez duchy, które nic nie streamują.
Rozwiązanie: odczekaj 5–10 minut, aż zadziała timeout po stronie serwera, i spróbuj ponownie. Albo skontaktuj się z dostawcą i poproś o wyczyszczenie aktywnych połączeń na twoim koncie.
3. W nazwie użytkownika jest ukryty biały znak
Wklejanie danych z maila, forum czy zrzutu ekranu często wciąga niewidoczne znaki: początkową spację, końcowy znak nowej linii, twardą spację (U+00A0) tam, gdzie użytkownikowi wydawało się, że wpisał zwykłą. Większość odtwarzaczy ich nie obcina, a nazwa użytkownika z jednym końcowym znakiem nowej linii to z perspektywy dostawcy zupełnie inna nazwa.
Sprawdź, wklejając nazwę użytkownika i hasło do zwykłego edytora tekstu. Przesuń kursor na sam koniec każdego z nich. Jeśli możesz nacisnąć backspace i skasować niewidoczny znak, zanim kursor stanie na końcu widocznego tekstu — masz swój problem.
Weryfikator danych jawnie obcina białe znaki z serwera i nazwy użytkownika, zanim wyśle je dalej, więc jeśli on się powiedzie tam, gdzie twój odtwarzacz padł, to prawie na pewno ta przyczyna.
4. URL serwera ma końcową ścieżkę lub nadmiarowe parametry
Xtream Codes woła jeden endpoint pod /player_api.php. Twój odtwarzacz buduje pełny URL, doklejając tę ścieżkę do tego, co wpisałeś w pole „serwer”. Jeśli wkleiłeś tam pełny URL M3U (http://server.example/get.php?username=…&password=…&type=m3u_plus) zamiast samego http://server.example, odtwarzacz w efekcie woła /get.php?username=…&password=…&type=m3u_plus/player_api.php?…, na co każdy serwer odpowie albo 404, albo HTML-em. Odtwarzacz raportuje wtedy „auth failed”, bo nie dostał JSON-a.
Rozwiązanie: skróć URL do samego http(s)://host:port. Nazwa użytkownika i hasło idą do osobnych pól. Wielu użytkowników przynajmniej raz wkleiło URL M3U do pola serwera.
5. Serwer jest na HTTPS, ale łańcuch certyfikatu jest zepsuty
Niektórzy dostawcy stawiają swoje API Xtream na certyfikacie self-signed albo wygasłym. Większość nowoczesnych odtwarzaczy odmawia rozmowy po HTTPS z serwerem o nieprawidłowym certyfikacie, ale starsze potrafią po cichu zejść do HTTP i wtedy padają, bo dostawca w zeszłym kwartale przestał serwować po HTTP.
Diagnostyka: otwórz URL serwera w przeglądarce na komputerze. Jeśli widzisz ostrzeżenie o certyfikacie, odtwarzacz też się o nie obija. Rozwiązanie: zmień URL serwera z https://… na http://…, oczywiście z zastrzeżeniem, że hasło leci wtedy bez szyfrowania. Naciśnij dostawcę, żeby odnowił certyfikat; to ich problem, nie twój.
6. Twoje IP jest blokowane
Dostawcy regularnie geo-blokują ruch z krajów, w których nie mają umów, albo rate-limitują na poziomie IP, gdy konto otwiera za dużo połączeń w krótkim oknie. Z perspektywy odtwarzacza obie sytuacje wyglądają identycznie: odpowiedź „auth failed”.
Sprawdź, próbując tych samych danych z innej sieci — z telefonu jako hotspota, z innego Wi-Fi albo z VPN-a do innego kraju. Jeśli dane działają gdzie indziej, ale nie z twojego domowego łącza, problem leży w twoim IP.
Weryfikator danych woła API po stronie serwera z ustalonego IP, więc rozjazd „weryfikator mówi tak, mój odtwarzacz mówi nie” potwierdza, że problem jest w IP klienta, a nie w danych logowania.
7. Baza dostawcy jest w trakcie konserwacji / migracji
Okresowe migracje u dostawcy potrafią rozwalić login Xtream na godziny. Objawy: wszystkie konta Xtream u tego samego dostawcy zwracają jednocześnie „auth failed”. Nie odróżnisz tego od cofnięcia twoich własnych danych logowania inaczej niż czekaniem i kolejnymi próbami albo zapytaniem na forum, gdzie inni klienci tego samego dostawcy to zauważyli.
Jeśli oprócz danych Xtream masz też URL M3U (większość dostawców daje obie formy), M3U często działa w trakcie migracji, bo jest serwowane z innej ścieżki kodu. Przełączenie się na URL M3U to szybkie obejście do czasu, aż API wróci.
8. Dane logowania naprawdę są błędne
Nudny przypadek, ale wciąż realny. Dostawca je unieważnił. Dostawca je zrotował po incydencie z płatnością. Używasz danych z zeszłego miesiąca, a przy przedłużeniu dostałeś nowe.
Jak to poznać: zaloguj się do panelu klienta u swojego dostawcy (prawie każdy dostawca Xtream taki ma) i skopiuj do formularza dane logowania pokazane tam. Jeśli te działają, a używane przez ciebie nie — masz odpowiedź.
Jak wpisuje się w to weryfikator danych
Weryfikator danych Xtream na tej stronie automatycznie odróżnia przypadki 1, 2 i 8 (te najczęstsze):
auth: ok+ liczby w głównym panelu → dane są dobre. Problem siedzi w twoim odtwarzaczu albo sieci — sprawdź przypadki 4–7.auth: expired→ przypadek 1. Odnów subskrypcję lub skontaktuj się z dostawcą.auth: failed→ przypadek 8. Dane logowania są faktycznie złe.- Ostrzeżenie o limicie połączeń → przypadek 2. Poczekaj albo poproś dostawcę o wyczyszczenie połączeń.
upstream_timeout/upstream_unreachable→ przypadek 6 albo 7. Sam serwer jest nieosiągalny z publicznego IP, więc problem w ogóle nie dotyczy uwierzytelniania.
Jedno uruchomienie weryfikatora przed debugowaniem odtwarzacza oszczędza średnio jakieś dwadzieścia minut grzebania. Wyklucza też w całości pytanie „czy dostawca leży” — jeśli nasz serwer się dogada z ich, to ich serwer stoi.
Co zrobić, kiedy znasz już przyczynę
Dla danych, które naprawdę działają (przypadki 1–7, w których namierzyłeś już sposób na obejście), Klipa obsługuje login Xtream i URL M3U obok siebie w tej samej bibliotece. Jeśli API Xtream u twojego dostawcy bywa zawodne, ale eksport M3U jest zdrowy, dodaj oba — jedno utrzymuje listę kanałów przy życiu, gdy drugie pada. Zobacz porównanie Xtream z M3U, by zdecydować, który interfejs postawić na pierwszym miejscu.
Jeśli przeszedłeś przez wszystkie osiem przypadków, a dane logowania nigdzie nie działają — także w weryfikatorze, w panelu klienta i z innej sieci — problem jest po stronie dostawcy i nic więcej z twojej strony nie zdiagnozujesz.