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.

Skapa en offentlig länk

Starta webbplatsen eller API:et och kontrollera lokal åtkomst. GhostlyShare hittar automatiskt lokala webbappar som körs. Klicka på Go Public för att skapa en offentlig HTTPS-länk.

  1. Låt appen och GhostlyShare köras under testet.
  2. Öppna länken i ett privat webbläsarfönster innan du delar den.
  3. Använd testdata. Lägg vid behov till ett lösenord för en privat kundförhandsvisning.

Windows och Linux. Kostnadsfria tillfälliga länkar utan konto, e-post eller abonnemang.

Ladda ner GhostlyShare ↗

Se alla funktioner i GhostlyShare →

GhostlyShare med offentlig förhandsvisning och delningskontroller

Ö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.

  1. Byt till mobildata för att testa åtkomst utanför ditt wifi.
  2. Testa meny, formulär, tangentbord och filuppladdning på den riktiga enheten.
  3. Ö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.

QR-kod i GhostlyShare för att öppna en förhandsvisning på mobilen

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
  1. Ersätt YOUR-TUNNEL med ditt faktiska värdnamn och ange hela callback-adressen i leverantörens testinställningar.
  2. Låt signaturkontrollen vara på. Lagra webhookhemligheten lokalt och skicka en testhändelse från leverantören.
  3. 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.

Exempel: verifiera GitHubs webhooksignaturer ↗

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.