Proxies for outbound traffic

Some external APIs (BILLmanager, VMmanager, mail servers) only let in allow-listed IPs, and some providers (Telegram or VK, for example) may be unreachable from the server's network. That's what proxy profiles are for: you pick a profile in a channel's settings, and the channel's outbound requests go through it instead of directly.

Two levels: platform and project

• Global profiles — set up by the platform admin in the platform admin panel, Proxies (under Platform). Every project sees them. The same page can mark a profile Enforced and manage Channel exceptions (see below).
• Project profiles — Settings → Proxies. Only this project sees them — handy when the company has its own VPN or exit node. Only the project owner can create and change them; platform profiles are listed here as Read-only. A project admin sees this page read-only and picks profiles in the channel cards.

Profile fields

• Protocol — HTTP, HTTPS or SOCKS5.
• Host, Port, Username and Password — username and password are optional. The password is stored encrypted and never shown back.
• Channel type — Any channel, BillManager, VMmanager, Email (IMAP/SMTP), Telegram or VK. A profile with a type is only offered to channels of that type, so you can't pick a proxy that exits from the wrong network by mistake.
• Active — an inactive profile can't be picked, and channels that already use it behave as if it weren't there.

A channel's proxy

You pick the proxy in the channel's card (Settings → Channels), in the Network and proxy block:

• Telegram — Proxy for the Telegram Bot API. The bot's requests go through it, including the ticket cards and notifications in the team's Telegram group.
• VK — Proxy for the VK API.
• Email — Proxy for outgoing IMAP/SMTP: both fetching mail over IMAP and sending over SMTP.
• BILLmanager over the API (v1) — two separate slots, see below.
• BILLmanager via the module (v2) — Proxy for outgoing requests on the General tab. Every call to the module goes through it: replies, the customer card, the module check, departments, closing and ticket statuses.

The widget and API have nothing to pick — they're inbound channels. WhatsApp has no proxy setting.

The list has No proxy (direct egress), the project's profiles and the platform's (marked 🌐). If the platform enforces a proxy for this channel type, No proxy is gone: the first item is “🔒 Enforced: …”, and only a project profile can replace it.

The IP to allow-list

Below the proxy picker, the channel card shows the IP the provider will see: the SupportHub server's public IP or, with a proxy selected, that proxy's exit IP. That's the IP to add to the allow-list of your BILLmanager or VMmanager panel or mail server firewall. A button next to it copies the IP.

Which proxy applies

For every outbound request SupportHub walks these steps and takes the first rule that fits:

1. Channel exception — if the platform admin put the channel on the Channel exceptions list, no enforced proxy applies to it: the channel uses the profile picked in it, or goes direct.
2. A project profile picked in the channel — applies even when an enforced proxy exists.
3. The platform's enforced proxy for this channel type. If there are several, a profile with a specific type beats an Any channel one.
4. A platform profile picked in the channel — only when there's no enforced one.
5. No proxy — the request goes straight from the SupportHub server.

A picked profile is ignored if it's inactive, deleted or tied to another channel type.

Enforced mode

A global profile marked Enforced applies to every channel of its type in every project, even when the channel is set to No proxy. That's how you route all of the platform's Telegram traffic through one network, or keep VK channels off the direct IP.

• A project can replace the enforced proxy with its own profile, but can't turn it off.
• Only the platform admin can let a channel bypass the enforced proxy — in Channel exceptions: find the project and pick its channel.

BILLmanager: two separate slots

A BILLmanager channel connected over the API (v1) has two independent proxies: Proxy for outgoing requests on the General tab — for the BILLmanager API (proxy_id in the channel config) — and Proxy for the VMmanager API on the VMmanager tab (vmmanager.proxy_id). The billing panel and the virtualization panel often sit in different networks, so you can route them differently — say, BILLmanager direct and VMmanager through a VPN. Each slot has its own allow-list IP block.