Factorio Railway Signals: How They Work and Network Building

When I first built a four-way intersection, the first train ran fine, but the moment the second one arrived, it stopped in the middle and the entire network jammed up. Once I switched the entrance to a chain signal, the flow improved dramatically, and I finally understood that normal signals and chain signals have completely different roles.

This article is written for beginners to intermediate players in Factorio vanilla versions 1.1–2.0 who are starting to build rail networks. It breaks down signal usage by explaining the difference between stop positions and reservation ranges, helping you design intersections and station approaches that don't jam. By following the basic pattern—dual-track one-way main lines, chain signals at intersection entrances with normal signals at exits, and a separate waiting line outside the main line at stations—you can significantly reduce common deadlock scenarios. I'll also walk through how chain signal placement works at intersection internals, with practical advice that accounts for how best practices have shifted in the 2.0 era.

Version scope and terminology foundations

This article covers Factorio vanilla versions 1.1–2.0 rail signals. The basic specifications for normal rail signals and rail chain signals are consistent across this range, and the core rules you should learn first—chain signals at entrances, normal signals at exits, and trains are managed in blocks—haven't changed. The official Wiki's 'Tutorial: Train signals' uses these same foundational principles.

This article sticks to official Wiki terminology: normal rail signal (Rail signal), rail chain signal (Rail chain signal), block, path reservation, intersection, and stacker (waiting line). Shorthand like "chain signal" or "normal signal" refers to these formal names. Keeping terminology consistent helps clarify "where do we stop trains?" and "how much space do we need free before entering?"—questions that can get confusing fast if terms drift.

A key principle to lock in early: trains only read signals on their right side relative to their direction of travel. This works naturally on dual-track one-way systems, but if you want bidirectional operation on a single track, you'll need signal placement on both sides for each direction. This is a classic gotcha—your signals look placed correctly, but one direction of train simply can't read them, so they never move. I spent embarrassing amounts of time stuck on this early on, wondering why trains wouldn't budge when the track looked complete.

On version differences, the main thing is intersection internals. The core logic is the same in 1.1, but older guides often show intersections with minimal internal subdivision. By 2.0, community observation reports that "detailed internal subdivision of intersections using chain signals is becoming standard practice," with players reporting it's easier to manage. This reflects community best practice, not an official spec change. This article keeps the fundamentals unchanged while noting how 2.0 environments handle this as one valid option.

One more principle that even intermediate players overlook: signal and rail placement/removal triggers a full path re-validation for all trains. This is documented under 'Railway/Train path finding', and while usually helpful, on large networks it becomes noticeable. I once adjusted main-line signals and every moving train suddenly decelerated in unison—the whole screen went "uh oh, I broke something." Nothing was actually broken; re-validation was just running. With heavy train traffic, this effect is real, so schedule major edits during quieter periods is solid operational practice.

From here onwards, I'll explain principles shared across 1.1–2.0, while weaving in what works well in 2.0 practice around intersection chain signal subdivision. Locking in terminology now means everything from block division to path reservation visibility to stacker placement clicks into place.

Railway signal fundamentals: blocks and direction of travel

Blocks—the minimum safety unit

To understand Factorio rail signals, the first thing to cement is this: "signals divide track into blocks." A block is basically a safe zone for trains. The core rule is one train per block maximum. That's your collision prevention foundation. If you only watch signal colors, it seems confusing. In reality, trains are just checking "is the next section ahead free?"

When you place normal signals evenly along a straight track, each signal creates a new block. Once the front train clears into the next block, the train behind can enter the previous one. So instead of thinking "one long stretch of track," frame it as a sequence of small, safe compartments. Once I internalized this, signal placement stopped feeling like symbol memorization and started looking like area management.

Confusion at branches and junctions often comes from not tracking block division. If two branch paths reconnect to the same block, they can't be used simultaneously even though they look like separate routes. Conversely, if you properly subdivide with signals, non-intersecting paths stay independent. The basic pattern of chain signals at intersection entrances, normal signals at exits ultimately exists because you want to prevent trains from stopping inside the dangerous intersection area, only letting them proceed when they can fit cleanly into the safe block beyond.

You'd benefit hugely from seeing Figure A here—watching a right-hand-traffic track show only the right-side signal being read by each train makes it instantly click that signals aren't decoration; they're directional gates.

Right-hand traffic and bidirectional signalling

Another critical rule: trains only read signals on their right side relative to direction of travel. A signal on the left might as well not exist if it's not oriented for that direction. Dual-track one-way is beginner-friendly specifically because you can line up signals naturally on the right side of both tracks.

Single-track bidirectional is different. If one track needs to work both ways, you must place mirrored signals on both sides so each direction can read its side. Skip this and you'll have trains that literally cannot perceive their signals—they sit waiting indefinitely even though track exists. I ran into this early trying to save rails. Single-tracked it, but only put signals on one side. One direction of trains just... didn't move. Track was connected, fuel was there, and I spent too long suspecting everything else. The cause was simple: trains couldn't read the signals because they weren't on the right side.

This same property cascades through single-track sidings and branches. Bidirectional single-track is possible but invitation for wiring-mistake disasters, especially at scale. The official Wiki's 'Tutorial: Train signals' assumes parallel one-way tracks as the easier baseline. As train count grows, this "trains read only their right-side signal" rule becomes fundamental to your whole design.

Tutorial: Train signals

wiki.factorio.com

Block visualization for self-diagnosis

When signals confuse you, the fastest fix is enable block visualization. Written explanations pale next to watching the track actually color-code into regions. Straight sections, branches, merges, and intersections all reveal their block structure instantly. Figure B shows a color-coded example—you see one block = one train made literal.

The trick is simple: first, check if a block boundary sits where you want trains to stop. Next, confirm that branches and merges aren't all one giant block. Example: if an entire intersection is one color, only one train fits. If it's finely divided, multiple trains on non-conflicting paths can move together. Older guides showed intersections without much internal subdivision, but 2.0 practice often does divide internals with chain signals, and frankly, that's usually cleaner to work with.

The easiest finding is "looks like separate routes but same color"—that signals a block shortage. If trains queue across unrelated alternate routes, it's typically unsplit blocks forcing them to wait for each other. Conversely, if your exit-side blocks are too short, trains can't fully clear the intersection before hitting the next stop—their rear stays inside the intersection, still blocking others. Visualization makes this obvious; trying to reason it out visually fails all the time.

Design track layouts as colored compartments, not route diagrams. Once you can see that, the role of chain versus normal signals practically designs itself—you already know where you want independent blocks and where you want trains to queue.

Normal rail signals versus rail chain signals

Normal signal behavior and placement rules

Normal rail signals are straightforward: they check only one block ahead. They don't care about the branch or intersection beyond it. Green ahead, go. Red ahead, stop. This simplicity means normal signals suit places where trains can wait a long time without causing problems.

Classic examples: spacing out your main line at regular intervals, or the interior of a waiting line before a station. Trains waiting there doesn't block the intersection or cascade problems to other directions. Actually, normal signals subdividing a straight section at intervals lets the prior train advance just a bit, pulling slack back into a tightly packed column. You get more throughput density on straightaways this way.

Early on, I threw all my signals together without distinction. Normal signals at intersection entrances let trains enter the intersection, but if the far side is blocked, trains stop inside. That jams everything. Normal signals only see one block, so the behavior is technically "correct"—they just entered a block that exists, so they went. Doesn't matter that the block ahead is locked up. This taught me normal signals aren't universal; they're tools for creating safe waiting zones. Different tool for a different job.

Figure C makes this clearer using "stop position" and "reference range" labels. Normal signals commit to fixed stopping positions; that's their strength.

Chain signal behavior and four states

Chain signals are far more cautious. They check the next signal or the exit of the path ahead, not just one block. They don't just ask "is it free?" but "can I reserve a path to that exit without getting stuck?" Basically, a signal that only lets trains through if they won't jam inside.

This is essential for intersections, branch entrances, and single-track entries—places where a stopped train is a disaster. The official 'Rail chain signal' and English 'Railway' articles assume chain signals are built around the idea that they see all the way to the exit.

Chain signals display four states: green, yellow, red, and cyan.

That cyan state is what makes chain signals seem mysterious. Cyan doesn't mean "fully clear"; it means different exits have different availability—one direction open, another blocked. Picture a four-way intersection entrance showing cyan: maybe the right-turn exit is free but the straight-ahead exit is occupied. A self-driving train sees this and adjusts. That's why cyan exists.

Another subtle factor: self-driving trains waiting at a chain signal perform periodic path re-exploration. Community reports suggest "around 5 seconds," though no official documentation pins an exact number (reference: Railway/Train_path_finding). This article phrases it as "trains re-explore after waiting a period (community reports suggest ~5 seconds)" to note the source uncertainty.

Compare using the table below, which mirrors how the real behavior shakes out:

Rail chain signal - Factorio Wiki

wiki.factorio.com

Where to queue trains, where never to stop them

When you're unsure, the rule is dead simple: queue trains with normal signals; use chain signals where stopping would jam everything downstream. This alone cuts accidents dramatically.

Picture a station stacker: the queue inside uses normal signals. Trains are supposed to wait in columns there, so staying put is their job. Now picture an intersection or roundabout entry: stopping there cascades failure backward, so use chain signals there instead. The philosophy flips: only let in trains that will clear.

I see one common mistake: treating stacker internals as chain signal territory. Then trains over-think, reserving so far ahead that they won't queue properly even with space available. Worse, they choke the main line upstream while the stacker stays weirdly empty. Fix it by making queue zones normal signals and reserving chain signals only for the critical gates (intersection entries, single-track entries), and suddenly the layout snaps into place. I rebuilt a station this way once and couldn't believe the difference.

The official deadlock fix examples modify intersection entrances to chain signals, and that's the same logic: the intersection is for passing through, not waiting. Signal choice reflects where you build patience into the design.

Jam-free intersection signals: chain at entry, normal at exit

T-junction: minimal setup that flows

A T-junction looks simple, and it is—it's where the basic rule shines cleanest. One idea: chain signals on entries, normal signals on exits. Trains then check "is the path clear to my goal?" before entering. They won't jam in the middle.

Concretely: place a chain signal on each inbound arm of the T, then place normal signals at the first safe position in each outbound direction. One detail: don't put the exit signal too close. If the distance from exit signal to the next signal can't fit your longest train, the rear stays in the intersection. That's "buttstrap overlap," and it jams everything.

I learned this the hard way running 4–8 car trains. My T-junctions had short exits. A train turning right would be mostly out, but its last car still occupied the center, blocking everyone else. Widening that safety margin solved it instantly.

The official Tutorial leans heavily on modifying intersection entrances to chain signals to prevent mid-intersection stops. A T-junction is a great training example—minimal setup, easy to replicate. Master "chain at entry, normal at exit, safe margin past the exit," and congestion drops sharply.

Four-way junctions: internal blocks for simultaneous flow

To push throughput on a four-way, add internal chain signals dividing the intersection. The aim isn't one-train-at-a-time. It's letting non-conflicting paths run together.

Example: north-to-south and east-to-west do conflict and can't both go. But north-to-east and south-to-west don't conflict. If you leave the center as one massive block, even non-conflicting routes get locked into sequence. Dividing the center and curved sections into several blocks means each entry chain signal reserves only what it needs, leaving free blocks for parallel traffic.

Certain setups I've seen in the community can push four trains simultaneously through a four-way. They're not always all four, but the jump from "only one direction moves at a time" to "four non-conflicting trains can flow in parallel" is huge. With heavy traffic, this matters more than you'd think.

The trap is overfilling with chain signals. If you chain-signal all the way from far upstream through the intersection, reservations get huge and trains become overly hesitant. I once tried to be clever and linked entry reservation far into the intersection—result was trains held back even when the center was empty. Subdivision grain depends on intersection size and traffic. Small junctions need minimal central division; big junctions need more. But bigger is not always better; fit to your actual throughput.

Figure E illustrates cleanly: entry chains, internal conflict zones subdivided, exit normals taking the through-traffic. Intersections become passing corridors, not waiting areas.

Branches, merges, and single-track entry

Branches and merges aren't flashy but are real congestion sources in practice. Why? Because route choice and merge conflict happen at the same spot. Same foundation: chain before the split/merge, normal after. For splits, a chain entrance ensures trains only enter if their chosen exit is clear. For merges, a chain entrance prevents trains from penetrating a merge point when the downline is jammed.

Cyan shows up at branches: one exit might be free, another might be packed. Chain signals handle this per train. Normal-signal-only branches risk having one train stop mid-split because its exit was taken, then blocking the other exit too.

Merges are dangerous at the junction itself. A train waiting at a merge point blocks the other side from entering at all, which cascades backward through both source sections. Protect merge entries with chain signals—"only enter if you'll clear"—then use normal signals past the merge.

Single-track connectors follow the same pattern. Single tracks jam easily with any opposing traffic, so chain signals guard the entry, checking both that the single section and the far exit are reserved clear. Figure F shows this plainly: even though it looks modest, the chain signal discipline is what keeps single-track from deadlocking.

Complex factories often grind not at flashy intersections but at the accumulation of branches, merges, and single-track segments. Those look boring so they're neglected, but they're the throughput bottleneck. Decked-out intersections upstream mean nothing if the entry isn't guarded and the following merge is uncontrolled. Chain at entry, normal at exit works everywhere.

Station connections and waiting lines (stackers): keeping main lines clear

Stacker anatomy

Sharing stations across multiple trains fails if the waiting queue eats into your main line. Stacker—a dedicated off-line holding area—is the fix. I learned this when mining-station hopping: trains backed up to the main line, the main line gridlocked, and adjacent intersections froze. Inserting a separate wait zone ahead of the stations let me park trains without the cascade. Day-and-night difference.

The structure is straightforward: main line branches into stacker, stacker has multiple queue lanes, lanes feed to open stations in order. If two stations share resources, one shared stacker feeds both. Figure G shows the typical layout: it's basically a parking lot before the stations.

Elements: an entry-branch segment splitting main traffic toward stacker, a fan-out section directing trains to waiting lanes, and a merge section from the lanes toward stations. The key insight: stacker internals are the waiting zone, not the stations or main line. While stations are occupied, queues absorb the trains. The moment a station frees up, the next train advances.

Design by first deciding where waiting happens—that separation (main line ≠ stacker ≠ station) prevents bleed.

Entry chain, internals normal, and why

Signal placement inside stackers trips people up. The rule: stacker entry is chain, queue lanes are normal.

Chain at entry is your gatekeeper. It asks, "Can this train fit into a free lane, and can it eventually clear to its destination?" If the stacker is full and the station is jammed, the entry chain stops the train before it half-enters the split. A normal signal there would let trains partially enter, jamming the split itself, and then you've lost the whole point of having a stacker.

Inside the stacker, though, normal signals reign. Waiting lanes aren't about path prediction; they're about parking trains in neat lines. Queues work best under normal signals, which just compress trains together. Chain signals in the waiting area over-reserve, making trains reluctant to queue properly. I've made this mistake thinking "chain signals are always smarter," and it backfired. Stacker internals are the opposite—they benefit from simple, permissive normal signals.

Capacity and train length math

Stackers sized on a whim ("two or three trains?") fail the instant traffic grows. Size to the actual number of trains using the destination. A three-lane station doesn't mean three-lane stackers. You need to absorb the peak concurrent trains using those three stations. If two are unloading and one is docking and a fourth arrives while the first is still incoming, your stacker catches four.

Length is critical too. Each lane must fit your maximum-length train end-to-end. A train half-in-lane and half-blocking the split defeats the purpose. I trimmed lanes to save space once and created a Hydra of problems: usually fine, but under heavy load, buttstrack overlap into the main line.

Sizing formula: count the trains headed to this group of stations, add a buffer for arrival clustering, give those trains that many lanes, and make each lane as long as your longest train. Scale is easy. Scalability comes later. For now, measure twice, build once.

Common failures and deadlock recovery

Four classic deadlock patterns

This is where beginners wreck everything. The cruel part: it works on one train. Two trains, three trains, and suddenly everything stops. I wasted huge spans of time on this early.

Pattern one: intersections with only normal signals. Looks like signal coverage exists, so you're confident. In reality, trains enter the intersection, then stop waiting for a path to clear. Now the northbound blocks east, east blocks south, south blocks north, and everyone waits forever. The official Tutorial shows the fix: convert intersection entries to chain signals. Change the logic from "is the next block ahead free?" to "is the full exit path available?"

Pattern two: short exit sections. Even with proper entry chains, if the exit-side block is too short, the train rear occupies the intersection while the front is technically "out." Then it still blocks everyone else. I've seen this in otherwise correct intersections. Check: does the block after the intersection fit a full train? If not, extend it.

Pattern three: undersized roundabouts under load. Roundabouts look efficient and charming. Early on, I loved them. Add traffic and the inside fills with waiting trains—each trying to exit, none able to. Small-diameter roundabouts choke at scale. Either go bigger or switch to a plus-shaped intersection.

Pattern four: single-track bidirectional without passing sidings. Two trains meet head-on on a single track with no way around. They both wait, forever. Auto re-planning can't help without an alternate path. Single-track works only if you've mapped where trains pass each other.

A fifth underlying issue: mixing directional signals on the same block. One block can't cleanly serve both directions. Trains halt to reconsider, and a loop of re-planning can kill flow. Decide direction per track, enforce consistency, and subdivide if needed.

Tutorial: Train signals

wiki.factorio.com

Diagnosis: which block is the conflict?

When jammed, resist the urge to spam signals. Spot which block is causing waits, and what path it's blocking, then you'll fix it fast.

A normal-signal-only intersection shows trains stopped inside the intersection. That's your sign: entry logic is too permissive. Fix: convert to chain entries and subdivide the interior as needed.

Short exits show the train's front out, back in the intersection. The culprit is visible: extend the exit block. Intersection logic might be perfect; the next block is just too short.

Roundabout deadlock shows multiple trains in the circle, each waiting for its exit. The issue is scale mismatch to traffic. Either grow the circle or reroute via straight intersections.

Single-track deadlock is trains facing each other at the same location, neither moving. Passing siding missing or both trains heading to it simultaneously.

Directional mix shows trains holding and re-planning instead of flowing. Audit path ownership: does each train's route stay in one preferred direction?

The diagnostic shortcut: look at where trains are stopped, not at the signals themselves. If they're inside danger zones, design is guilty. If they're in queues, capacity might be short. If they're waiting at a split while the target is empty, gates are too cautious.

The official config examples, collected at community layout sites, show jammed networks corrected by moving stops out of intersection interiors back into dedicated queuing zones. Not a signal tweak—a role reassignment.

列車ネットワーク/配置例 - factorio@jp Wiki

factorio@jp Wiki

wikiwiki.jp

Recovery: temporary blocks, manual moves, permanent fixes

Once everything freezes, the rescue is simple: extract the trains from the danger zone. A deadlock is just one loop; break the loop and flow returns.

1. Temp-block the inflow

Slap signals at entry points to stop new arrivals. This prevents the jam from spreading. It looks harsh, but "pause" beats "let it seethe."

1. Hand-move trains to safety, one at a time

Manually shunt each stuck train to a free block (past intersection exits, to passing sidings, outside roundabouts). Don't rush—watch each move, because one departure might unlock everything else. I once got impatient and shuffled multiple trains at once, creating a new collision elsewhere. Patience wins here.

1. Redesign the zone

Once free, don't just clear and restart. Fix it: convert intersection entries to chains, subdivide internals, extend exits, create passing sidings for single-track, enlarge roundabouts, or replace them with four-ways. The official recovery examples show this level of overhaul.

1. Enforce directional consistency

Standardize one-way per main route. Single-track stays bidirectional but with mapped passing points. Once this rule holds network-wide, wiring errors become rarer.

A practical note: if you've ever hand-moved a train from an intersection middle, that intersection needs redesign. It's not a rare accident; it's a design flaw surfacing under load.

Design principles for expanding networks

Dual-track one-way standardization

As you grow your network, lock in dual-track one-way as your foundation. Pick a direction (left or right), assign it to each line, and watch signals fall into place. At first, bidirectional looks more efficient ("fewer rails needed!"), but branch and station complexity explodes later.

The win is consistency. Every intersection, branch, and station follows the same directional rules. Signal placement choices become predictable. In multiplayer, if your design is a rule, others extending your lines won't accidentally create bidirectional tangles.

Single-track bidirectional saves rails upfront but costs back-end: passing sidings, two-sided signals, direction logic. For a backbone network, the simplicity of one-way pays huge dividends. Single-track can remain in support branches and temporary expansions, but your main arteries stay simple.

This principle cascades. If your core philosophy is clear, extensions snap in without reinvention. Save rail cleverness for places where complexity doesn't spread.

"Minimal chain signals" principle

Chain signals are useful but not infinitely so. The trap: more chain signals = more lookhead = more mutual blocking = lower throughput. Counterintuitive? Yep.

Use chains only where you must make an entry call: intersection points, branch splits, single-track gates. Long straightaways, queues, and exit zones? Normal signals. Chain signals create reservations that ripple backward; overuse them and trains become overly hesitant, actually reducing flow.

The official Tutorial and Railway guides make this same call. Chain signals are "don't-jam-inside" gates, not universal traffic controllers. I once over-chained a support line out of paranoia and watched capacity drop. Simplifying to essentials fixed it.

2.0 practice includes finer subdivision inside intersections to allow parallel non-conflicting flows. But this stays surgical: only where needed, and never cascading far upstream.

Modification risk management

A detail that scales invisibly: adjusting one signal ripples across the entire network. The whole path-finding engine re-runs for every train. In small bases, unnoticed. In sprawling ones, it's chaos. I've moved a single intersection signal during peak traffic and watched a cascade of train slowdowns ripple across the map.

So modify in stages, not one-shot rewrites. Rework one entrance, observe flow, fix the next. It's slower but vastly more diagnoses when (not if) something worsens. Session saves become valuable: revert if a change backfires. Large networks need staged rollout.

Practical checklist

Forget theory for a moment. Here's what I actually do when a network is sludgy:

1. Unify main-line direction (one-way or one-way, pick a convention and stick)
2. Pick the most-jammed intersection and convert its entry to chain signals
3. Verify the exit block behind that intersection fits a full train
4. Add a stacker (waiting lines outside the main) ahead of multi-train stations
5. Observe that trains now stop outside danger zones, not inside them

Those five moves often unstick a network more than deep theory. I've seen sprawling overhauls needed less often than simple "move the waiting zone off the main line" fixes.

Check with question blocks: Where do trains park? Is it a safe zone, or does it jam critical routes? Is it a stacker, or the main line itself?

Terminology summary and quick reference

Keep this saved. When designing, I don't memorize all the logic—I just check two questions: "How far ahead does this signal peek?" and "Is this a place trains should queue?"

• Normal rail signal: Sees one block. Good for controlled queues and long spacing.
• Rail chain signal: Sees to the next signal or exit. Locks out entries if the path isn't reserved all the way. Shows green/yellow/red/cyan (cyan = partial exit availability).
• Dual-track one-way: Simple, scalable, safe.
• Single-track bidirectional: Space-saver, but signal and passing-logic complexity explodes.
• Roundabout: Compact until load climbs. Then interior deadlock risks spike.
• The tiebreaker: Does a train stopping here jam others? If yes, use chain. If no, use normal.

The official 'Rail chain signal' and 'Tutorial: Train signals' articles say the same: chain signals are entry gatekeepers, not universal traffic managers.

For detailed specs and images, the official Factorio Wiki is your permanent reference, especially:

• Rail chain signal: https://wiki.factorio.com/Rail_chain_signal

Community layouts and advanced patterns will appear in related articles on this site as we expand coverage (watch for links to planned articles like train scheduling and advanced intersection blueprints).