Claude Code: Fejlfinding af afbrudte fjernforbindelser – symptomer, kriterier og løsninger for seks afbrydelsestyper

Når du kører Claude Code eksternt, er det værste ikke, at du ikke kan oprette forbindelse, men at forbindelsen etableres og så afbrydes igen – og årsagen er forskellig hver gang.

Ordet »afbrydelse« dækker faktisk over seks helt forskellige fejl. De har hver deres karakteristiske symptomer, og løsningerne har intet med hinanden at gøre – hvis du behandler en udløbet langvarig forbindelse som følge af netværksskift som om, maskinen er gået i dvale, hjælper det ikke at slå dvalen fra; hvis du behandler en halvdød forbindelse som dårligt netværk og venter på, at det går over, bliver den ikke god af sig selv, selvom du venter til daggry.

Denne artikel ræsonnerer baglæns ud fra det, du faktisk ser: For hver afbrydelsestype gives symptomerne, hvordan du bekræfter, at det er den, og den tilsvarende løsning. Hvis du vil i gang med det samme, kan du springe til tjeklisten i sidste afsnit.

ne artikel handler kun om fejlfinding af afbrydelser. Se »Claude Code fjernadgang: Styr sessioner hvor som helst, selv uden din lokale maskine« for opsætning af fjernadgang, og se »Claude Code på mobilen: Se sessioner og godkend værktøjer på iOS når som helst« for brug på mobilen.

Tjek først symptomerne: Hvilken en ser du?

En fjernforbindelse består af to led: udviklingsmaskinen, der kører Claude Code ←→ den enhed, du har i hånden til at vise. Hvis et af de to led har problemer, viser det sig som »afbrudt«, men symptomerne er forskellige:

Det, du ser	Sandsynligvis	Spring til
Sessionen fryser pludselig, og efter genforbindelse er fremskridtet stadig fastfrosset på det tidspunkt	Udviklingsmaskinen er i dvale / skærmen er låst	§1
Afbrydes præcis i det øjeblik, du går ind i elevatoren, skifter til 4G eller skifter WiFi	Langvarig forbindelse afbrudt	§2
Så snart den lokale terminal lukkes, eller den lokale maskine går i dvale, afbrydes fjernforbindelsen med det samme	Hård begrænsning ved skærmdeling	§3
Vises som online, men beskeder forsvinder sporløst uden nogen fejlmeddelelse	Halvdød forbindelse	§4
Kan genoprette forbindelse, men det er en tom session / beskeder fra afbrydelsesperioden er væk	Genforbindelsen får ikke den oprindelige session tilbage	§5
Efter et par timer er sessionen væk	Processen blev genbrugt, og der er ingen kold genoprettelse	§6

Den letteste at fejlvurdere er den fjerde type: den giver ingen fejlmeddelelse. Forbindelsesstatus er grøn, beskeder kan sendes, men der er bare aldrig noget svar – sværere at finde end et direkte afbrud, fordi alle indikatorer fortæller dig, at »alt er normalt«.

1. Udviklingsmaskine i dvale / skærm låst / låg lukket

Symptomer: Sessionen stopper helt på et bestemt tidspunkt. Når du genopretter forbindelsen, er fremskridtet stadig på det tidspunkt, hvor den afbrød – ikke et skridt videre.

Hvorfor: Mange tror, at »min udviklingsmaskine er tændt hele tiden«, men systemdvale, dvale ved lukket låg og planlagt skærmlåsning vil suspendere eller dræbe Claude Code-processen. På visningssiden ser det bare ud som om, at »den stoppede pludselig«.

Sådan bekræfter du det: Gå tilbage til udviklingsmaskinen og se, om processen stadig findes, og om systemloggen indeholder dvale-posteringer. Hvis processen stadig kører, men tidsstemplet er fastfrosset på afbrydelsestidspunktet, er det næsten sikkert dette.

Løsning: Indstil udviklingsmaskinens strømplan til »ingen dvale / ingen dvale ved lukket låg«. Dette er den eneste måde at løse det grundlæggende – ingen fjernløsning kan redde en maskine, der allerede er gået i dvale.

2. Langvarig forbindelse afbrudt pga. netværksskift

Symptomer: Afbrydelsen sker på et meget bestemt tidspunkt – du går ind i elevatoren, WiFi skifter til 4G, eller hjemmets bredbånd genforbinder midt om natten.

Hvorfor: Realtidssynkronisering eksternt afhænger af en langvarig forbindelse (WebSocket / SSH). Så snart IP-adressen ændres, er forbindelsen ugyldig med det samme – der er ingen forhandling.

Sådan bekræfter du det: Hvis afbrydelsestidspunktet matcher dit netværksskift, er det dette.

Løsning: Denne type kan ikke undgås; den kan kun håndteres med automatisk genforbindelse + backoff (1s→2s→5s…, for at undgå at hamre løs, så snart forbindelsen afbrydes). Ren SSH har ikke denne mulighed – afbrudt er afbrudt, og du skal oprette forbindelse manuelt. Dette er et hårdt krav, når du vælger løsning.

3. Skærmdelingsløsning: Den lokale maskine skal køre i forgrunden

Symptomer: Så snart den lokale terminal lukkes, eller den lokale maskine går i dvale, afbrydes mobilen øjeblikkeligt. Det er ikke en langsom timeout – synkroniseringen ophører.

Hvorfor: Anthropics officielle Remote Control projicerer den session, der kører på din lokale maskine, til mobilen/browseren. Forudsætningen er, at Claude Code på den lokale maskine kører i forgrunden hele tiden, og at den lokale maskine er online hele tiden. Så snart den lokale maskine falder ud, har fjernsiden ingen selvstændig livscyklus at knytte sig til.

Sådan bekræfter du det: Luk det lokale terminalvindue og se, om fjernforbindelsen afbrydes i samme sekund. Hvis ja, bruger du en skærmdelingsløsning.

Løsning: Skift til en arkitektur med en vedvarende daemon-service på udviklingsmaskinen – den side, der kører sessionen, bliver en baggrundstjeneste, der starter automatisk ved opstart og lever uafhængigt af din visningsenhed. Uanset om visningssiden lukkes, skiftes eller afbrydes, kører den stadig på udviklingsmaskinen. Dette er den grundlæggende forskel mellem »skærmdeling« og »vedvarende service« – det kan ikke justeres med parametre.

4. Halvdød forbindelse (half-open): Den sværeste at opdage

Symptomer: Vises som online, men beskeder får intet svar og ingen fejlmeddelelse. Det kan hænge i et par minutter eller helt indtil du manuelt genopretter forbindelsen.

Hvorfor: Når netværket afbrydes stille og roligt (NAT-tabelposter udløber, mellemliggende enheder mister tilstand, signalet er så svagt, at pakker tabes uden at forbindelsen lukkes), kan begge TCP-ender tro, at de stadig er forbundet, mens data i virkeligheden aldrig når frem. Uden heartbeat vil begge sider fortsætte med denne illusion.

Sådan bekræfter du det: Forbindelsesstatus viser normal, men sendte beskeder får hverken leveringsbekræftelse eller fejlmeddelelse; efter manuel afbrydelse og genforbindelse virker det med det samme – så er det dette.

Løsning: Forbindelsen skal have et heartbeat (keepalive ping): Hvis der ikke modtages noget svar fra modparten inden for den aftalte tid, bedømmes forbindelsen som halvdød, og den afbrydes og genoprettes proaktivt i stedet for bare at vente. Kriteriet skal være »intet svar modtaget«, ikke »ingen fejlmeddelelse« – en halvdød forbindelse giver aldrig fejlmeddelelser.

5. Genforbindelse får ikke den oprindelige session tilbage / mistede beskeder

Symptomer: Efter afbrydelse kan du genoprette forbindelsen, men enten er sessionen tom, eller også er alle beskeder, der blev sendt under afbrydelsen, væk.

Hvorfor: Genforbindelse opretter bare en ny forbindelse uden at abonnere den tilbage på den oprindelige session; beskeder fra afbrydelsesperioden er heller ikke blevet cachet for dig.

Sådan bekræfter du det: Efter genforbindelse er session-ID'et ændret, eller historikken starter kun fra genforbindelsestidspunktet.

Løsning: Vælg en løsning, der automatisk abonnerer tilbage på den oprindelige session efter genforbindelse og afspiller historikken fra afbrydelsesperioden. Hvis den kun kan genoprette forbindelsen, men ikke få sessionen tilbage, er genforbindelsen nytteløs.

6. Sessionens proces blev genbrugt, og der er ingen kold genoprettelse

Symptomer: Korte afbrydelser og genforbindelser fungerer normalt, men når du vender tilbage efter et par timer, er sessionen væk.

Hvorfor: En session, der har været inaktiv i lang tid, kan blive genbrugt, og selve daemon-processen kan også være genstartet (opgradering, genstart efter nedbrud). Sessionstilstanden i hukommelsen forsvinder dermed.

Sådan bekræfter du det: Det sker kun ved lange afbrydelser, ikke ved korte.

Løsning: Du har brug for kold genoprettelse – sessionstilstanden gemmes på disk, så konteksten kan gendannes fra disken, selvom processen er væk. Ideelt set gendannes den automatisk, når du sender en besked, og du mærker det ikke.

Fejlfindingstjekliste (kan følges med enhver løsning)

Gå gennem den i rækkefølge – hvert trin kan afkræftes uafhængigt:

1. Er maskinen, der kører sessionen, gået i dvale / er skærmen låst? → Slå automatisk dvale fra, ingen dvale ved lukket låg. (§1)
2. Sker afbrydelsen samtidig med, at du skifter netværk? → Du har brug for en løsning med automatisk genforbindelse + backoff, ikke ren SSH. (§2)
3. Afbrydes fjernforbindelsen med det samme, når den lokale terminal lukkes? → Hård begrænsning ved skærmdelingsløsninger; du skal skifte til en vedvarende daemon-arkitektur. (§3)
4. Hænger du i »vises som online, men beskeder får intet svar«? → Halvdød forbindelse; kun heartbeat-detektion kan automatisk redde den. (§4)
5. Er sessionen tom / er beskeder forsvundet efter genforbindelse? → Du har brug for »genoprettelse af den oprindelige session + afspilning af historik«. (§5)
6. Forsvinder sessionen kun ved lange afbrydelser? → Du har brug for lagring på disk + kold genoprettelse. (§6)

Når vi ser på konkrete løsninger

Af de seks punkter ovenfor er kun punkt 1 et indstillingsproblem på din egen maskine. De øvrige fem er alle bestemt af arkitekturen – de er fastlåst, når du vælger løsningen, og kan ikke reddes ved at justere parametre efter problemerne opstår.

En fjernløsning, der ikke afbrydes, skal samtidig have: en vedvarende daemon-proces på udviklingsmaskinen (dækker resterende risiko fra §1 og §3), automatisk genforbindelse + backoff (§2), heartbeat-detektion (§4), genforbindelse til den oprindelige session + historikafspilning (§5) samt lagring på disk + kold genoprettelse (§6).

PandaNpc + pandapaw er bygget, så det opfylder alle seks punkter: pandapaw registreres på udviklingsmaskinen som en vedvarende daemon-proces, der starter automatisk ved opstart (ikke et terminalvindue, du skal holde åbent manuelt; den genstartes automatisk ved nedbrud); visningssiden genopretter automatisk forbindelsen med backoff; forbindelsen har heartbeat, og hvis der ikke modtages svar, bedømmes den som halvdød og genopretter proaktivt; efter genforbindelse abonnerer den automatisk tilbage på den oprindelige session og afspiller historikken fra afbrydelsesperioden; og selvom sessionens proces bliver genbrugt, kan den koldt gendannes fra disken ved at sende en besked.

Se »Claude Code fjernadgang« for, hvordan du installerer og opretter forbindelse; se »Claude Code på mobilen« for sessionsvisning og værktøjsgodkendelse på mobilen.

En ekstra fælde: Pas på afregningen, når du kører eksternt

Når du fejlfinder afbrydelser, er det let at skifte til claude -p (headless-tilstand), men fra 15. juni 2026 ændrede Anthropic afregningen – headless bruger ikke længere abonnementskvoten, men trækker i stedet på et lille månedligt SDK-credit, og når det er brugt, afregnes det efter API. Ved kraftig brug overskrider man nemt budgettet. Interaktiv tilstand (claude REPL) bruger stadig abonnementskvoten. Når du skifter løsning for at fejlfinde afbrydelser, skal du passe på ikke også at skifte afregningsmodel.