Skip to content

Config delivery queue

After you change a forward rule or tunnel in the console, the Master writes the desired state into the config delivery queue, which FF1 Core on each node applies. This is the real-time config push from Core concepts.

Workflow

Console saves change
  → Master computes desired config (split per node; multi-hop chains include every node in the chain)
  → Task enqueued
  → FF1 Core receives it over WebSocket and applies it
  → Reports result → status updated

Reading the queue

Field	Meaning
Target node	Which node
Change	Added / updated / deleted forward rule or tunnel
Status	`pending` / `running` / `success` / `failed`
Time	Enqueued, started, completed
Error	Reason the change failed to apply

Offline replay

When a node is disconnected, new tasks stay pending and are not lost; once FF1 Core reconnects, the Master automatically pushes the backlog. No manual sync is needed. If tasks keep failed, first check the FF1 Core service and network on the node.

Multi-hop chains

When you change a tunnel (chained) path, the queue generates a separate delivery task for every node in the chain, ensuring the whole chain is consistent rather than updating only the ingress. See Tunnels & tunnel chaining.

FAQ

Q: Tasks stuck at pending? A: The target node is offline or FF1 Core is not running; check the node’s service status.

Q: Shows success but forwarding doesn’t work? A: Delivery only guarantees the config is applied; also check the node firewall, whether the ingress port is open, and whether the upstream is reachable.