Core concepts
FF1’s model is simple: open an entry port on a node and forward traffic to a target address. The following concepts revolve around that.
FF1 Master
Section titled “FF1 Master”The control-plane main service, providing the console, Admin API, and config-delivery scheduling. Node online status, resources, and real-time throughput are pushed over WebSocket—no polling needed.
FF1 Core
Section titled “FF1 Core”The data-plane forwarding engine, installed on each node: it receives and applies the forwarding config pushed by Master, performs forwarding, and reports heartbeats and traffic. It saturates the physical bandwidth without becoming a bottleneck.
A VPS or physical machine running FF1 Core—your “relay machine.” It can be auto-deployed and registered via one-click SSH installation, or joined after manually installing FF1 Core.
Forward rule
Section titled “Forward rule”A rule = entry port → target address:port. It supports same-position, same-number pass-through of port ranges and lists (like RouterOS)—for example, a mixed list like 50-60,80,90-200 configured in one shot, with entry and exit ports mapping one-to-one.
Tunnels and nesting (tunnel chaining)
Section titled “Tunnels and nesting (tunnel chaining)”Stringing multiple nodes into one forwarding chain (A→B→C) is “nesting.” The chain is linked level by level via upstream_tunnel_id; change any link in the chain and Master re-pushes config to every node on the chain, not just the entry.
Config delivery queue
Section titled “Config delivery queue”After you edit rules in the console, Master automatically reconciles and applies them through each node’s FF1 Core. Every change enters the delivery queue and can be tracked; when a node is offline the task is held and auto-re-pushed once it recovers.
Users and access tokens
Section titled “Users and access tokens”For multi-operator operations, you can create user accounts for different operators. For scripted operations, issue an API Token with least-privilege scopes (e.g. nodes:read, rules:write). See Admin API.
Rate limiting and real IP
Section titled “Rate limiting and real IP”- Rate limiting: based on tc HTB shaping (kernel-level), stable across both low and high speed tiers.
- Real-IP pass-through: optional PROXY protocol that passes the client’s real IP to the upstream, so logs/risk-control don’t lose the source IP.