Kezdd a Docker Desktop és a WSL 2 virtuális gép újraindításával – ne a Docker újratelepítésével vagy a WSL adatainak törlésével. A jelenlegi Windows beállításokon a Docker Desktop általában a WSL 2 backendet használja, így az „Engine stopped” (Motor leállt) üzenet lehet Docker Desktop hiba, WSL hiba vagy Windows virtualizációs hiba. A leggyorsabb javítási út az, hogy megállapítsd, melyik réteg hibászik, mielőtt destruktív változtatásokat végeznél.
2026 szeptemberéig a Docker Windows dokumentációja a WSL 2.1.5 vagy újabb verziót követeli meg a WSL 2 backendhez, és a legújabb WSL verzió használatát ajánlja. A Docker azt is leírja, hogy a WSL 2 az alapértelmezett backend a legtöbb Windows felhasználó számára. A Microsoft dokumentálja a wsl --version, wsl --status, wsl --update és wsl --shutdown parancsokat a WSL környezet ellenőrzésének, frissítésének és újraindításának szabványos parancsaiként. Lásd a Docker Windows telepítési követelményeit, a Docker WSL 2 backend dokumentációját és a Microsoft WSL parancsreferenciáját.
Ez az útmutató négy javítási fázist használ, a legbiztonságosabbtól a leginkább zavaróbbig. Állj meg, amint a Docker újra működik.
| Amit látsz | Hasznosabb következő ellenőrzés |
|---|---|
| A Docker Desktop megnyílik, de azt mondja, hogy a motor leállt | Indítsd újra a Docker Desktopot, majd teszteld a Docker daemon-t |
A wsl --status vagy wsl --version hibát jelez | Javítsd vagy frissítsd a WSL-t, mielőtt a Docker adatait módosítanád |
| A WSL virtualizációs vagy szükséges funkció hibát jelent | Ellenőrizd a Virtual Machine Platformot és a BIOS/UEFI virtualizációt |
| A WSL működik, de a Docker még mindig nem indul el | Ellenőrizd a Docker Desktop beállításait, frissítsd a Dockert, és gyűjts diagnosztikai adatokat |
| A probléma közvetlenül egy frissítés után kezdődött | Ellenőrizd a jelenlegi Docker Desktop kiadási megjegyzéseit egy megfelelő Windows/WSL ismert hiba miatt |
Amit tudunk: ezek a rétegek egymástól függenek. Amit nem tudunk pusztán az „Engine stopped” szavakból: melyik réteg hibásodott meg a gépeden. Maga az üzenet nem elég egy gyári visszaállítás igazolásához.
Először használd a Docker Desktop Troubleshoot > Restart Docker Desktop (Hibaelhárítás > Docker Desktop újraindítása) opcióját. A Docker a Restart Docker Desktopot dokumentálja a Troubleshoot menü első nem destruktív lépéseként. Azokon a verziókon, amelyek tartalmazzák a Docker Desktop CLI-t, használhatod a következőket is:
docker desktop status
docker desktop restartA Docker jelenlegi CLI referenciája dokumentálja a status, start, stop és restart parancsokat. Lásd a Docker Desktop CLI dokumentációt és a Docker Desktop hibaelhárítási dokumentációt.
A Docker újraindítása után teszteld a daemon-t:
docker version
docker infoHa a docker version mind a kliens, mind a szerver információit visszaadja egy daemon-csatlakozási hiba helyett, a motor újra válaszol.
Hasznos lépés: ha az újraindítás működik, állj meg itt. Ne állítsd vissza a WSL-t, ne regisztráld le a disztribúciókat, és ne telepítsd újra a Dockert csak azért, mert egy másik útmutató ezt ajánlja.
Ez nem univerzális megoldás. A Docker jelenlegi Windows jogosultsági dokumentációja azt mondja, hogy WSL 2 Linux konténerek esetén a com.docker.service privilegizált segédprogram általában nem szükséges, és ezért nem feltétlenül fut automatikusan bootoláskor. Szükséges olyan esetekben, mint a Windows konténerek és a Hyper-V backend, és bizonyos privilegizált host-fájl műveletekhez is használható.
Tehát egy leállt com.docker.service nem bizonyítja, hogy egy WSL 2 Linux-konténer telepítés törött. Lásd a Docker Windows jogosultsági követelményeit.
Hasznos lépés: állapítsd meg, hogy WSL 2 Linux konténereket használsz-e, mielőtt a Windows szolgáltatást tekintenéd gyökérokának.
Nyisd meg a PowerShellt vagy a Windows Terminált, és futtasd:
wsl --version
wsl --status
wsl -l -vA Docker jelenleg a WSL 2.1.5 vagy újabb verziót követeli meg a WSL 2 backendjéhez, és a legújabb elérhető WSL kiadás ajánlja. Ha a WSL-ed régebbi, frissítsd:
wsl --updateMajd állítsd le teljesen a WSL 2 környezetet:
wsl --shutdownA Microsoft azt mondja, hogy a wsl --shutdown azonnal megszünteti az összes futó disztribúciót és a WSL 2 könnyűsúlyú segéd virtuális gépet. Indítsd újra a Docker Desktopot a leállítás után. Ha a Windows vagy a WSL újraindítást kért egy frissítés során, indítsd újra a Windowst az újratesztelés előtt.
Hasznos lépés: futtasd a parancsokat ebben a sorrendben, és jegyezd fel a pontos hibakódot. Egy hiba a wsl --status-ból diagnosztikailag hasznosabb, mint az általános Docker „Engine stopped” üzenet.
A Docker Desktop nem igényel egy konkrét felhasználó által telepített Linux disztribúciót. A Docker WSL dokumentációja azt mondja, hogy a Docker parancsok működhetnek Windowson anélkül, hogy egy konkrét Linux disztribúció telepítve lenne; az Ubuntu, Debian vagy másik disztribúció WSL integrációjának engedélyezése opcionális a Linux-natív munkafolyamatokhoz.
Hasznos lépés: ha maga a WSL helyesen indul el, ne törölj egy működő Ubuntu vagy Debian disztribúciót pusztán azért, hogy megjavítsd a Docker Desktopot.
A Microsoft kifejezetten figyelmeztet, hogy a wsl --unregister <DistributionName> véglegesen eltávolítja az adott disztribúció adatait, beállításait és telepített szoftvereit. A Docker-rel kapcsolatos vagy személyes WSL disztribúciókat regisztráló parancsok ezért destruktív hibaelhárítások, nem rutinszerű újraindítási parancsok.
Hasznos lépés: először használd a wsl --shutdown parancsot. Készíts biztonsági mentést a fontos adatokról bármilyen regisztráció törlése, visszaállítás, takarítás vagy újratelepítés előtt.
A WSL 2-nek virtualizációs támogatásra van szüksége. A Microsoft azt állítja, hogy a WSL 2 megköveteli a Virtual Machine Platform funkciót és a hardveres virtualizációs támogatást. A Microsoft WSL GYIK-je is azonosít két szükséges Windows komponenst a WSL 2-höz: Virtual Machine Platform és Windows Subsystem for Linux. Lásd a Microsoft WSL GYIK-jét és a Microsoft kézi WSL telepítési lépéseit.
Nyisd meg a Windows funkciók bekapcsolása vagy kikapcsolása (Turn Windows features on or off) ablakot, és ellenőrizd, hogy a következő két funkció engedélyezve van-e:
Ha bármelyik funkció le volt tiltva, engedélyezd, és indítsd újra a Windowst.
A teljes kliens Hyper-V nem ugyanaz, mint a WSL 2 által használt virtualizációs komponensek. A Microsoft azt magyarázza, hogy a WSL 2 a Hyper-V architektúra egy részhalmazát használja, amelyet a Virtual Machine Platform biztosít. A teljes Hyper-V nem érhető el Windows Home-on, míg a WSL 2 támogatott Windows Home-on, ahol a WSL elérhető. A Docker is külön backendként kezeli a WSL 2-t és a Hyper-V-t.
Hasznos lépés: ha a WSL 2 backendet használod, először a WSL-t és a Virtual Machine Platformot ellenőrizd, ahelyett, hogy vakon engedélyeznéd az összes Hyper-V-vel kapcsolatos jelölőnégyzetet.
Ez konkrétabb tipp, mint az „Engine stopped”. A Microsoft WSL hibaelhárítási oldala azt mondja, hogy a 0x80370102 hiba jelentheti, hogy egy szükséges virtualizációs funkció nem érhető el. A Microsoft a Virtual Machine Platform, a BIOS/UEFI virtualizáció, a CPU virtualizációs támogatás és a hypervisor indítási konfiguráció ellenőrzését ajánlja.
Egy emelt jogosultságú PowerShell ablakban megvizsgálhatod a hypervisor indítási beállítását:
bcdedit /enum | findstr -i hypervisorlaunchtypeHa kifejezetten hypervisorlaunchtype Off-t jelent, a Microsoft hibaelhárítási útmutatója szerint engedélyezhető a következővel:
bcdedit /set hypervisorlaunchtype AutoEzután indítsd újra a Windowst. Lásd a Microsoft WSL hibaelhárítási útmutatóját.
Hasznos lépés: csak akkor használd ezt a boot-konfigurációs javítást, ha a tüneteid a virtualizációra vagy a hypervisorra utalnak. Ne változtass boot beállításokat pusztán azért, mert a Docker lassú, vagy egyetlen konténer hibásodott meg.
Ha a WSL normálisan indul, de a Docker Desktop még mindig nem, térj vissza a Docker réteghez.
Linux konténerek esetén a Docker WSL dokumentációja azt mondja, hogy a Docker Desktop a WSL 2 motort használja, amikor az a backend engedélyezve van. A jelenlegi Docker Desktop verziótól és a támogatott rendszertől függően a „Use WSL 2 based engine” (WSL 2 alapú motor használata) beállítás alapértelmezetten engedélyezve lehet, és nem feltétlenül látható.
Ha a Settings > Resources > WSL Integration (Beállítások > Erőforrások > WSL Integráció) hiányzik, és Linux-konténer integrációt vártál, a Docker megjegyzi, hogy a Docker Desktop Windows konténer módban lehet. Ebben a helyzetben válts vissza Linux konténerekre, ha Linux konténereket szándékozol futtatni.
Hasznos lépés: ne változtass konténer módot pusztán véletlenszerű hibaelhárítási lépésként. Erősítsd meg, hogy a projekted valóban Linux vagy Windows konténereket használ-e.
Használd a Docker Desktop Software updates (Szoftverfrissítések) szekcióját vagy a jelenlegi telepítőt a Docker hivatalos Windows telepítési oldaláról. A Docker kiadási megjegyzései gyakran tartalmaznak Windows- és WSL-specifikus javításokat és ismert hibákat, ezért érdemes ellenőrizni őket, amikor a probléma közvetlenül egy frissítés után kezdődik. Lásd a Docker Desktop kiadási megjegyzéseit.
Hasznos lépés: jegyezd fel a jelenlegi Docker Desktop és WSL verzióidat a frissítés előtt. Ha egy közelmúltbeli kiadási megjegyzés leírja a pontos tüneteidet, kövesd a dokumentált kerülési megoldást, ahelyett, hogy kapcsolódó registry vagy WSL-törlési parancsokat alkalmaznál.
A Docker Desktop Troubleshoot (Hibaelhárítás) menüje képes diagnosztikai információkat gyűjteni még akkor is, ha az alkalmazás indítási problémákkal küzd. A Docker is dokumentálja:
docker desktop diagnoseA Docker Desktop CLI dokumentációja azt mondja, hogy a diagnose parancs a Docker Desktop 4.60 és újabb verzióival érhető el. Ha a telepített verziód nem támogatja ezt a parancsot, használd a Troubleshoot felületet vagy a Docker dokumentált com.docker.diagnose futtatható útvonalát helyette.
Hasznos lépés: mentsd el a diagnosztikai azonosítót, és rögzítsd a pontos indítási hibát, mielőtt bármit visszaállítanál. Ez a bizonyíték hasznos, ha logokat kell összehasonlítanod, egy jelenlegi ismert hibát kell keresned, vagy támogatási esetet kell nyitnod.
A Docker Troubleshoot menüje tartalmazza a Clean up data (Adatok takarítása) és a Reset to factory defaults (Visszaállítás gyári alapértelmezésekre) opciókat. Ezek utolsó lépcsőfokú lehetőségek, nem rutinszerű javítások. A Docker biztonsági mentési dokumentációja azt ajánlja, hogy mentsd el a fontos image-eket, köteteket és Docker Desktop VM adatokat újratelepítés vagy visszaállítás előtt, amikor a Docker Desktop nem tud normálisan elindulni. Lásd a Docker biztonsági mentési és visszaállítási útmutatóját.
Amikor a daemon még elég jól működik ahhoz, hogy Docker parancsokat használj, mentsd el a fontosakat visszaállítás előtt. Például a fontos image-eket feltöltheted egy registrybe vagy mentheted tar archívumba. A kötet adatoknak saját biztonsági mentési stratégiára van szükségük.
Ha a Docker Desktop egyáltalán nem indul el, a Docker dokumentál egy Windows eljárást a Docker Desktop virtuális lemezének biztonsági mentésére újratelepítés előtt. Kövesd a jelenlegi hivatalos útvonalat a biztonsági mentési útmutatóból, mert a Docker belső tárolási elrendezése kiadások között változhat.
Hasznos lépés: ne kattints a Reset to factory defaults gombra, amíg nem tudod megválaszolni: „Hol van a fontos kötet adataim egyetlen másolata?”
Az újratelepítés ésszerű, miután megállapítottad, hogy:
Használd a jelenlegi telepítőt a Dockertől, ne egy régi, egy korábbi útmutatóból gyorsítótárazott telepítőt. A Docker jelenlegi Windows telepítési dokumentációja megkülönbözteti a felhasználónkénti és az összes felhasználó számára történő telepítési módokat. A WSL 2 backend a legtöbb felhasználót lefedi, míg a Hyper-V backend és a Windows konténerek eltérő telepítési és jogosultsági követelményekkel rendelkeznek.
Hasznos lépés: ha újratelepítés közben megváltoztatod a telepítési módot vagy a backendet, egyszerre csak egy változót változtass meg, hogy tudd, mi javította meg valójában a problémát.
Ez általában integrációs kérdés, nem bizonyíték arra, hogy a Docker motor leállt. A Docker azt mondja, hogy a WSL integráció engedélyezhető kiválasztott WSL 2 disztribúciókhoz a Settings > Resources > WSL Integration alatt. Magának a felhasználói disztribúziónak WSL 2 módban kell futnia.
Ellenőrizd a következővel:
wsl -l -vHa egy felhasználói disztribúció még mindig WSL 1-en van, a Microsoft a konverziót a következővel dokumentálja:
wsl --set-version <DistributionName> 2A Microsoft figyelmeztet, hogy nagy disztribúciók konvertálása időbe telhet és sikertelen lehet, ezért ments el fontos fájlokat egy nagy WSL konverzió előtt.
Hasznos lépés: különböztesd meg a „Docker daemon leállt” és a „ez a WSL disztribúció nem fér hozzá a Dockerhez” eseteket. Ezek különböző problémák, és nem ugyanazokat a javítási lépéseket kell kiváltaniuk.
Ha a Windows 11 VMware, Hyper-V, Azure vagy másik hypervisor alatt fut, a WSL 2 beágyazott virtualizációt (nested virtualization) igényelhet – virtualizációt, amelyet a külső virtuális gép a Windows vendég számára tesz elérhetővé. A Microsoft dokumentálja a beágyazott virtualizáció követelményeit, és megjegyzi, hogy a támogatás a host platformtól és konfigurációtól függ.
Hasznos lépés: ha ez egy vállalati VDI vagy felhő VM, erősítsd meg a beágyazott virtualizáció támogatását a platform adminisztrátorral, mielőtt időt töltenél a Docker Desktop újratelepítésével.
docker version paranccsal.wsl --version és wsl --status parancsokat.wsl --update, majd a wsl --shutdown parancsot, és próbáld újra a Dockert.0x80370102, kövesd a Microsoft célzott WSL hibaelhárítását.A „Docker Desktop Engine Stopped” egy tünet, nem egyetlen diagnózis. Windows 11-en a WSL 2 backenddel a legbiztonságosabb javítási út a Docker újraindítása, a WSL ellenőrzése és frissítése, a virtualizáció megerősítése csak akkor, ha a WSL kapcsolódó hibát jelent, és a Docker diagnosztika gyűjtése a destruktív visszaállítási opciók használata előtt.
A két legfontosabb elkerülendő hiba egyformán egyszerű: ne feltételezd, hogy egy leállt Windows Docker szolgáltatás az ok minden WSL 2 beállításnál, és ne regisztrálj le WSL disztribúciókat vagy állítsd vissza gyári állapotba a Dockert adatok biztonsági mentése előtt. Ezek a lépések egy indítási problémát adatvesztési problémává alakíthatnak anélkül, hogy az eredeti okot kezelnék.
Fix Tailwind CSS styles not updating in Vite React by checking Tailwind v4 setup, CSS imports, source detection, dynamic classes, HMR, and stale caches.
Javítsd ki a Python 3 ModuleNotFoundError hibáját a pip esetében Windows, macOS és Linux rendszereken ensurepip, operációsrendszer-csomagok, virtuális környezetek és interpreter-ellenőrzések segítségével.
Javítsd ki a GitHub SSH engedély megtagadva (nyilvános kulcs) hibát a gazdagép, az aktív SSH kulcs, a GitHub fiók, az SSO-engedélyezés, a távoli URL és a 22-es port hozzáférésének ellenőrzésével.
Git nem gyorsított push hiba javítása biztonságosan. Helyi munka védelme, távoli commitok beolvasása, egyesítés vagy újraalapozás kiválasztása, ütközések feloldása és push végrehajtása a változtatások elvesztése nélkül.
Javítsd ki az Nginx 502 Bad Gateway hibákat egy Node.js upstream fájllal az alkalmazásport, az NGINX naplók, a proxy_pass cím, a konténerhálózat, az időtúllépések és az újratöltés ellenőrzésével.
Kijavítottuk a TypeScript „A 'null' típus nem rendelhető típushoz” hibáját uniótípusokkal, szűkítéssel, alapértelmezett értékekkel és biztonságos állításokkal a strictNullChecks alatt.
Javítsa ki a Prisma Client nem generált hibát a generátor, a séma, a kimeneti útvonal, az importok, a verziók, a monorepo beállítás és a telepítési build lépések ellenőrzésével.
Javítsd ki a Node.js ERR_MODULE_NOT_FOUND hibát az ESM-ben az importálási útvonalak, fájlkiterjesztések, csomagtelepítés, exportálások, ESM mód és tiszta telepítések ellenőrzésével.
Javítsd ki a Git 'unable to get local issuer certificate' hibáját a megbízható háttérprogram azonosításával, a helyes CA-lánc telepítésével, és az SSL-ellenőrzés engedélyezve tartásával.
Javítsa a Mongoose MongoDB hálózati időtúllépési hibáit az időtúllépés típusának azonosításával, az Atlas vagy TCP elérhetőség tesztelésével, az URI helyesbítésével, és az időtúllépések beállításával csak akkor, ha az indokolt.
