diff --git a/wiki/Connections.md b/wiki/Connections.md
index b142c7c..c819fdb 100644
--- a/wiki/Connections.md
+++ b/wiki/Connections.md
@@ -54,10 +54,36 @@ address in the group box listens on unicast instead, and says so in the log.
 |---|---|---|
 | **ADIF message** | a plain ADIF record | each QSO logged |
 | **WSJT-X logged QSO** | the same ADIF wrapped in a WSJT-X datagram | each QSO logged |
+| **Relay the WSJT-X stream** | every datagram received, byte for byte | as it arrives |
 | **PstRotator frequency** | `<PST><FREQUENCY>` | frequency change |
 | **N1MM RadioInfo** | N1MM's RadioInfo XML | frequency or mode change |
 | **Custom message** | whatever you write | a trigger you pick |
 
+### Relay the WSJT-X stream
+
+WSJT-X, JTDX and MSHV each send to **one address**. Without a relay the choice
+is between OpsLog and JTAlert / GridTracker, not both.
+
+This row re-sends every datagram an inbound WSJT-X row receives, **byte for
+byte**, to another program — so OpsLog stops being the reason you cannot run the
+two together:
+
+```
+WSJT-X ──▶ OpsLog (inbound, 2237) ──relay──▶ GridTracker (2238)
+```
+
+Point it at the **other** program's port. Pointing it at one of OpsLog's own
+listening ports would feed the stream back into itself for ever; the relay
+refuses and says so in the log rather than flooding the network.
+
+Nothing is added to the datagrams — no origin header. Some relays in the field
+prepend one (`127.0.0.1:2237|`), which is exactly the kind of thing OpsLog has
+had to write code to survive on the receiving side; passing it on downstream
+would be repeating that mistake.
+
+> If every program involved can do **multicast**, prefer that: each one gets its
+> own copy and no relay is needed. See [[Digital Modes and GridTracker]].
+
 ### Which one for another logger?
 
 If a logger says it accepts "WSJT-X UDP", it wants the **WSJT-X logged QSO**
diff --git a/wiki/Digital-Modes-and-GridTracker.md b/wiki/Digital-Modes-and-GridTracker.md
index 61b9922..eee2fbe 100644
--- a/wiki/Digital-Modes-and-GridTracker.md
+++ b/wiki/Digital-Modes-and-GridTracker.md
@@ -135,15 +135,25 @@ untick *Multicast*.
 ## If you have to stay on unicast
 
 Sometimes you cannot use multicast — an old program, a locked-down network.
-Then **only one program may listen on the port**, and the others are fed by it:
+Then **only one program may listen on the port**, and the others are fed by it.
+
+**OpsLog can be the one that feeds them.** Add an outbound *Relay the WSJT-X
+stream* row (Settings → Connections) and it re-sends every datagram it receives,
+byte for byte, to wherever you point it:
 
 ```
-WSJT-X ──unicast 2237──▶ GridTracker ──forward──▶ OpsLog (another port)
+WSJT-X ──unicast 2237──▶ OpsLog ──relay──▶ GridTracker (2238)
 ```
 
-GridTracker can forward what it receives; point it at a **different** port, add
-a matching inbound row in OpsLog, and nothing competes. The one arrangement
-that never works reliably is two programs on one unicast port.
+Set GridTracker to listen on **2238** instead of 2237 and nothing competes for
+anything. Point the relay at the other program's port, never at one of OpsLog's
+own — that would feed the stream back into itself, and the relay refuses rather
+than let it.
+
+It works the other way round too, if you prefer GridTracker to own the port:
+GridTracker forwards to a **different** port and OpsLog takes an inbound row
+there. Either order is fine. The one arrangement that never works reliably is
+two programs on one unicast port.
 
 ---