Reverse proxy nodes

The tracker sets up the node over SSH on its own, moves domain A records to it through a Cloudflare API token and monitors whether the node responds. Owners and admins can see this section: open the admin panel (the icon in the top right corner) and select Reverse proxy nodes («Реверс-прокси ноды»). In older releases this item was called Proxy servers («Proxy-серверы»), and the tab was called Nodes («Узлы»).

Why you need reverse proxy nodes

A node is a separate VPS with a web server in front of the main tracker. It accepts an HTTP request and passes it to Micator. Campaigns, stream selection, click recording and statistics stay on the main server; you do not need a separate license or another tracker installation on the node.

With the current connection method, a request goes like this:

Visitor → Cloudflare → node → main Micator server → selected stream target.

Cloudflare accepts the visitor's HTTPS. Caddy, installed on the node, accepts HTTP on port 80 and forwards requests to the main tracker. That is why the Cloudflare HTTPS settings and the panel domain DNS from the section below are required: simply changing the A record without them can break redirects.

Nodes let you spread tracking domains across separate entry servers and have a standby if one of them fails. This is not a backup and not a second copy of the database: switching nodes does not fix a failure of the main server. The main server must still be reachable from the nodes.

Putting the node IP instead of the tracker IP in a tracking domain's record reduces direct exposure of the main server's address through that domain, but does not guarantee that the address stays hidden: it may be known from the panel domain or previous DNS records. Nodes also do not replace checks against the PL registry.

What you need

Node server:

• a public IPv4 address — IPv6 is not accepted;
• a system with apt and systemd, for example Debian or Ubuntu, with internet access to install packages;
• SSH login with the root user's password;
• inbound port 80 open.

Use a server without other sites: the tracker installs the Caddy web server on the node, overwrites the /etc/caddy/Caddyfile file and takes port 80.

Panel domain: the node forwards requests to it over HTTP, port 80. So the panel domain's A record must point directly to the tracker server's IP. If the panel domain is in Cloudflare, turn off proxying for this record — the “DNS only” mode.

Domains:

• added to the Domains section;
• the domain's zone is in Cloudflare;
• a Cloudflare token with access to the zone is added in the Cloudflare API block on this same page — see Working with Cloudflare;
• the zone's SSL mode in Cloudflare is Flexible: the node accepts only HTTP on port 80, see SSL mode in Cloudflare.

Adding a node

1. Click + Add node («+ Добавить ноду»), on a phone — the + button in the bottom right corner. The “New proxy node” («Новая прокси-нода») window opens.
2. Fill in the fields.
3. Click Add and set up («Добавить и настроить»).

The password is used once and is not saved. The tracker adds its own access key to the node and connects with it from then on, installs Caddy if it is not there yet, and turns on request forwarding to the tracker.

The node appears in the table with the “setting up…” («настройка…») status; the page refreshes the list automatically. Setup takes up to 3 minutes. After the “ready” («готова») status, wait about a minute, as the hint above the table says, and then route domains to the node.

You cannot change node parameters: delete the node and add it again.

Statuses and checks

The Checked («Проверена») column shows the time of the last successful check, automatic or manual. The IP column shows the SSH port only if it is not 22.

The check («проверить») button connects to the node over SSH with the saved key and checks that Caddy is running. On success, the time in the Checked column is updated, and a node with the “error” status goes back to “ready”. On failure the status does not change; a node with the “error” status gets the text “manual check: …” («ручная проверка: …») next to it.

Routing domains to a node

1. In the Route domains to a node («Направить домены на ноду») block, select the node in the “— node —” («— нода —») list. The list contains only nodes with the “ready” status.
2. Check the domains. The select all («выбрать все») button checks the whole list, clear («снять») removes the checks.
3. Click Route selected (N) («Направить выбранные (N)»).

For each domain, the tracker creates or updates an A record pointing to the node IP through Cloudflare, turns on proxying for it (orange cloud) and remembers the binding. You can spread domains in parts: some to one node, others to another. Routing to a different node replaces the binding.

Up to 500 domains are routed at a time. If more are checked, the panel shows “too many domains at once (maximum 500)” («слишком много доменов за раз (максимум 500)»).

The result is shown above the node table: “Routed 12 domain(s) to node 203.0.113.10. Make sure the domains are on the Cloudflare orange cloud.” («Направлено 12 домен(ов) на ноду 203.0.113.10. Убедитесь, что домены на оранжевом облаке Cloudflare.») If some domains failed, the second sentence is replaced by a list: “; failed 1: track.example.com (not found)” («; не удалось 1: track.example.com (not found)») — the domain and the reason in parentheses.

Checking

1. Find the domain in the Route domains to a node block: to its right there is a mark like → DE-1 (203.0.113.10).
2. Open the domain's zone in Cloudflare: the A record points to the node IP, the cloud is orange.
3. Open Domains («Домены») and wait for the “Ready” («Готов») status in the Status («Статус») column. After routing to a node, the previous result is reset and the domain check runs again.

After checking DNS, open the link of a separate test campaign through the assigned domain and make sure the redirect leads to the expected target and the click appears in the tracker. A running Caddy status by itself does not confirm the whole chain up to Micator. To test failover, use a test domain and two ready nodes; do not turn off a node carrying live traffic to test it.

If a node is unavailable

Every 30 seconds, the tracker sends an HTTP request to port 80, path /health, of nodes with the “ready” status. This is an HTTP check, not an ICMP ping. If the connection cannot be established or the request ends with a transport error three checks in a row, the tracker moves the bound domains through Cloudflare to another responding node of the same workspace. The timeout of one request is 6 seconds; with several nodes the checks run one after another, so detection may take more than a minute and a half.

Any HTTP status received, including 502, currently means that the node itself responds. An error on the main tracker does not trigger a node switch. The check runs from the Micator server: it does not prove that the node is reachable from every country or network your visitors come from. The standby is chosen from ready nodes that responded in the current pass; this is not load balancing and not a choice of the nearest server.

• All domains moved — the node gets the “error” status with the text “unavailable — domains moved to 203.0.113.20” («недоступна — домены перенесены на 203.0.113.20»).
• Some domains moved — the node stays “ready”, and moving the rest is retried.
• No other responding nodes — the domains stay on the same node.

Switching depends on Cloudflare's response and on the DNS change taking effect. A minute and a half is a guide for detecting a failure, not a promise that every request recovers within that time. Clicks that did not reach the main tracker are not stored by the node for later delivery.

Move entries appear in Logs → System log. Domains do not move back on their own. A node with the “error” status is not checked automatically: when it is reachable again, click check. On success the status goes back to “ready”, and you can route domains to the node again.

Deleting a node

1. Route the node's domains to another node or change their A records in Cloudflare manually.
2. In the node row, click delete («удалить»).
3. Confirm the question “Delete node ‘DE-1’ (203.0.113.10)? Domains pointing to it will stop working until you switch the A record.” («Удалить ноду «DE-1» (203.0.113.10)? Домены, указывающие на неё, перестанут работать, пока не переключите A-запись.»)

The tracker removes the binding of domains to the node but does not change DNS records in Cloudflare. The software and the access key on the VPS itself remain.

To move a domain back from a node to the tracker server, put the tracker server's IP in its A record in Cloudflare. The domain's binding to the node in the tracker stays until the node is deleted: if the node fails, the tracker will again move the domain's A record to another node.

If something went wrong

ip must be the node's IPv4 address («ip должен быть IPv4-адресом ноды»)

The Server IP field contains something other than an IPv4 address. The message appears above the node table, and the add window stays open. Enter an address like 203.0.113.10. If the SSH password field is empty, the message is “ip and ssh_password are required” («ip и ssh_password обязательны»).

“Error” status right after adding

Node setup failed. The beginning of the text next to the status shows the stage:

• ssh connect — the tracker did not connect over SSH. Check the IP, SSH port, SSH login, SSH password and that the server allows password login;
• bootstrap — the connection worked, but the installation on the node ended with an error; the text continues with the last lines of its output. Check that the server has apt and systemd, has internet access, and that you log in as root.

Fix the cause, delete the node and add it again.

node is not provisioned yet («нода ещё не провижена»)

The check button was clicked for a node whose setup is still in progress or has failed. Wait for the “ready” status. If a node's setup ended with the “error” status, delete it and add it again.

failed 1: track.example.com (not found) («не удалось 1: track.example.com (not found)»)

The tracker did not find the domain's zone with any of the added Cloudflare tokens, or there are no tokens. Add a token with access to this domain's zone and route the domain again. Other reasons in parentheses are covered on the Working with Cloudflare page.

The domain is routed to a node, but its status in Domains is “Needs attention” («Требует внимания»)

Check the requirements: the node has the “ready” status and port 80 open, the zone's SSL mode is Flexible, and the panel domain's A record points directly to the tracker server's IP. Then click ⟳ in the domain row. Stage messages are covered on the Domain check page.