Nether Portals Not Linking? How to Fix Wrong Connections

Portal travel is not a stored permanent pair. Each trip converts an entry position, searches for eligible portal points of interest, and ranks them by full 3D distance. That is why the same frame can stop being the destination after the network changes.

1. Confirm that you entered an activated portal. Write down the dimension, the source coordinates, the frame you arrived at, and which direction fails.
2. Record every observed frame, not just the intended one. Include old bases, generated portals and frames at unusual heights. An unrecorded candidate is invisible to your diagnosis.
3. Recheck the horizontal arithmetic. Floor X and Z by 8 toward negative infinity when entering the Nether. Y is not scaled, but it still affects candidate ranking.
4. Separate a wrong destination from a missing destination. If the trip lands in a new frame, the likely fault is candidate availability or generation, not that the converter chose the wrong block.
5. Do not rebuild everything yet. Establish whether another candidate wins, whether the intended frame is inactive, or whether only the return path differs.

When you have several known frames, compare them in the portal link checker. It uses the same converter and ranks the active portals you enter, but it cannot see unentered frames, terrain or exact entry blocks.

These causes are possibilities, not automatic verdicts. The same symptom can come from an active competitor, an invalid frame or an activation failure. Use the evidence in the linked section to narrow it down.

• Wrong exit or an old base

  Check first

  The actual destination XYZ compared with the scaled target.

  Possible cause

  Another active portal is nearer in 3D distance, or the frame you expected is not eligible.

  Best next action

  Record every known frame, then compare candidates and heights in the link checker.

  See the wrong-exit checks

• Outbound works, return goes elsewhere

  Check first

  A separate start point and result for each direction.

  Possible cause

  The return trip runs a new search from the frame you entered, not from the original source.

  Best next action

  Test both directions independently and compare the reverse target with the known frames.

  See the return-trip checks

• Two entrances share one exit

  Check first

  Both Overworld entrances plus every known Nether exit.

  Possible cause

  Both converted targets can include the same eligible portal inside their search areas.

  Best next action

  Compare the shared area, adjust an intended frame, and retest each route separately.

  See the shared-exit checks

• A new portal keeps appearing

  Check first

  Whether the intended destination is active, eligible and where you left it.

  Possible cause

  No eligible active portal was found, so the game generated one where terrain allowed.

  Best next action

  Inspect the expected frame first; do not rely on generated placement to match the ideal X/Z.

  See the generated-portal checks

• The map-nearest portal is ignored

  Check first

  Y and full 3D distance, not only the X/Z offset.

  Possible cause

  A closer height difference can beat a smaller horizontal offset in the candidate ranking.

  Best next action

  Compare X, Y and Z together and treat eligibility as separate from ranking.

  See the height checks

• A portal stopped working after a break or fire

  Check first

  Whether the destination frame is still complete and lit.

  Possible cause

  The destination was deactivated or destroyed, so it is no longer an eligible candidate.

  Best next action

  Repair or relight the frame if appropriate, then verify the candidate search again.

  See the inactive-destination checks

• The portal will not light at all

  Check first

  The outer frame shape, materials and ignition.

  Possible cause

  A structural or activation failure, not a coordinate-linking fault.

  Best next action

  Validate the frame with the size calculator instead of changing coordinates first.

  See the activation checks

The game does not teleport you to the ideal converted block. It converts the entry position, looks for eligible portal points of interest inside an approximate horizontal area, and selects the nearest candidate by 3D Euclidean distance including Y. If no active candidate is eligible, it can create a portal nearby where the terrain allows.

A frame that matches the ideal X/Z can therefore lose to a different active frame that is much closer vertically. The diagram below uses candidate A at the same X/Z but 56 blocks higher, and candidate B at the same height but 10 blocks east.

Edition changes where the game searches, not the 8:1 arithmetic. Java is often described as roughly ±16 X/Z into the Nether and ±128 into the Overworld; Bedrock is often described as roughly ±128 in both destination dimensions. The edition comparison below keeps these as approximate square areas, not guaranteed link radii.

Repair path for a competing frame

1. Find and record every active frame that could be inside the relevant candidate area.
2. Compare the actual converted target with each candidate in the link checker, including Y and the return estimate.
3. Build or adjust the intended frame closer to the target position, at a height you can safely reach. Moving one frame can change the result in both directions.
4. If a competing frame is genuinely unused, consider deactivating it only after you understand what depends on it. Breaking every extra portal is not a safe universal fix.
5. Test the outbound and return trips separately after each change.

Need to rebuild the intended pair deliberately?Follow the two-way portal linking steps.

Two Overworld entrances can convert to targets that are close together. If one active portal is near both targets, both outbound searches can select it. This is overlapping candidate eligibility, not a permanent two-to-one binding.

The two targets are separated by 8 blocks on X and 0 on Z. The shared frame is 4 blocks from each target in this simplified point model, so both can choose it when no closer candidate exists. The reverse trip then starts from the shared frame itself, which is why neither base is guaranteed to be the return destination.

Practical plan for two separate routes

• Record both Overworld entrances and every Nether frame near the overlapping targets.
• Compare all candidates in the link checker.
• Adjust or add an intended frame so each route has its own nearby candidate, then test each outbound and return trip independently.
• Do not rely on a universal separation number. Overlap depends on the edition's search area, Y, and the frame positions you actually have.

Outbound and return travel are separate searches. The return starts from the portal block you enter in the Nether, converts from that position, and searches the Overworld again. Nothing stores a reciprocal pair for you.

In this example, Overworld A at (800, 64, -400) can reach the Nether frame at (101, 64, -50). Entering that Nether frame converts back to the ideal Overworld target (808, 64, -400). Portal B already sits at (808, 64, -400), so the return can choose B. Portal A is 8 X blocks away from the reverse target.

If the return fails, compare the reverse target with every known Overworld frame, then check whether a new frame appeared. A complete tested round trip is the only evidence that a particular route works both ways, and only for the entry points you tested.

To rebuild a deliberate pair, use the step-by-step linking guide. To compare the reverse candidate search with your own frames, use the link checker's return estimate.

Portal creation can happen when the destination search finds no eligible active portal. The game then places a new portal at a location where it can fit, and terrain affects that placement. A generated frame is not promised to appear at the ideal X/Z.

In the related scenario, Overworld (800, 64, -400) projects to Nether (100, 64, -50). If the frame you expected there is dark, destroyed or simply absent, the next entry may create a replacement somewhere nearby instead of using it.

Checks when a new frame keeps appearing

• Is the expected destination frame still complete and lit?
• Is it inside the relevant candidate area for your edition and entry point?
• Did an earlier generated portal replace the route you thought you had?
• Is another active frame nearer, so the new frame is not the only issue?
• Did the vertical position change enough to affect the 3D ranking?

Reopening or rebuilding an existing frame does not by itself guarantee that it becomes the winner when another candidate is closer. Record the full network, compare it in the checker, repair the frame you want, and test both directions. Do not predict the exact block of a game-generated portal from a coordinate formula alone.

Need a guaranteed valid frame for the intended destination first?Check whether your obsidian frame is valid before changing the route.

Y is never divided by eight, but it is part of the 3D distance used to rank eligible candidates. The horizontal search area decides which frames are considered; height helps decide which considered frame wins.

Against the converted target (100, 64, -50), candidate A matches X and Z but is 56 blocks away vertically. Candidate B is 10 blocks away horizontally and shares the target height, so the simplified 3D comparison favors B. A frame directly above or below the target can lose to a frame that looks farther away on a map.

Do not blindly copy the target Y if that height is unsafe, flooded, or inaccessible. The goal is a reachable frame that is genuinely closer in 3D distance, not a coordinate that is merely exact on paper. Use the link checker to compare the frames you actually have.

The coordinate conversion is identical in both editions. What differs is the documented candidate search area around the converted target.

These are square, axis-aligned approximations, not circles and not a guaranteed safe spacing between portals. Boundary behavior, game versions, server software, plugins and mods can change what you observe. Do not assume a Bedrock-specific glitch is caused by the search radius without separate evidence, and do not assume the two editions behave the same.

If the edition changes which frame wins, record the same coordinates in the link checker using the selector and compare the candidate table, not only the ideal target.

Normal vanilla travel has no unlink button and no permanent pairing to switch off. Changing the eligible active portals, or changing where you enter, changes the outcome of later searches. There is also no single spacing value that guarantees two portals will never interact.

A safer sequence

1. Record every portal in both dimensions and the direction that fails.
2. Identify the destination the game currently chooses, then compare it with the intended frame.
3. Move or add an intended counterpart near the converted target, at a reachable height, and retest.
4. Only after understanding the consequences, deactivate or remove an interfering frame. Explain what changes, why it may help, and what could break before you do it.
5. Run an outbound and return check again, and watch for a newly generated frame.

Breaking a frame does not automatically unlink anything else. Another active portal can become the winner, and a missing destination can lead to a new generated portal. The checker's network comparison is more useful than guessing a safe distance.

A dark frame that refuses to light is a different fault category from a portal that works but chooses the wrong destination. Check the structure before changing coordinates.

• The outer frame must be a complete valid obsidian rectangle.
• The minimum outer size is 4 wide by 5 tall; corners may be omitted.
• Ignition must reach the inside opening, and inappropriate blocks must not obstruct it.
• A frame with a broken edge or wrong material is not a linking problem.

Use the portal size calculator for valid dimensions, opening size and obsidian counts. If the frame lights and then routes incorrectly, return to the symptom checks above.

A destination that becomes inactive or loses part of its frame is no longer an eligible candidate. Re-entering the source may then generate a new destination or select another active frame. This can look like a sudden linking bug even though the route changed in the world.

• Inspect the expected destination for missing obsidian or an extinguished portal.
• Record its coordinates before repairing it, especially if a generated frame appeared.
• Repair or relight a valid frame where appropriate, then check nearby active candidates.
• Compare the outbound and return searches again instead of assuming the old pair is restored.

A ghast or explosion can deactivate a Nether portal, but do not assume every break is a linking fault. Confirm the visible state first, then use the checker to see which entered active frame is likely to win. For frame repairs, use the size calculator.

Follow the path from the symptom you can actually observe. The tree is a nested text list so it wraps on a small screen and stays usable with a screen reader.

1. Can you enter an activated Nether portal?
   • No: Check the frame and ignition. Use the Portal Size Calculator (separate issue).
   • Yes: Does it create a new destination portal?
     • Yes: Check that the intended destination is active and in range, then record the generated portal.
     • No: Does it arrive at the wrong existing portal?
       • Yes: Compare candidate X/Y/Z in the Link Checker.
       • No: Test the return trip independently.
         • Returns elsewhere: Compare the reverse target and Overworld candidates.
         • Returns correctly: The pair works for the tested entry; keep monitoring the network if frames are added or changed.

Reaching the bottom branch is a success observation for the route you tested, not a permanent guarantee. Adding a new active portal, changing an entry point or a later world change can alter the candidate search.

These are illustrative simplified-model examples, not recorded gameplay. The arithmetic is deterministic; exact in-game frame selection can differ at boundaries, entry blocks and points of interest.

1. Correct X/Z, winning candidate decided by height

Overworld (800, 64, -400) projects to Nether (100, 64, -50). Candidate A at (100, 120, -50) is 56 blocks away because it is 56 blocks higher. Candidate B at (110, 64, -50) is 10 blocks away. In the simplified 3D ranking B wins, even though A matches the target on a map.

Next step: add A and B to the link checker and compare the full candidate table before moving a frame.

2. Two entrances reach one shared exit

Base A at (800, 64, -400) projects to (100, 64, -50). Base B at (864, 64, -400) projects to (108, 64, -50). The shared Nether portal at (104, 64, -50) is 4 blocks from A's target and 4 from B's target. Both can be eligible with no closer candidate, but that does not prove the reverse trips return to their respective bases.

Next step: record the shared frame, compare both routes, then give each route an independently matched destination if you need separate pairs.

3. The outbound works, the return chooses another Overworld frame

Overworld A at (800, 64, -400) can reach the Nether exit at (101, 64, -50). The reverse conversion from that exit is the ideal Overworld point (808, 64, -400), where portal B already sits. Portal A is 8 X blocks away, so the simplified return model predicts B.

Next step: run the round-trip evidence checklist above, then compare the reverse candidates in the link checker.

4. Negative coordinates and the floor trap

Overworld (-9, 70, 9) projects to Nether (-2, 70, 1). Converting Nether X -2 back gives an ideal Overworld X of -16, not -9. That asymmetry comes from flooring each conversion. It is not evidence by itself that a portal is broken.

Next step: use the homepage converter to check arbitrary negative or decimal positions, then verify the actual frames in the checker.

The coordinate examples use the same floor converter as the rest of the site, and automated tests compare them with independently written expected values. The search descriptions are teaching approximations from the community-maintained Minecraft Wiki. No in-game Java or Bedrock play test was performed for this guide, and no specific game release is claimed as verified.

The checker estimates from the portal points you enter. It cannot see hidden or unentered frames, the exact entry block, point-of-interest or chunk boundaries, terrain, generated placement, server plugins or modded rules. When a result looks wrong, treat it as a hypothesis to verify in your world.

Read how the portal-checking model works for the full converter rules, search-area approximations and known limits.

Sources

• Minecraft Wiki: Nether Portal— Frame dimensions, obsidian counts, and the 8:1 dimensional ratio.
• Minecraft Wiki: Nether portals tutorial— Portal linking behavior, candidate search areas, and edition differences.
• Minecraft Wiki: Point of Interest— Portal blocks as points of interest used by the game search.
• Minecraft Wiki: Nether hub tutorial— Converting endpoints and building routes between Nether portals.

Minecraft Wiki is a community-maintained reference, not official Mojang documentation. This is an independent fan-made guide and is not affiliated with or endorsed by Mojang Studios or Microsoft.

• Compare your known portal network and see the separate return estimate.
• Calculate the ideal Nether coordinates for one source position, including negative floor behavior.
• Follow the two-way portal linking steps to build a deliberate pair from scratch.
• Check whether your obsidian frame is valid before treating a dead portal as a linking fault.
• Moving a base or building a route to the destination?Plan a different Nether route between the endpoints.
• Read how the portal-checking model works, including its source and uncertainty rules.