Outbound requests
The Outbound requests tab of the Cài đặt Qubix window, in the Protection group. Here you choose how the server's requests reach the internet: directly from the server's address, through your SOCKS proxy or through Tor. With a proxy or Tor, the services the server contacts see the address of the proxy or of a Tor exit instead of the server's own address.
This tab is shown to an administrator only.
Ways out
The How the server reaches the internet field offers three ways:
- Directly, from the server's address — the server goes out from its own address. This is how a server works until an administrator chooses another way.
- Through your SOCKS proxy — requests go through a SOCKS5 proxy whose address you enter.
- Through Tor — requests go through the Tor network. Tor runs in a container of its own on the server: the server raises it when you choose Tor and removes it when you choose another way.
Not every request takes the chosen way: Facebook, Cloudflare, Namecheap, the license server and a few other kinds of requests go past it — the full list is in What goes past the chosen way.
If the chosen proxy or Tor stops answering, the requests that go this way are refused: the server does not fall back to its own address. As soon as the way answers, requests go out again; a request refused in the meantime is not resent by the way itself. What goes past the way keeps working all along.
How to switch to your proxy
- Open Cài đặt Qubix → Outbound requests.
- In the How the server reaches the internet field, choose Through your SOCKS proxy. The SOCKS proxy address field appears.
- Enter the proxy address:
socks5://host:port, orsocks5://login:password@host:portif the proxy asks for a login. Thesocks5h://scheme is accepted as well, and an address without a scheme is read assocks5://. - Click Lưu. Before saving, the server sends a request through the proxy to find out which address the outside world sees. If the address is not a SOCKS5 one or the proxy does not answer, nothing is saved, and the reason is shown next to the button: a proxy that does not answer would stop every request that goes this way.
Under the field description the saved proxy is shown — its host and port and, if it has a login, the words "with a login"; the login and password themselves are not shown. The saved address stays when you switch to another way. To go back to it, choose Through your SOCKS proxy again and save with the field left empty: the server checks the saved proxy and uses it. Enter an address only to replace the saved one.
In this mode the server looks up the names of its requests itself, through its usual DNS server, makes sure the address is not one of an internal network and hands the proxy the checked address rather than the name — with either of the two schemes. That is why a proxy in your own network cannot be used to reach into that network.
How to switch to Tor
- Open Cài đặt Qubix → Outbound requests.
- In the How the server reaches the internet field, choose Through Tor.
- Click Lưu. Unlike a proxy, Tor is saved without a check: the way takes effect at once, and the server downloads the Tor image and raises the container in the background.
- Click Check in the Way out group and wait until it shows the address the outside world sees. Until the container is up, the requests that go this way are refused.
The Way out group shows the state of the Tor container; it is read when the tab opens and with every check:
- The Tor container is running.
- There is no Tor container yet: it is raised once Tor is chosen.
- The Tor container is stopped.
- The server cannot reach Docker, so the Tor container cannot be checked.
While Tor is chosen, the server checks the container every five minutes and raises it again if it has disappeared or stopped. Each time the server starts — after a Qubix update, for example — the container is brought to the Tor version that the installed release carries.
Checking the way out
When a proxy or Tor is saved, the Way out group appears under the choice of the way. While the server goes out directly, there is nothing to check, and the group is not shown.
Click Check: the server sends a request through the way in force and shows the answer:
- "The outside world sees the address …" — the way works, and this is the address seen by the services the server contacts. When the address belongs to a Tor exit, the line says so as well: the server learns this from the Tor Project's own check. If that check does not answer and another address service does, the line comes without this mark — even in the Tor mode.
- A line saying that the way out does not answer, with the details below it. Only the requests that go this way stop: they are refused until the way answers, and what goes past the way keeps working.
What goes past the chosen way
These requests do not take the way chosen on the tab, whichever it is:
- Facebook. Requests to Facebook go, as before, through the browser profile's own proxy, or directly when the profile has none. Conversions sent to Facebook (Conversions API), the pixel check, the check of a profile's proxy and the downloading of ad pictures and videos go directly.
- Cloudflare and Namecheap — directly: their keys are tied to the server's address. Checking a domain through the Cloudflare network goes directly too, and so does finding out the server's own address: through Tor, the server would learn the address of a Tor exit instead of its own.
- Our license server — directly: the license check and what the server downloads from it, such as updates of the geo and cloak databases.
- The port check and the DNS checks of domains — directly, by their very purpose: a port check has to come from the server's own address, and a SOCKS proxy does not carry DNS queries.
- A request with its own proxy. A
fetchcall that names its own proxy — theproxyfield ofctx.fetchin scripts — goes to that proxy directly from the server; see Writing a script. - Hosts of your internal network:
- a
fetchrequest of a script, a Britva rule or a site page handler to an internal-network address that the Danh sách host cho phép allows goes directly. Through your proxy or Tor,fetchcannot reach an internal host given by name — give it by its address; - postbacks to hosts of the Internal networks for proxies, mail and postbacks list (Services and jobs) go directly;
- script databases on an internal network from the Database hosts for scripts list are connected directly (Your own databases).
- a
- The check for a new Qubix version — directly: the server asks the Qubix image registry whether a new version is out.
- Qubix's other containers go out on their own, directly: the assistant on a Claude subscription and the certificate container, which gets Let's Encrypt certificates for domains.
- Docker downloads container images by itself, directly from the server's address: Qubix updates, the Tor image (at every start of the server and every save of this tab while Tor is chosen) and the images of the server's other components, such as the on-box models.
- Name lookups (DNS). In the SOCKS proxy mode, the server looks up the names of its requests itself (see above). In the Tor mode, the names of the requests that go through Tor are looked up by Tor, but the DNS server that the Qubix server uses still sees the names of the requests that go past the way directly, the names of the domain DNS checks, the names the server checks before a request — the hosts of script databases, for example — and the names of postbacks when the Internal networks for proxies, mail and postbacks list is not empty.
Connections without encryption
Through a proxy or Tor, whoever carries a connection can read and change it unless it is encrypted. An http:// address in a script's request or in a postback travels open as far as the proxy or the Tor exit — prefer https:// addresses where you can. A Tor exit is somebody else's server: that is why a script's database on the internet is connected through Tor only when the connection checks the database server — the settings are in Your own databases.