How the static IP proxy works

The proxy URL

Everything starts from one URL. Your HTTP client uses it as its proxy.

https://APP_ID:TOKEN@mum.egress.fixedmark.com:443
socks5h://APP_ID:TOKEN@mum.egress.fixedmark.com:1080

IP pairs and high availability

Each region runs at least two proxy nodes. Your app gets a pair of static IPv4 addresses, one primary on each node. The region's host name resolves to healthy nodes only. Each new connection leaves from one IP in the pair.

When a node fails, the other node takes over its IP. When Fixedmark replaces a node, the IP moves to the new node. Addresses are tracked separately from servers, so a server change never means a new IP for you.

• Allowlist both IPs. Requests are spread across the pair, and failover can move traffic to either address. An allowlist with one IP fails part of the time, which is hard to debug.
• Expect resets during failover. Connections that were open on a failed node drop. New connections succeed once the IP moves. Clients with retries and connection pools recover on their own.
• Broker slots map to the pair. Brokers that ask for a primary and a secondary IP get one address each. See static IP for algo trading.

Shared and dedicated pairs

The Free and Starter plans use a shared IP pair. Other Fixedmark customers in the same region send traffic from the same addresses. Pro and higher plans get a dedicated pair that only your account uses.

A shared IP still gives you a fixed address, but an allowlist that trusts it also admits other customers' traffic from that IP. Use a dedicated pair when the allowlist is a security control, such as a production database or a bank API. See planned pricing.

Regions

Each IP pair lives in one region. Pick the region closest to the destination, not to your app. A Mumbai pair is the right choice for an Indian bank API even if your app runs in the US.

Planned launch regions: Mumbai (India), Chennai (India), Bangalore (India), Singapore (Singapore), Jakarta (Indonesia), Tokyo (Japan), Sydney (Australia), Frankfurt (Germany), New York (United States), Virginia (United States). The Mumbai endpoint is mum.egress.fixedmark.com. Host names for the other regions are listed in the dashboard at launch. See regions.

IPs cannot move between regions. Plans with two regions give you a pair in each, and you allowlist all four addresses. Automatic failover across regions is on the roadmap.

Apps and tokens

An app groups usage, logs, and IPs. Each app can hold several tokens, so you can give each environment or service its own credential and rotate one without touching the others. Rotating a token never changes your IPs.

• Fixedmark stores only a hash of each token. Copy the token when you create it.
• A token can carry a destination allowlist, for example api.razorpay.com:443 and db.example.com:5432. The proxy refuses any other destination, so a leaked token cannot reach anything else.
• Proxy nodes check tokens locally from a cached copy. Authentication keeps working if the Fixedmark control plane is down.

The TLS proxy endpoint

A classic HTTP proxy listens on plain TCP. Your client sends the credentials in a Proxy-Authorization: Basic header, which is base64, not encryption. Anyone on the network path between your app and the proxy can read the token.

Fixedmark's proxy URL uses https:// on port 443. Your client opens TLS to the proxy first, then sends the CONNECT request and the credentials inside that TLS session. For HTTPS destinations this means two layers of TLS: one to the proxy, and your own session to the destination inside it.

CONNECT tunnels and plain HTTP requests

For an https:// destination, your client sends CONNECT api.example.com:443. The proxy checks the token and the destination allowlist, connects from your static IP, replies 200 Connection Established, and then copies bytes in both directions. It reads the TLS SNI for connection logs and nothing else.

For an http:// destination, the client sends the full request to the proxy, such as GET http://example.com/. The proxy forwards it. That request is plain text on the internet anyway, so prefer HTTPS destinations.

Usage counts a request as one new CONNECT or SOCKS session, or one plain HTTP request. Clients that reuse connections send many HTTPS requests through one tunnel, which uses fewer requests from your plan.

SOCKS5, socks5 and socks5h

SOCKS5 on port 1080 carries any TCP connection: Postgres, MySQL, MongoDB, Redis, SSH, or SFTP. It authenticates with your app ID and token as username and password. SOCKS5 authentication is not encrypted, so the token crosses the network in clear text on this hop. Your database's own TLS still protects the data. The planned bm tunnel CLI wraps SOCKS5 in TLS.

The scheme decides where DNS happens:

• socks5h:// sends the host name to the proxy. The proxy resolves it in its region. Use this.
• socks5:// tells many clients, including curl and Python requests, to resolve the name locally and send an IP. Your local resolver sees every lookup, and geo-DNS can return an address meant for your app's region instead of the proxy's.

Some clients ignore the difference. Go's net/http treats socks5 the same as socks5h, and the MongoDB Node.js driver always sends the host name.

Which protocol to use