Mastering Factorio Train Signals and Network Building

When I first built a four-way intersection in Factorio, the first train ran fine, but the moment a second arrived, it stopped dead in the middle and the whole network jammed. The moment I switched the entrance to use chain signals instead, the flow improved dramatically—that's when I really understood that standard signals and chain signals have completely different roles.

This article is written for beginners to intermediate players in Factorio vanilla 1.1–2.0 who are just starting to build train networks. It clarifies stop positions and reservation ranges to help you properly distinguish when to use each signal type, then walks you through building intersections and stations that don't jam. The core principle—dual-track one-way for the main line, chain signals at intersection entrances and standard signals at exits, plus a waiting queue outside the main line—dramatically reduces typical deadlocks. Along the way, I'll also cover how chain signal subdivision inside intersections works in practical terms, accounting for how 2.0 operations sometimes differ from older guides.

Target version and terminology baseline for this article

This article covers Factorio vanilla 1.1–2.0 train signals. The basic specs of standard rail signals and rail chain signals remain consistent across this range, and the core rules that beginners need to learn first—"chain signals at entrances, standard signals at exits" and "trains are managed as blocks"—don't change. The official Wiki's 'Tutorial: Train signals' also builds its explanations around these fundamentals.

I'll standardize terminology to match the official Wiki: standard rail signal (Rail signal), rail chain signal (Rail chain signal), block, path reservation, intersection, and stacker (waiting queue). We might sometimes abbreviate as "chain signal" or "standard signal," but these refer to the formal names. Keeping terminology consistent makes it much clearer to discuss "where to stop" and "how much space needs to open before entry"—these details become hard to follow if terms shift mid-explanation.

A critical premise to keep in mind: trains only read signals on the right side of their travel direction. With dual-track one-way, this is natural—you just align signals on the right. But for bidirectional single-rail, you need matching signals on both sides so trains in both directions can read them. This catches beginners off guard: you place a signal, but the train heading the other way can't see it, so it just sits there. This was a major source of confusion early on for me too. The issue isn't signal performance—it's that the train must be facing the signal to read it in the first place.

On version differences, one thing worth mentioning is how intersection interiors are subdivided. The core logic is the same in 1.1, but older guides often show intersections with minimal internal division. Conversely, in 2.0 the community has reported that using chain signals to finely partition intersection interiors is becoming more common, and players increasingly find it easier to operate that way. This reflects practical community experience, not an official spec change—I'll treat it as one useful option for 2.0 environments while keeping the fundamentals intact.

One more thing that catches intermediate players: when you place or remove signals and rails, all trains re-run pathfinding at once. This is documented under 'Railway/Train path finding', and while usually convenient, it has real presence on large networks. I once adjusted a bunch of main-line signals at once and watched every train slow down in unison—it was nerve-racking, even though nothing was actually broken. Large save files feel this impact more. So batch modifications during light traffic hours becomes quietly important practice.

From this point on, I'll explain based on 1.1–2.0 shared principles while also covering how 2.0's intersection-interior chain subdivision simplifies things in practice. Locking terminology in now makes the ripple effects—block cuts, how path reservation appears, where to put stackers—all click together.

Rail signal fundamentals in Factorio: blocks and direction

Blocks = the smallest safe zone

To really grasp Factorio train signals, the first insight to cement is "signals divide track into blocks." A block is like a safe zone for trains—fundamentally, only one train can occupy one block. This is the foundation of collision prevention. If you only watch signal colors, it feels confusing, but what's really happening is simple: trains are asking, "is that section of track ahead clear?"

When you place standard signals at even intervals along a straight line, each one creates a new block boundary. The moment the front train leaves that block, the train behind can enter it. So instead of thinking of one long stretch of track, it's better to picture a series of finely divided safe compartments. Understanding this helped me—signal placement stopped looking like "memorizing symbols" and became "organizing zones" instead.

Confusion at branches and merges often comes from not tracking how blocks connect in your head. If two branches converge into the same block despite appearing separate, trains can't use them simultaneously. But with proper block division via signals, non-conflicting paths remain independent. The intersection rule—chain signals at entrance, standard signals at exit—ultimately serves one purpose: let trains through the dangerous intersection zone without stopping, only when they can fit safely into the block beyond. It's zone management.

Figure A would jump-start understanding here: seeing a right-hand traffic track with trains reading only the signal on their right side makes it click visually—"oh, signals aren't decoration, they're directed gateways."

Right-hand traffic and bidirectional-track signal placement

One more critical signal rule: trains only read signals on the right side relative to their heading. A signal on the left is invisible to a train approaching from that direction. Dual-track one-way earns the "beginner-friendly" label partly because of this—fixed directions mean signals naturally align on the same side.

For a right-hand traffic pair, place signals on the right of both tracks and you're done. But a single track used bidirectionally flips the equation. If the same rail needs to carry traffic both ways, you must place corresponding signals on both sides so each direction's trains can read them. Miss this and you get a train facing a signal it can't use, stuck saying "no path forward" while the track sits empty. I hit this early: I'd set up rails but only one side of signals, then watched a train sit motionless. The rails were connected, so I blamed schedules and fuel before the truth hit—the train's side had no signal to read.

This trait echoes through single-track passing sidings and branches too. Bidirectional rail isn't impossible, but forgotten signals become impassable or deadlock instantly, making it accident-prone for the inexperienced. The official 'Tutorial: Train signals' assumes parallel directional tracks are easier than bidirectional single-rail. As train counts rise, this "right-side only" rule ripples through the whole design philosophy.

Tutorial:Train signals/ja

wiki.factorio.com

Self-diagnosis using block visualization

When signals puzzle you, the quickest fix is enabling block visualization. Seeing color-coded track reveals far more than text explanation. You instantly see how many blocks your straight sections, branches, merges, and intersections split into—and "why does everything jam here?" becomes obvious. Figure B's color-coded example shows one block, one train crystallized visually, which really helps beginners.

The diagnostic approach is straightforward: first, check if a block boundary sits just before your intended stop position. Next, make sure branches and merges aren't pooled into a single giant block. An intersection painted one color means only one train can use it—ever. Finely subdivided means competing paths can coexist. Older guides assume minimal interior splits, but in 2.0, interior chain-signal subdivision often feels more workable, and that's honestly how I run things operationally.

The easiest pattern to spot is "looks like separate routes but same color." That signals insufficient subdivision—the same block eating both branches. When one train forced to wait blocks unrelated directions, that's usually the culprit. Conversely, if exit blocks are too short for your longest train, the rear sticks inside the intersection. Color-coded view exposes both at a glance.

Signal design shifts from "circuit symbol memorization" to "color-zone layout" when you see it this way. Once it clicks, branch and merge decisions turn into "what block should be independent?" with signal placement naturally following.

Standard vs. chain signals: what they actually do

Standard signal behavior and placement rule

A standard rail signal is delightfully simple. It checks if the block directly ahead is clear—nothing beyond matters. Ahead is empty? Go. Ahead is full? Stop. That clarity means standard signals work great where trains can wait for long periods without issue.

Classic spots: spaced intervals along a main line, or interior lanes inside a waiting queue before a station. Trains stopping there aren't blocking intersections or dragging other directions down. Standard signals gapped across a line actually boost throughput—when one train inches forward, followers can creep up too, densifying the corridor.

When I was learning, I treated all signals the same. But all-standard signal intersection entry was the recipe for disaster: the train enters the intersection, the road ahead is blocked, and it stops trapped inside. Standard signals only look one block forward, so from their perspective they're working correctly. Once I realized standard signals were designed to create safe waiting zones, not to manage intersections, the role split became obvious.

Figure C shows this "stop position" vs. "look-ahead range" distinction clearly. Standard signals nail fixed stop positions because they judge one block at a time.

Chain signal behavior and four states

Chain signals are far more cautious. Instead of peeking one block ahead, they check the next signal or the path all the way to the exit. Beyond just checking if it's empty, they verify the path can be reserved—meaning entry only happens when the train won't get stuck after entering.

You need this caution at intersections, branch entrances, single-track entry points—anywhere a stopped train would cause broader gridlock. The official 'Rail chain signal' docs and English Wiki both frame this signal around exit-aware pathfinding.

Chain signals display four states—versus standard's three:

That blue state is why chain signals confuse so many people. Blue doesn't mean "all clear." It means some directions work, others are blocked depending on the train's destination. A four-way intersection entrance flashing blue might mean "you can turn right, but left and straight are both plugged." I used to gloss over blue early on—figured blue meant go—but per-train destination routing changes the picture entirely. This detail matters a lot.

One subtle chain signal behavior: auto-trains pause before a red chain signal for a bit before re-routing. Community reports suggest roughly 5 seconds, though no official docs specify the exact figure (see 'Railway/Train_path_finding'). I'll err cautious in the main text: "after waiting a period, the train recalculates (community consensus around 5 seconds)" to flag the source difference.

The comparison in Table 1 matches real operational feel:

Rail chain signal - Factorio Wiki

wiki.factorio.com

Where to wait, where to never stop

If you're second-guessing placement, the logic is cleanly binary: standard signals where long waits are OK; chain signals where stops cause cascading jams. This one rule cuts accident rates dramatically.

Say you build a stacker (waiting queue) before a station. The internal lanes use standard signals—trains queuing is literally the point. Conversely, intersection entrances, rotaries, and single-track access: chain signals go there because a stopped train there ripples backward through everything. The mindset flips from "hold at this spot" to "only send trains that can clear the zone."

Early me thought "more lanes = better stacks," but overloading a queue with chain signals backfires: trains get anxious predicting availability and cram less densely, paradoxically leaving the stacker looking sparse while the main line backs up. Fixing it meant swapping stacker internals back to standard signals while moving chain signals to intersection and single-track entrances alone—suddenly it organized itself.

The official tutorial's deadlock-fix example is famous: swap intersection entrance to chain signals. Same logic. Intersections are pass-through zones, not parking lots. Signal type is really about reservation strategy and stopping philosophy, not colors.

Non-jamming intersection signal placement: chains at entry, standard at exit

T-junctions: minimal, stable config

T-junctions seem simple and actually demonstrate the basic rules most directly. The whole trick: chain signals guard entry, standard signals mark safe exit points. This forces trains to ask "can I fully exit?" before committing, killing mid-intersection stalls.

Concretely: place chain signals on each inbound branch, then standard signals at the start of safe zones beyond the intersection. A sneaky detail: don't cluster the exit signal too close. The gap between intersection exit and next signal must fit your longest train—otherwise the rear hangs in the intersection while the nose pokes out, creating the infamous "tail stall." Trains jamming up because the back half is still trapped is a full network freeze.

I learned this the hard way: ran 4-8 car trains and crammed the exit close. A rightbound train's tail stayed in the T-zone, blocking oncoming and left-branch traffic completely. The signals were correct—the gap wasn't. Suddenly spacing that distance fixed the same layout's jam patterns entirely.

The official 'Tutorial: Train signals' consistently shows intersection entry swapped to chain signals to prevent mid-zone stops. T-junctions are the training-wheels version, and Figure D's minimal build is very reproducible. Just three rules—chain at entry, standard at exit, plus one train-length gap after exit—stabilizes most cases.

Four-way: internal block setup for parallel flow

Scaling a four-way to move more trains requires subdividing the intersection interior with chain signals. Goal: not one-at-a-time throughput, but parallel paths that don't collide.

North→South and East→West cross, so no simultaneous routing there. But North→East and South→West turn profiles don't collide with each other—and if you split interior blocks smartly, both can flow at once. A single central block means even non-crashing routes lock each other out. Subdividing forces each chain-signal entry to claim only the path it needs, leaving other lanes free.

Community examples show four-way intersections capable of 4 simultaneous trains through design like this. Not always flowing four at once, but shifting from "only one direction moves at a time" to "non-conflicting directions flow together" is a night-and-day practical difference. As train volume climbs, this compounds.

The pitfall: chain-signal overkill. Finer subdivision helps, but sprawling reservation zones make trains overly cautious—green signals and empty space ahead, yet trains halt two blocks out. I once wired a "clever" four-way with chain signals dense from far back through the center. The result: trains dawdled and the middle sat empty while the approach clogged. Partition grain-size should match intersection size and traffic. Small four-way? Partition just the center. Massive intersection? Then fine cuts help, but you don't need chain signals everywhere.

Figure E sketches it simply: entry chains for decision-making, interior split on conflict points, exit standards for receiving. Turns the intersection from "wait zone" into "express lanes."

Branches, merges, single-track entry

Branches and merges seem less dramatic than four-ways but are jam fountains in real play. Why? Path selection and merge conflicts happen in the same area. Same toolkit applies: chain signals protect branch/merge entry, standard signals finish the journey beyond.

For branches, a blocked exit branch should prevent entry altogether. That blue signal appears precisely here—one exit open, the other stuffed. Chain signals let per-train destinations decide: "your target is clear, proceed; yours is blocked, hold." Standard-only branches let trains halfway through before getting stuck, tainting the feeder main line.

For merges, never treat the merge point as a waiting zone. One train parked in the merge waiting for outbound space freezes the other merge arm and everything behind it. Chain signals at pre-merge, standard post-merge, ensure only clearing-capable trains enter. Figure F's understated layout is stable despite simplicity.

Single-track feeding works the same. Single rails jam easy with one opponent, so chain-signal entry gates, checking both single-track passage and exit clearance. Bidirectional single-track examples run heavy chain-signal counts, but the core is preventing head-ons and crossings at the entry gate. Deciding mid-zone courts catastrophe.

Big factories eventually depend less on flashy intersections and more on these branch/merge runs. Because they look straightforward, they often get deferred—then become the actual throughput bottleneck. Great intersections mean nothing if their feeders are standard-signal junkyards. These unglamorous zones are where the basic rule shines: chain entry, standard exit.

Station connections and main-line ties: stackers (waiting queues) kill station-front backups

Stacker building blocks

Running multiple trains into the same station group demands keeping the main line uninvolved in arrival waits. Stackers are the solution: gather trains in one zone, let them queue, feed into stations as they empty. Early factory-building, I'd see a station fill up, the next train stall on the main line, and then the whole main line and intersection back up into paralysis. A small stacker in between? Trains lined up out of the main line's way. Night-and-day difference.

The shape is straightforward: main line splits into a stacker, internal parallel lanes accumulate trains, and a merge feeds empty station slots in order. Shared by two mining stations? One joint wait-zone, as 'Tutorial:Train signals/ja' shows. Figure G resembles a parking lot before a building—entry funnel, fanned lane distribution, exit flow toward service.

The real work: understand waiting belongs in stacker lanes, not main line or stations. Stations stay occupied with cargo ops; main lines stay flowing. Stackers absorb and release. Blur these and you're building a gridlock amplifier instead of a buffer.

Sketch the design by first answering "where should trains queue?" separately from "where should trains flow?" If line-management roles collapse, real networks jam instantly despite graphically connected rails.

Why entry chains, interior standards

Stacker signal placement trips people up. The answer is clean: stacker entry uses chains; interior lanes use standard signals.

Chains at entry judge "can you proceed into the queue and toward your assigned station?" If lanes are full or stations blocked downstream, don't even let the fork-in happen. Without chain entry, trains half-merge and jam, and now your wait zone's head is blocking the main feeder. Chains make stacker entry a single "intake permission gate."

But chain signals throughout the stacker would feel smarter and usually backfire. Stacker job is neat line-up and holding, not reservation presaging. Standard signals let trains comfortably stack for long periods—that's their purpose. Deploying chains in wait zones spreads reservation overhead and ironically cracks flow. I once tried all-chain stackers thinking "smarter = better." The result: trains neurotic about distant availability, slower intake, paradoxically less dense queuing.

The lesson scales to pre-station placement. Long-wait zones get standard; entry gates deciding admission get chain. Trains then make a clear choice at the gate and relax in queue. Chains are for forking and contested merges—not for parking.

Estimating capacity and train lengths

A "feel-based, maybe 2-3 lanes" stacker dies the moment train fleet grows. The metric: inbound train count targeting this station group. As baseline: how many trains visit this station set at peak? That count, plus safety margin. The margin absorbs arrival timing scatter and simultaneous arrivals.

Example: two mining stations, shared stacker. Count real inbound trains—not "2 stations therefore 2 lanes." One's unloading, one's entering, two more arrive simultaneously—real scenario needs 3–4 lanes. I once tried "two stations = two lane-way" and created the worst failure mode: normally fine, but demand spikes overflow the main line, blocking everyone. Boom, network-wide stall at peak.

Length is do-or-die. Each lane must fit your longest train complete—locomotive through caboose. If the rear pokes into the fork or main line, you've built a "main-line blocker," not a queue. That's where station-front mess lives.

The recipe: decide inbound train count, provision lanes for that count, stretch each lane to longest-train length. Fewer, proper-length lanes beats more cramped lanes. Shared stations multiply the stacker size slightly but save the main line. Large factories feel that difference compounding—intersection flash counts for less than station-entry lane health.

Common pitfalls and deadlock fixes

Four classic deadlock patterns

This is where beginners crash hardest. Cruelly, solo train runs fine, but train two or three arrives and everything seizes. "But it worked!" is the cry. I burned hours on this loop early.

First: building intersections with standard signals only. Looks complete, feels finished, but trains enter and stall inside. Then northbound blocks eastbound, eastbound blocks southbound, southbound blocks westbound—mutual waiting, full lockup. The official 'Tutorial: Train signals' fixes precisely this by swapping entry to chain signals. Intersections are "pass, don't think here"; chains force that.

Second: exit blocks too short. Signal types might be perfect, but if longest trains can't fully escape before next stop, the rear wedges inside. Then everything downstream clogs. Short doesn't look broken—headlights clear, tails visible—but you've blocked the zone from behind.

Third: tiny roundabouts in dense operation. Roundabouts look appealing—space-saving, direction-flexible. Early me loved them. But small diameter plus heavy traffic = trains filling the loop, each waiting for the next exit, each blocking those behind—a locked wheel of jam around the perimeter. Small roundabouts plateau hard once train density rises. I've rebuilt them as T-junctions and suddenly flow returned.

Fourth: single-track bidirectional without passing siding planning. Single rails jam easily—one oncoming train stalls both directions. No sidings? Trains meet mid-line and deadlock: neither can back up, recalculation finds no alternate. The infrastructure itself is clogged, not the schedule.

Bonus trap: mixed-direction blocks. One rail direction forward, another backward in the same zone creates cautious approach-and-retry, which chains everything. Unified track direction per rail prevents this.

Tutorial:Train signals

wiki.factorio.com

Diagnosing: which block has mutual waiting?

Instinct says "add more signals." I did that early—made things worse. Deadlock diagnosis leans on spotting which block traps trains and which paths that stall blocks.

Standard-signal intersection jams show trains stopped inside the intersection, overlapping hazardous cross-paths. Swap entry to chain. Public fix examples do exactly that. Entrance-gate rethink, not more middle signals.

Stalled exit blocks show train nose beyond the zone, tail inside it. Diagnosis: next block after exit too short. Stretch it to full-train length. That single fix often solves the picture.

Roundabout deadlock puts multiple trains in the loop itself, each paused, each blocking outbound paths. Cause: loop too small for volume. Make it bigger or switch to linear intersections. Chaininess won't save a structurally inadequate loop.

Single-track bidirectional sees trains at zone ends facing each other, neither able to proceed, or one backed up on main because sidings were absent. The infrastructure lacks passing space. Build sidings or convert to dual-track one-way.

Mixed-direction blocks spawn trains sometimes moving, sometimes stalling mysteriously. Root cause: one direction forward, another backward in the same real-estate creates mutual confusion. Separate the block directions.

The community 'Train Network/Layout Examples' shows successful networks where stop positions have clear roles. Failed networks park trains where stops would break flow. Diagnosis question: "is this block a stop or a transit?" If transit, remove the stop permission. If stop, shift it outside the critical zone.

Train Network/Layout Examples - Factorio JP Wiki

wikiwiki.jp

Recovery steps: temp signals, manual moves, permanent fix

A full gridlock needs staged unclogging. Complex-seeming, but cycle-breaking is simple.

1. Temp signals block new entry

Block new arrivals into problem zones. Intersection entrance, single-track start—kill the green light. This stops the deadlock from expanding while you clear the inside.

1. Manually push one train at a time to safety

Drag stuck trains to safe blocks beyond—intersection exits, passing sidings, roundabout perimeter. Clearing one can unlock all. Resist batching moves; watch clearance between each nudge to avoid creating a second jam elsewhere.

1. Redesign stop positions

Once breathing room exists, permanent fix. All-standard intersection? Swap entry to chain, subdivide interior, confirm exit length. Short-exit issue? Extend the exit block. Stalled roundabout? Expand diameter or rebuild as linear intersection. Single-track bidirectional? Add passing sidings, or convert to dual one-way. Gate entries with chain signals and enforce direction consistency.

1. Unify direction rules

Permanent fix also means coherent design. Dual-track = one direction each. Single-track = bidirectional with sidings. Eliminate mixed directions in the same zone.

This staged approach—hold the line, clear the mess, rebuild right—prevents reactive jam-whack-a-mole. I found that every manual rescue of a train from an intersection signals a stop-position design error, not an accident. Fixing the design prevents recurrence at higher train counts.

Expansion principles for growing networks

Dual-track one-way standardization

As your network grows, pin down dual-track one-way as the baseline. Fix direction per pair, let trains read their right-side signals, and consistency ripples everywhere. Feels like a limit early on—"bidirectional saves rail!"—but it's untrue. Mixing directions later becomes exponentially messier. Branching and stations pile on, and suddenly half your signals are redundant or confused.

Strength: rule apply at intersections, branches, and stations alike. Where to enter, where to exit, where to queue becomes obvious. Cross-play friendliness soars—other players extending track can't accidentally bidirectional-ize and corrupt the design.

Bidirectional single-track squeezes rail but demands passing sidings, dual-side signals, and passing logic. Scaling that becomes heavy. Mainstream use is support lines and temps, not trunk routes.

This thinking extends to logistics philosophy. Big trains solve problems belts and drones can't—distance and bulk. That use case screams for simple, clear control. Dual one-way front-loads simplicity, and as fleet size and bases grow, simplicity compounds. Tracks can keep expanding; rules stay the same.

"Minimal chain signals" principle

Chain signals are useful but overbuild them and throughput paradoxically crashes. Worth repeating: chain signals forecast ahead and reserve, so over-reservation locks trains against each other even when there's room. I've watched trains anxiously stall in a wide-open corridor because every exit two blocks past was chain-predicted as full.

Place chains at intersection entries, branch entries, single-track entries—decision points where "should I proceed?" matters. Ditch them afterward. Long straights, exit-following waits—standard signals ease flow better. Own experience: trimming a branch's unnecessary chains while rebuilding an intersection caused visible speedup. The traffic volume didn't change; the reservation anxiety did.

Public tutorials and the 'Railway' article hold the same principle: caution is surgical, not wallpaper. Chains are "don't enter unless exit is certain"; not "govern every block."

2.0 does add texture: interior chain subdivision for parallel-path throughput. But that's refinement within the principle—still aimed at "don't stop mid-intersection." Exterior sprawl still backfires.

Change-management for big networks

A trap the large save overlooks: touching signals or rail anywhere triggers global train pathfinding recalculation. One intersection change and every train reroutes mid-journey. Small bases don't care. Busy networks feel seismic shifts—stopped trains, unexpected reroutes, cascades.

Risky: remaking a congested main-intersection during peak traffic. Design looks right, but twenty trains recalculating simultaneously creates temporal chaos. Before a stalled import suddenly unclogs, something else blocked by rerouting. Diagnosis becomes impossible.

Safer: staged, off-peak modifications. Swap entrance signals one intersection at a time. Verify flow-change. Next quiet window, next site. Design stays same; symptoms appear one at a time, traceable.

Massive scaling in Space Age / 2.0 means this fractures more noticeably. Precision in change-management—staging, timing, verification—separates "elegant network" from "working network." Flashy intersection geometry matters less than "can I adjust this safely?"

Quick-start checklist

Theory lands best when you can act on it in an afternoon. I use this when triage-fixing sluggish routes: hits five key points, skips the exhausting rebuild. Solve stop-position roles at five trouble spots and the whole network's responsiveness shifts.

First, snap the main line to dual-track one-way everywhere—pick right-hand or left-hand globally. Mixing directions breeds invisible failures later. Once you've fixed baseline direction, intersection entries and exits naturally align.

Next, pick the single most congested intersection and flip it: entry chains, exit standards. Not all intersections at once. Surgical proof. Official deadlock examples show this single tweak recovering flow.

Then verify exit blocks fit full train lengths. Easy to miss, huge impact. A perfectly signaled intersection fails if the tail sticks in.

Fourth, add a stacker outside the main line before any multi-train station. Pub example: two-station shared waits with one outside queue. Eases

Terminology Quick Reference and Comparison Summary

This is a keeper section, condensed so you can take the design rules with you. When I work on train networks, rather than recalling every complex principle, I just confirm two things first: "what range does this signal look at before allowing passage?" and "where does this setup make trains wait?" Honestly, once those are clear, there's no confusion.

• Rail signal looks at the one block ahead before allowing passage. Best for long straight-line segments or locations where you specifically want trains to wait outside the main line.
• Rail chain signal looks at the path all the way to the next signal or exit before allowing passage. Used at intersection entrances, junction entries, and single-track entries -- anywhere you "don't want a train stopping inside." Display states are green, yellow, red, and blue, where blue means only some exit candidates are available.
• Double-track one-way is the easiest layout for beginners to adopt as a foundation. Traffic direction is easy to unify, and adding stations or intersections later rarely breaks the design.
• Single-track bidirectional saves on rails but signal design difficulty jumps dramatically. Without planning for passing sidings and entry management, deadlocks come quickly, and throughput ceiling is lower.
• Roundabout is compact and easy to build. However, as train density increases, internal waits cascade easily and it needs more headroom than it appears.
• When in doubt, the rule is "chain signals at intersections and single-track entries, rail signals at waiting locations and after exits." Rather than memorizing signal types, deciding based on whether it's okay for a train to stop here speeds up judgment.

To review this with diagrams, the official Wiki's "Rail chain signal/ja" and "Tutorial:Train signals/ja" pair well. I initially placed chain signals thinking of them as "high-performance rail signals" and failed, but understanding them as signals that prevent waiting made operations much more stable.