Claude Code távoli megszakadás hibakeresése: hatféle megszakadás tünetei, felismerése és megoldása

A távoli Claude Code használatakor nem az a legrosszabb, ha nem tudsz csatlakozni, hanem az, hogy csatlakozol, aztán megszakad, és minden alkalommal más okból.

A „megszakadás” szó valójában hat teljesen különböző hibát takar. A tüneteik eltérőek, a javításuk pedig független egymástól – ha a hálózatváltás okozta hosszú kapcsolat megszűnését gépi alvásnak nézed, a hibernálás kikapcsolása sem segít; ha a félig halott kapcsolatra vársz, mint rossz hálózatra, akkor reggelig sem fog magától helyreállni.

Ez a cikk a ténylegesen tapasztalt jelenségek alapján következtet vissza az okokra: minden megszakadási módhoz megadja a tüneteket, hogyan ismerheted fel, és a hozzá tartozó megoldást. Ha azonnal cselekednél, ugorj az utolsó rész hibakeresési listájára.

Ez a cikk kizárólag a megszakadás hibakereséséről szól. A távoli hozzáférés beállításáról lásd „Claude Code távoli hozzáférés: a gép nélkül is bárhonnan vezérelheted a sessiont”, a mobilról való használatról pedig „Mobilról a Claude Code-hoz: iOS-en bármikor megtekintheted a sessionöket és jóváhagyhatod az eszközöket”.

Először a tünetek: melyiket látod?

A távoli kapcsolat két szakaszból áll: a Claude Code-ot futtató fejlesztőgépről ←→ a nálad lévő megtekintő eszközről. Bármelyik szakasz hibája „megszakadtként” jelentkezik, de a tünetek különböznek:

Ami látod	Valószínűleg ez	Ugrás
A session hirtelen megáll, és újracsatlakozáskor a folyamat is ott áll, ahol megszakadt	Fejlesztőgép alvás / zárolás	§1
Liftezés, 4G-re váltás, WiFi csere pillanatában szakad meg	Hosszú kapcsolat megszakítva	§2
Amint bezárod a helyi terminált, vagy a gép elalszik, a távoli kapcsolat azonnal megszakad	Kivetítéses megoldás kemény korlátja	§3
Online jelzés, de az üzenetek süket fülekre találnak, hibaüzenet nélkül	Félig halott kapcsolat	§4
Újracsatlakozik, de üres sessiont kapsz / a megszakadás alatti üzenetek elvesztek	Az újracsatlakozás nem az eredeti sessionhöz kapcsolódik	§5
Órákkal később csatlakozva a session eltűnt	A folyamatot újrahasznosították, és nincs hideg helyreállítás	§6

A negyedik típust a legkönnyebb félreérteni: nem ad hibaüzenetet. A kapcsolat állapota zöld, az üzenetek elküldhetők, csak soha nincs válasz – nehezebb diagnosztizálni, mint az egyszerű megszakadást, mert minden jelzőlámpa azt mondja: „minden rendben”.

1. Fejlesztőgép alvás / zárolás / lecsukott fedél

Tünetek: A session egy adott pillanatban teljesen megáll. Újracsatlakozáskor a folyamat még mindig a megszakadás időpontjában áll, egy lépést sem haladt előre.

Miért: Sokan azt hiszik, hogy „a fejlesztőgép folyamatosan fut”, de a rendszer hibernálása, a lecsukott fedél okozta alvás és az időzített képernyőzár felfüggeszti vagy egyenesen megöli a Claude Code folyamatot. A megtekintő oldalon ezt „hirtelen leállásként” látod.

Hogyan ismerheted fel: Menj vissza a fejlesztőgépre, és nézd meg, hogy a folyamat létezik-e, illetve hogy a rendszernapló tartalmaz-e alvásra utaló bejegyzést. Ha a folyamat megvan, de az időbélyeg a megszakadás időpontjában áll, szinte biztosan ez az ok.

Megoldás: Állítsd a fejlesztőgép energiaellátási tervét „nincs alvás / lecsukott fedélnél sincs alvás” módra. Ez az egyetlen gyökeres megoldás – semmilyen távoli megoldás nem tud megmenteni egy már elaludt gépet.

2. Hálózatváltás miatt megszakított hosszú kapcsolat

Tünetek: Megszakad egy nagyon konkrét pillanatban – liftezés, WiFi→4G váltás, otthoni szélessáv éjszakai újratárcsázása.

Miért: A távoli valós idejű szinkron egy hosszú életű kapcsolatra épül (WebSocket / SSH). Ha az IP megváltozik, a kapcsolat azonnal érvénytelenné válik, mindenféle egyeztetés nélkül.

Hogyan ismerheted fel: Ha a megszakadás időpontja egybeesik a hálózatváltás időpontjával, ez az ok.

Megoldás: Ezt a típust nem lehet elkerülni, csak automatikus újracsatlakozással + visszahúzódással lehet kezelni (1s→2s→5s…, hogy ne támadd rögtön a szervert). A puszta SSH erre nem képes; ha megszakad, megszakad, és kézzel kell újracsatlakozni. Ez kemény követelmény a megoldás kiválasztásakor.

3. Kivetítéses megoldás: a helyi gépnek előtérben kell futnia

Tünetek: Amint bezárod a helyi terminált, vagy a helyi gép elalszik, a telefonos oldal azonnal megszakad. Nem lassú időtúllépés, hanem a szinkron azonnali elvesztése.

Miért: Az Anthropic hivatalos Remote Control megoldása a helyi gépen futó session kivetítése a telefonra/böngészőre. Ennek előfeltétele, hogy a helyi Claude Code folyamatosan előtérben fusson, és a helyi gép online legyen. Ha a helyi gép kiesik, a távoli oldalnak nincs független életciklusa, amihez kötődhetne.

Hogyan ismerheted fel: Zárd be a helyi terminálablakot, és nézd meg, hogy a távoli kapcsolat ugyanabban a másodpercben megszakad-e. Ha igen, akkor kivetítéses megoldást használsz.

Megoldás: Válts fejlesztőgép-oldali állandó háttérszolgáltatásra épülő architektúrára – a sessiont futtató oldal legyen egy rendszerindításkor automatikusan elinduló háttérszolgáltatás, amely függetlenül él a megtekintő eszközeidtől. Ha a megtekintő oldalt bezárod, lecseréled vagy megszakad, a szolgáltatás ugyanúgy fut a fejlesztőgépen. Ez a lényegi különbség a „kivetítés” és az „állandó szolgáltatás” között, és nem állítható be paraméterekkel.

4. Félig halott kapcsolat (half-open): a legnehezebben észlelhető típus

Tünetek: Online jelzést mutat, de az üzenetekre nincs válasz, és hibaüzenet sincs. Lehet, hogy percekig tart, vagy addig tart, amíg manuálisan újracsatlakozol.

Miért: Amikor a hálózat csendben megszakad (NAT-bejegyzés időtúllépése, köztes eszköz állapotvesztése, olyan gyenge jel, ami csak csomagokat ejt, de nem bontja a kapcsolatot), a TCP mindkét végpontja azt hiheti, hogy még kapcsolatban van, miközben az adatok soha többé nem jutnak át. Szívverés (keepalive) nélkül mindkét fél fenntartja ezt az illúziót.

Hogyan ismerheted fel: A kapcsolat állapota normális, de az elküldött üzenetekre sem kézbesítési visszaigazolás, sem hibaüzenet nincs; manuális újracsatlakozás után azonnal helyreáll – ez az.

Megoldás: A kapcsolaton fusson szívverés (keepalive ping): ha egy megadott időn belül nem érkezik válasz a másik féltől, akkor a kapcsolatot félig halottnak kell minősíteni, és aktívan bontani/újracsatlakozni, nem pedig tétlenül várni. A kritérium mindig „nincs válasz” legyen, ne „nincs hibaüzenet” – a félig halott kapcsolat soha nem ad hibaüzenetet.

5. Az újracsatlakozás nem tér vissza az eredeti sessionhöz / üzenetvesztés

Tünetek: Megszakadás után újra lehet csatlakozni, de vagy egy üres sessiont kapsz, vagy a megszakadás alatt a másik fél által küldött üzenetek mind elvesznek.

Miért: Az újracsatlakozás csak egy új kapcsolat létrehozását jelenti, de ez a kapcsolat nincs feliratkoztatva az eredeti sessionre; a megszakadás alatti üzeneteket sem gyorsítótárazták a számodra.

Hogyan ismerheted fel: Az újracsatlakozás után a session ID megváltozott, vagy az előzmények csak az újracsatlakozás pillanatától érhetők el.

Megoldás: Olyan megoldást válassz, amely újracsatlakozás után automatikusan feliratkozik az eredeti sessionre, és visszajátssza a megszakadás alatti előzményeket. Ha csak újracsatlakozni tudsz, de visszakapcsolódni nem, az olyan, mintha hiába csatlakoznál.

6. A session folyamatot újrahasznosítják, és nincs hideg helyreállítás

Tünetek: Rövid megszakítás után az újracsatlakozás normális, de ha órákkal később jössz vissza, a session eltűnt.

Miért: A hosszú ideje tétlen session folyamatokat újrahasznosíthatják, és maga a háttérfolyamat is újraindulhatott (frissítés, összeomlás utáni újraindítás). A memóriában lévő session állapota ezzel elvész.

Hogyan ismerheted fel: Csak hosszú megszakítás után jelentkezik, rövid megszakítás után nem.

Megoldás: Hideg helyreállításra van szükség – a session állapotát lemezre kell írni, hogy a folyamat elvesztése után is vissza lehessen állítani a kontextust a lemezről. Ideális esetben csak küldesz egy üzenetet, és az automatikusan folytatódik, számodra észrevétlenül.

Hibakeresési lista (bármilyen megoldáshoz követhető)

Menj végig sorrendben, minden lépés önállóan cáfolható:

1. Aludt / zárolódott a sessiont futtató gép? → Kapcsold ki az automatikus alvást, lecsukott fedélnél se aludjon. (§1)
2. A megszakadás időpontja egybeesik a hálózatváltással? → Automatikus újracsatlakozást + visszahúzódást támogató megoldás kell, ne puszta SSH-t. (§2)
3. Ha bezárod a helyi terminált, a távoli kapcsolat azonnal megszakad? → Ez a kivetítéses megoldás kemény korlátja, állandó háttérszolgáltatásra kell váltani. (§3)
4. Elakadtál a „online jelzés, de az üzenetekre nincs válasz” állapotnál? → Félig halott kapcsolat, csak szívverés-ellenőrzés tudja automatikusan megmenteni. (§4)
5. Az újracsatlakozás után üres a session / hiányoznak üzenetek? → „Visszakapcsolódás az eredeti sessionhöz + előzmény-visszajátszás” kell. (§5)
6. Csak hosszú megszakítás után vész el a session? → Lemezre írás + hideg helyreállítás kell. (§6)

Konkrét megoldásokra lebontva

A fenti hat pont közül csak az 1. a saját géped beállítási kérdése, a másik öt mind architektúra által meghatározott – a megoldás kiválasztásakor eldől, és ha probléma adódik, paraméterezéssel nem lehet megmenteni.

Egy megszakításmentes távoli megoldásnak egyszerre kell rendelkeznie: fejlesztőgép-oldali állandó háttérfolyamattal (az §1 maradék kockázatára és §3-ra), automatikus újracsatlakozással + visszahúzódással (§2), szívverés-ellenőrzéssel (§4), újracsatlakozáskor az eredeti sessionhöz való visszakapcsolódással + előzmény-visszajátszással (§5), valamint lemezre írással és hideg helyreállítással (§6).

A PandaNpc + pandapaw rendszer ezt a hat pontot pontosan követi: a pandapaw rendszerindításkor automatikusan induló állandó háttérfolyamatként regisztrálja magát a fejlesztőgépen (nem egy kézzel nyitva tartott terminálablak; ha összeomlik, automatikusan újraindul); a megtekintő oldal megszakadáskor automatikusan újracsatlakozik, visszahúzódással; a kapcsolaton szívverés fut, és ha nem érkezik válasz, félig halottnak minősíti és aktívan újracsatlakoz; újracsatlakozás után automatikusan feliratkozik az eredeti sessionre, és visszajátssza a megszakadás alatti előzményeket; még ha a session folyamatot újra is hasznosították, egy üzenet küldésével hideg helyreállítás indul a lemezről.

A telepítésről és a csatlakozásról lásd „Claude Code távoli hozzáférés”; a mobiloldali session-megtekintésről és eszközjóváhagyásról pedig „Mobilról a Claude Code-hoz”.

Egy járulékos buktató: távoli futtatásnál kerüld el a számlázási csapdát

A megszakadás hibakeresésekor könnyen átváltasz a claude -p (headless mód) futtatásra, de 2026. június 15-től az Anthropic módosította a számlázást – a headless mód már nem a feliratkozási keretet használja, hanem egy kis havi SDK creditet, ami után API-alapú számlázás következik, így intenzív használatnál könnyen túllépheted a keretet. Az interaktív mód (claude REPL) továbbra is a feliratkozási keretet használja. Amikor megoldást váltasz a megszakadás hibakeresésére, figyelj arra, hogy ne váltsd át egyúttal a számlázási módot is.