Find the last stage that definitely succeeded. “The jailbreak failed” combines several independent problems: the entry page may not load, the application trigger may not execute, the kernel stage may panic, or a healthy loader may receive an incompatible payload. Record the on-screen messages before changing anything.
Reviewed 10 October 2026. Recovery actions depend on the chain and failure mode. A successful file transfer does not confirm payload execution.
Stage-by-stage diagnosis
| Observed result | Likely boundary to inspect | Useful next check |
|---|---|---|
| The entry page never appears | Browser access, DNS, web server, certificate or path | Check host request logs and exact URL. Confirm the console and server can communicate on the LAN. |
| A firmware-rejected message appears | Project allowlist | Compare the real system version with the selected source gate. Do not remove the check. |
| A game loads without a Lua notification | Title/version, account or save preparation | Verify exact title ID, correctly imported save and account match. |
| A receiver starts but the script does nothing | Format or destination port | Read the application's reported port and send the expected JS/Lua/JAR format. |
| A race stalls or the console panics | Kernel exploitation | Preserve the stage/error, follow the project's clean retry guidance, and retest the same revision. |
| A TCP sender cannot connect | IP, listener lifetime, port or network isolation | Confirm loader-ready message, current address and whether the entry app must stay open. |
| Transfer completes but no feature appears | Payload ABI, firmware support or payload startup | Check console output and logs; compare the payload release with the actual loader. |
| Failure starts after a plugin or auto-start change | Background environment | Restore the known-working configuration and introduce one component at a time. |
This table is a diagnostic workflow rather than an exhaustive list of console error codes. Use it to choose the smallest useful observation before replacing files, editing databases or reinstalling software.
Use the correct protocol
The Remote JAR Loader documents a Java JAR receiver normally on 9025. Native payload ELF delivery commonly moves to 9021 after a kernel stage; old primitive loaders can use 9020. These are different receivers. The Payload Dev loader accepts native payloads and runs them in separate processes, so a payload crash may leave the loader alive.
The Relapse Y2JB port sends its JavaScript to the userland receiver before native ELFs are sent to 9021, and currently requires YouTube to remain open. Never apply a close-app instruction from another host just because both eventually expose the same native payload port.
Keep a small port record with your files: entry receiver, native loader, FTP server, web interface and log receiver. FTP and HTTP service ports do not accept the same byte stream as a raw payload socket. From your computer, use the console's LAN address; 127.0.0.1 identifies the computer itself. On-console code can use that same address to mean the console.
Retry kernel races cleanly
The Relapse stability notes distinguish a stalled browser attempt from a kernel hang or panic, recommending reboot before retrying the latter. The Poops Java release notes describe cleanup changes intended to reduce later panics. Those implementation changes explain why release revision and last successful stage belong in a report; a generic success-rate percentage does not describe every console.
After an unsuccessful race, follow that exact project's instructions. Do not stack another chain onto unknown memory state. Let the console complete any storage check it initiates after an abnormal shutdown. Once it is responsive, begin with the original minimal setup. Count attempts and successes yourself using the same revision and conditions if you want a useful local reliability measurement.
Separate sender success from loader success
The official Windows sender source writes bytes to a TCP stream and reports transmission completion. It does not query a console-side result. If the file was delivered but nothing appears, verify that it is the intended release artifact, that the loader supports it and that firmware-specific initialization succeeded. Re-sending an already running daemon can create another problem, so observe first.
For etaHEN, use the setup guide to identify configuration and logs. The Plugin SDK documentation notes USB plugin precedence and potentially slow loading through kstuff. Check for a second copy on removable storage before concluding that an internal update failed. Temporarily return to a minimal plugin configuration for a controlled retest.
Preserve firmware during diagnosis
An exploit failure by itself is not evidence that a firmware update, reinstallation, factory reset or storage rebuild is required. Such actions can remove application/save/cache preparation or change the firmware that the route needs. For an actual boot or system-storage problem, follow recovery and reinstallation; for personal-data protection, read backups and save data. Keep these tasks separate from ordinary race retries.
A useful bug-report record
Console model and real firmware:
Exploit repository, release tag or commit:
Entry application title ID and version:
Account/save/backup preparation:
Kernel payload revision:
Native loader and payload revisions:
LAN address and receiver ports:
Last confirmed successful stage:
Exact error or panic stage:
Cold boot versus rest resume:
Auto-start plugins and services:
Reproduction steps and attempt count:
Relevant logs, with personal identifiers removed:State what changed since the last successful session and include the smallest reproducible sequence. Avoid publishing account IDs, credentials or private savedata in a report. Read the project's existing issues and reporting guidance before filing a new one. These details let maintainers distinguish a porting gap, regression and setup mismatch without guessing.