LOKALNE TWORZENIE · PRAKTYCZNE TESTY
Udostępnij localhost: testy na telefonie i webhooki
Strona działa na Twoim komputerze. Tymczasowy link HTTPS pozwoli wejść na nią z telefonu, klientowi lub usłudze webhooków, bez wdrożenia.
Przed udostępnieniem sprawdź lokalny adres
Sprawdź adres wyświetlany przez serwer deweloperski. Protokół i port mają znaczenie: http://localhost:5173 i https://localhost:7143 to różne cele. Otwórz dokładny adres na komputerze i wykonaj typową czynność przed utworzeniem tunelu.
Jedna aplikacja, jeden port
Jeśli strona i API używają tego samego lokalnego adresu, jeden tunel dotrze do obu. Ścieżki pozostają bez zmian: publiczne żądanie /contact dociera do /contact w aplikacji. Tunel nie kopiuje ani nie wdraża plików.
Frontend i API na różnych portach
Tunel do frontendu nie publikuje automatycznie API na innym porcie. Przeglądarka wywołująca localhost:3000 połączy się z urządzeniem odwiedzającego. Użyj proxy API serwera deweloperskiego lub dostępnego adresu testowego API i dostosuj frontend.
Utwórz publiczny link
Uruchom stronę lub API i sprawdź dostęp lokalny. GhostlyShare automatycznie wykrywa działające lokalne aplikacje webowe. Kliknij Go Public, aby utworzyć publiczny link HTTPS.
- Podczas testu pozostaw aplikację i GhostlyShare uruchomione.
- Przed udostępnieniem otwórz link w oknie prywatnym.
- Używaj danych testowych. W razie potrzeby ustaw hasło do prywatnego podglądu dla klienta.
Windows i Linux. Darmowe linki tymczasowe bez konta, adresu e-mail i abonamentu.
Pobierz GhostlyShare ↗
Otwórz publiczny adres na komputerze i innym urządzeniu. Jeśli strona lokalna działa, a publiczna nie, zachowaj oba adresy, by odróżnić błąd aplikacji od problemu z tunelem lub konfiguracją hosta.
Otwórz localhost na telefonie
Na telefonie localhost oznacza sam telefon, a nie komputer. Otwórz publiczny link lub zeskanuj kod QR w GhostlyShare.
- Przełącz się na transmisję komórkową, aby sprawdzić dostęp spoza Wi-Fi.
- Sprawdź menu, formularze, klawiaturę i przesyłanie plików na prawdziwym urządzeniu.
- Otwórz podstronę bezpośrednio i odśwież ją. Sprawdź też obrazy i odpowiedzi API.
Testujesz tylko w tej samej sieci Wi-Fi? Lokalny adres sieciowy komputera może wystarczyć, jeśli serwer deweloperski i zapora pozwalają na dostęp. Publiczny tunel przydaje się w innych sieciach i dla usług zewnętrznych.
Przydatny pięciominutowy test na telefonie
- Nawigacja i układ
- Otwórz menu, obróć telefon i odwiedź długą stronę. Szukaj przewijania poziomego, zasłoniętych przycisków i treści pod stałym nagłówkiem. Emulacja przeglądarki pomaga, ale nie odtwarza każdej interakcji z urządzeniem.
- Formularze i sesja
- Dotknij każdego pola i wyślij najpierw błędną, potem poprawną wartość. Sprawdź widoczność komunikatów nad klawiaturą. Jeśli logowanie działa tylko na komputerze, przetestuj nową sesję i sprawdź callback oraz cookies.
- Żądania i ładowanie
- Sprawdź stronę z wieloma obrazami i czynność pobierającą dane. Powolna odpowiedź przez domowe łącze nie jest miarą wydajności produkcyjnej. Zanotuj stronę, urządzenie i czynność, by odtworzyć błąd lokalnie.
Pokaż swoją pracę klientowi
Wyślij dokładną stronę do oceny. Napisz, co sprawdzić i kiedy podgląd zostanie zamknięty.
Przed wysłaniem
Użyj konta testowego i przykładowej treści. Sprawdź, czy link działa bez Twoich plików cookie i zalogowanej sesji.
Poproś o konkretny test
Wypełnienie formularza, sprawdzenie menu mobilnego lub zakup z płatnością testową: jasne zadanie daje bardziej przydatne uwagi.
Oto podgląd do dzisiejszego omówienia. Sprawdź menu mobilne i formularz kontaktowy. Link zostanie zamknięty po naszej rozmowie.
Zbieraj uwagi, które pozwalają odtworzyć błąd
Poproś o adres strony, urządzenie, przeglądarkę i ostatnią czynność przed problemem. Zrzut z opisem „oczekiwałem X, ale wystąpiło Y” pomaga bardziej niż „strona nie działa”. Uprzedź o zmianach podczas oceny: zależnie od konfiguracji odwiedzający mogą zobaczyć je lub odświeżenie od razu.
Odbierz webhook lokalnie
Usługa webhooków nie dotrze do localhost na Twoim komputerze. Podaj publiczny adres tunelu wraz ze ścieżką callback. Przykład zakłada, że aplikacja obsługuje już żądania POST pod /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Zastąp YOUR-TUNNEL rzeczywistą nazwą hosta i wpisz pełny adres callback w ustawieniach testowych dostawcy.
- Pozostaw włączoną weryfikację podpisów. Zapisz sekret webhooka lokalnie i wyślij zdarzenie testowe u dostawcy.
- Sprawdź status dostarczenia i lokalne logi. Zwróć oczekiwaną odpowiedź sukcesu i obsłuż ponowne próby bez powtarzania działania.
Żądanie hasła w przeglądarce może zablokować nadawcę webhooka. Użyj dostępnego endpointu i weryfikuj podpisane żądania. CORS dotyczy żądań przeglądarki, nie webhooków między serwerami.
Sprawdź odpowiedź webhooka, nie tylko przeglądarkę
Otwarcie callbacku w przeglądarce zwykle wysyła GET. Wiele webhooków oczekuje POST, więc błąd przeglądarki nie dowodzi błędu dostarczenia. Wyślij zdarzenie testowe i porównaj czas oraz identyfikator dostarczenia z lokalnym logiem.
- 404 / 405
- Sprawdź ścieżkę i metodę HTTP. Użyj portu API, niekoniecznie frontendu. Dostępna strona główna nie oznacza, że endpoint callback istnieje.
- 401 / 403
- Ustal, co odrzuciło żądanie: hasło podglądu, uwierzytelnianie aplikacji czy podpis. Przestrzegaj zasad dotyczących oryginalnego ciała podpisanego żądania; jego parsowanie i ponowne zapisanie przed weryfikacją może unieważnić podpis.
- 5xx / Timeout
- Sprawdź, czy aplikacja działa i otrzymała żądanie. Przy dłuższym przetwarzaniu przestrzegaj limitu czasu dostawcy i użyj zadań w tle, gdy to właściwe. Przetestuj ponowne dostarczenie, aby uniknąć podwójnych zamówień lub wiadomości.
Używaj trybu testowego dostawcy i nie zapisuj sekretów ani pełnych danych osobowych w logach. Udany test sprawdza dostarczenie i obsługę w aplikacji, ale nie zastępuje wymagań integracyjnych dostawcy.
Link się otwiera, ale coś nie działa?
Publiczny link nie dociera do aplikacji
Najpierw otwórz adres lokalny. Sprawdź port, HTTP lub HTTPS oraz czy aplikacja i tunel nadal działają.
Obrazy lub wywołania API nie działają
Szukaj adresów localhost wpisanych na stałe w kodzie. W miarę możliwości używaj ścieżek względnych. API na innym porcie wymaga własnej dostępnej trasy.
Aplikacja przekierowuje do localhost
Sprawdź publiczny adres bazowy, zaufane proxy i callbacki logowania. Zezwól na rzeczywisty host podglądu zamiast wyłączać wszystkie kontrole hostów.
Odświeżanie na żywo lub WebSockets nie działają
Sprawdź, czy WebSockets używają publicznego hosta i wss na stronach HTTPS. Niektóre serwery wymagają oddzielnego ustawienia hosta HMR.
Webhook nie otrzymuje odpowiedzi sukcesu
Sprawdź ścieżkę callback, metodę HTTP, sekret podpisu i log dostarczenia. Zaktualizuj callback po uruchomieniu nowego tymczasowego tunelu.
Zakończ test i udostępnianie
Zatrzymaj udostępnianie w GhostlyShare albo tunel w terminalu przez Ctrl+C. Termin wygaśnięcia może automatycznie zakończyć zaplanowany podgląd. Usuń też tymczasowe adresy callback u dostawcy webhooków.
Potrzebujesz stałego adresu na dłużej?
Tymczasowy podgląd nie zastępuje wdrożenia. Poradnik hostowania w domu opisuje nazwane tunele, domeny, usługi Windows i koszty utrzymania.
Skonfiguruj stały Cloudflare Tunnel →Pytania o lokalne podglądy
FAQ
Dlaczego localhost nie działa na telefonie?
Localhost oznacza urządzenie otwierające adres. Na telefonie użyj publicznego linku, aby dotrzeć do aplikacji na komputerze.
Czy komputer musi pozostać włączony?
Tak. Komputer, lokalna aplikacja i tunel muszą działać. Uśpienie lub zatrzymanie tunelu wyłącza dostęp do podglądu.
Czy podgląd wymaga domeny?
Nie. Tymczasowy tunel zapewnia publiczny adres HTTPS. Gdy się zmieni, zaktualizuj udostępnione linki i ustawienia webhooków.