LOKAL UTVECKLING · VERKLIGA TESTER
Dela localhost: testa på mobilen och ta emot webhooks
Din webbplats körs på din dator. Ge mobilen, en kund eller en webhooktjänst en tillfällig HTTPS-länk för åtkomst, utan driftsättning.
Innan du delar: kontrollera den lokala adressen
Se vilken adress utvecklingsservern visar. Protokoll och port spelar roll: http://localhost:5173 och https://localhost:7143 är olika mål. Öppna exakt den adressen och genomför en vanlig åtgärd innan du skapar tunneln.
En app, en port
Om sidan och API:et använder samma lokala adress når en tunnel båda. Sökvägar bevaras: ett offentligt anrop till /contact når /contact i den lokala appen. Tunneln kopierar eller driftsätter inte filer.
Frontend och API på olika portar
En tunnel till frontend publicerar inte automatiskt ett API på en annan port. En webbläsare som anropar localhost:3000 kontaktar besökarens egen enhet. Använd utvecklingsserverns API-proxy eller en nåbar testadress för API:et och anpassa frontend.
Öppna den offentliga adressen på datorn och på en annan enhet. Fungerar den lokala sidan men inte den offentliga, jämför båda adresserna för att skilja appfel från tunnel- eller värdinställningsfel.
Öppna localhost på mobilen
På mobilen avser localhost mobilen själv, inte din dator. Öppna den offentliga länken eller skanna QR-koden i GhostlyShare.
- Byt till mobildata för att testa åtkomst utanför ditt wifi.
- Testa meny, formulär, tangentbord och filuppladdning på den riktiga enheten.
- Öppna en undersida direkt och ladda om den. Kontrollera även bilder och API-svar.
Testar du bara på samma wifi? Datorns lokala nätverksadress kan räcka om utvecklingsservern och brandväggen tillåter åtkomst. En offentlig tunnel hjälper vid andra nätverk och externa tjänster.

Ett användbart mobiltest på fem minuter
- Navigering och layout
- Öppna menyn, rotera mobilen och besök en lång sida. Leta efter sidledsrullning, täckta knappar och innehåll bakom ett fast sidhuvud. Webbläsaremulering hjälper, men återskapar inte alla verkliga interaktioner.
- Formulär och session
- Tryck på varje fält och skicka först ett ogiltigt, sedan ett giltigt värde. Syns felmeddelanden ovanför tangentbordet? Fungerar inloggning bara på datorn, prova en ny session och kontrollera callback-adress och cookies.
- Anrop och laddning
- Testa en bildrik sida och en åtgärd som laddar data. Ett långsamt svar via hemanslutningen mäter inte produktionsprestanda. Anteckna sida, enhet och åtgärd för att återskapa felet lokalt.
Visa ditt arbete för en kund
Skicka exakt den sida du vill få granskad. Förklara vad mottagaren ska testa och när förhandsvisningen stängs.
Innan du skickar
Använd ett testkonto och exempelinnehåll. Kontrollera att länken fungerar utan dina egna cookies eller din inloggade session.
Be om en konkret kontroll
Fyll i kontaktformuläret, granska mobilmenyn eller prova kassan med testbetalningar. En tydlig uppgift ger mer användbar återkoppling.
Här är förhandsvisningen för dagens genomgång. Kontrollera mobilmenyn och kontaktformuläret. Länken stängs efter vårt samtal.
Gör återkopplingen möjlig att återskapa
Be om sidans adress, enhet, webbläsare och sista åtgärden före problemet. En skärmbild med ”jag väntade mig X, men Y hände” hjälper mer än ”sidan fungerar inte”. Säg till om du ändrar appen under granskningen: besökare kan beroende på inställningarna se ändringar eller omladdningar direkt.
Ta emot en webhook lokalt
En webhooktjänst når inte localhost på din dator. Ange tunnelns offentliga adress med din callback-sökväg. Exemplet förutsätter att appen redan hanterar POST-anrop på /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Ersätt YOUR-TUNNEL med ditt faktiska värdnamn och ange hela callback-adressen i leverantörens testinställningar.
- Låt signaturkontrollen vara på. Lagra webhookhemligheten lokalt och skicka en testhändelse från leverantören.
- Kontrollera leveransstatus och lokala loggar. Returnera det framgångssvar leverantören förväntar sig och hantera nya försök utan att upprepa åtgärden.
En lösenordsruta i webbläsaren kan blockera webhookavsändaren. Använd en nåbar endpoint och verifiera signerade anrop. CORS gäller webbläsaranrop, inte webhooks mellan servrar.
Kontrollera webhooksvaret, inte bara webbläsaren
Att öppna callback-adressen i webbläsaren skickar vanligtvis GET. Många webhookendpoints väntar på POST, så ett webbläsarfel bevisar inte leveransproblem. Skicka testhändelsen och jämför tidpunkt och leverans-ID med den lokala loggen.
- 404 / 405
- Kontrollera sökväg och HTTP-metod. Använd API-porten, inte automatiskt frontendporten. En nåbar startsida betyder inte att callback-endpointen finns.
- 401 / 403
- Kontrollera vad som avvisade anropet: förhandsvisningens lösenord, appens autentisering eller signaturkontrollen. Följ reglerna för ursprunglig meddelandekropp vid signerade data; tolkning och omskrivning före verifiering kan ogiltigförklara signaturen.
- 5xx / Timeout
- Kontrollera att appen körs och tog emot anropet. Respektera leverantörens svarstid vid långsam behandling och använd bakgrundsarbete där det passar. Testa en upprepad leverans så att beställningar eller meddelanden inte dubbleras.
Använd leverantörens testläge och logga inte hemligheter eller fullständiga personuppgifter. Ett lyckat test kontrollerar leverans och appens hantering, men ersätter inte leverantörens integrationskrav.
Länken öppnas, men något fungerar inte?
Den offentliga länken når inte appen
Öppna den lokala adressen först. Kontrollera port, HTTP eller HTTPS och att appen och tunneln fortfarande körs.
Bilder eller API-anrop misslyckas
Leta efter hårdkodade localhost-adresser. Använd relativa sökvägar där det går. Ett API på en annan port behöver en egen nåbar väg.
Appen omdirigerar till localhost
Kontrollera offentlig basadress, betrodda proxyer och inloggningens callback-adresser. Tillåt den faktiska förhandsvisningsvärden i stället för att stänga av värdkontroller överallt.
Direkt omladdning eller WebSockets fungerar inte
Kontrollera att WebSockets använder den offentliga värden och wss på HTTPS-sidor. Vissa utvecklingsservrar behöver en separat HMR-värd.
Webhooken får inget framgångssvar
Kontrollera callback-sökväg, HTTP-metod, signaturhemlighet och leveranslogg. Uppdatera callback-adressen när en ny tillfällig tunnel startas.
Avsluta testet och sluta dela
Stoppa delningen i GhostlyShare eller terminaltunneln med Ctrl+C. En sluttid kan avsluta en planerad förhandsvisning automatiskt. Ta även bort tillfälliga callback-adresser hos webhookleverantören.
Behöver du en fast adress för löpande användning?
En tillfällig förhandsvisning är ingen driftsättning. Vår guide om webbhotell hemma tar upp namngivna tunnlar, domäner, Windows-tjänster och driftskostnader.
Konfigurera en permanent Cloudflare Tunnel →Frågor om lokala förhandsvisningar
Vanliga frågor
Varför fungerar inte localhost på mobilen?
Localhost avser enheten som öppnar adressen. Använd den offentliga länken på mobilen för att nå appen på datorn.
Måste datorn vara på?
Ja. Datorn, den lokala appen och tunneln måste fortsätta köras. Viloläge eller en stoppad tunnel gör förhandsvisningen otillgänglig.
Behöver jag en domän för förhandsvisningen?
Nej. En tillfällig tunnel ger en offentlig HTTPS-adress. Uppdatera delade länkar och webhookinställningar om adressen ändras.
