---
title: "Destination Allowlists per Proxy Credential"
description: "Limit where each proxy credential can connect: exact hosts, *.suffix hosts, IPv4 CIDRs, and ports, how denials look, and what an allowlist cannot stop."
canonical: https://fixedmark.com/docs/allowlists
updated: 2026-10-24
source: Fixedmark (https://fixedmark.com), BitMask LLP
---

Manage

# Destination allowlists

An allowlist limits where one proxy credential can connect. A credential with rules reaches only the hosts, address ranges, and ports you list, so a leaked token cannot reach anything else.

Docs preview: Fixedmark is not live yet. Endpoints are issued at launch, and these pages describe planned launch behavior. Anything marked planned may change. [Join early access](https://fixedmark.com/early-access) to get yours first.

## How rules work

- Rules belong to one credential. Other credentials of the same app keep their own rules.
- A credential with no rules can reach every destination the proxy allows. Adding the first rule restricts it to what the rules name.
- A connection is allowed when any rule matches its host or address and its port.
- Nodes enforce a new or deleted rule within seconds.
- Private and reserved address ranges stay blocked whatever the rules say.

## Rule types

_Allowlist rule types_

| Rule        | Example            | Matches                                                                                                                                               |
| ----------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Exact host  | `api.razorpay.com` | That name only, compared without case.                                                                                                                |
| Host suffix | `*.example.com`    | Every name under `example.com`, such as `api.example.com`, but not `example.com` itself. The suffix needs at least two labels, so `*.com` is refused. |
| CIDR        | `203.0.113.0/24`   | Any IPv4 address in the range. A bare address is its `/32`.                                                                                           |
| Port        | `443`              | Added to a host or CIDR rule. Without a port, the rule matches every port.                                                                            |

Host rules match the name your client sends, never an IP address. A connection to an IP literal such as `203.0.113.10` needs a CIDR rule, even when a host rule names a host that resolves to it. The proxy dials exactly the addresses it checked, so a name that later resolves elsewhere cannot slip past.

## Add and test rules

In the dashboard, open the app, then Credentials, then Allowlist on the credential. Or use the API with an API key:

**Terminal**

```bash
# Allow one host on port 443
curl -X POST https://api.fixedmark.com/v1/apps/APP_ID/credentials/CRED_ID/policy \
  -H "Authorization: Bearer $FIXEDMARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"host_pattern": "api.razorpay.com", "port": 443}'

# Ask whether a destination would be allowed, and by which rule
curl -X POST https://api.fixedmark.com/v1/apps/APP_ID/credentials/CRED_ID/policy/test \
  -H "Authorization: Bearer $FIXEDMARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"destination": "api.razorpay.com:443"}'
```

The test answers `allowed` with a reason: `no_rules`, `match`, `no_match`, `resolve_failed`, or `reserved_address`. Deleting the last rule allows every destination again. Each change is written to the org's audit log.

## Plans with allowlists

Allowlists come with Business ($79 a month) and every larger plan. The 7-day trial is Starter, so it has none. On a plan without them, adding a rule answers 409 with the code `plan.feature_required` and `"feature": "egress_firewall"`.

If your plan changes to one without allowlists, the rules you have stay in force, because dropping them would let the credential reach anything. You can still list, test, and delete them, but not add new ones.

## What a denied connection looks like

_How each protocol reports an allowlist denial_

| Client       | What it sees                                               |
| ------------ | ---------------------------------------------------------- |
| HTTP CONNECT | `403 Forbidden` with `X-Proxy-Error: denied_by_policy`     |
| SOCKS5       | Reply code `0x02`, connection not allowed by ruleset       |
| fm tunnel    | `not_allowed` on that connection; the tunnel keeps running |

Each denial is a row in your [connection logs](https://fixedmark.com/docs/logs) with `result=denied_by_policy`.

## What an allowlist does not stop

- Domain fronting. A suffix rule for a CDN, such as `*.cloudfront.net`, allows every site on that CDN. A client can send an allowed name in TLS and reach another site behind the same CDN. Prefer exact hosts.
- Traffic inside an allowed connection. The proxy never decrypts TLS, so it cannot see paths or requests.
- Connections already open. A new rule, a deleted rule, or a revoked credential applies to new connections. A tunnel opened before the change stays open until it closes.

Operators: deploy new proxies before a new control plane. An older proxy ignores the rules and serves every credential without them. Rolling back the allowlist release or its migration drops every rule, so every credential becomes unrestricted until the rules are added again.

## Frequently asked questions

### Do allowlists slow connections down?

The proxy checks the rules in memory before it dials, with no extra network call.

### Can I allow IPv6 ranges?

Not yet. CIDR rules take IPv4 ranges only, and the proxy connects over IPv4.