---
title: "IP whitelisting"
url: https://proxy.wiki/glossary/ip-whitelisting/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# IP whitelisting

> Authorising a proxy by the address you connect from, instead of sending a username and password.

**IP whitelisting authorises use of a proxy based on the address your requests originate from.** You register your server’s public address with the provider, and requests from it are accepted without credentials.

## Why it is used

- No credentials in configuration files, environment variables or logs.

- Slightly lower overhead, since there is no authentication exchange.

- Convenient for fixed infrastructure with a stable address.

## Where it breaks

- **Dynamic addresses.** A home connection or an autoscaling instance changes address and access stops without warning.

- **Shared addresses.** Anyone else behind the same NAT can use your allocation.

- **Slow propagation.** Whitelist changes are not always instant, which is painful during an incident.

## Choosing between the two

For fixed servers, whitelisting is clean. For anything that moves, scales or runs on a laptop, [credential authentication](/glossary/proxy-authentication/) is more robust. Some providers allow both at once, which is usually the pragmatic answer.

## When it is the better choice

An allow-list beats credentials in exactly one situation: the traffic comes from a fixed, known address that you control. A server in a datacentre qualifies. A laptop on hotel wifi does not.

- **Nothing secret travels with the request,** so there is no credential to leak into a log.

- **An attacker who steals your configuration cannot use it** without also originating from your address.

- **The client stays simpler,** which matters for tools that handle proxy authentication badly.

## The failure mode to design for

An allow-list fails silently and confusingly. Your address changes, and every request is refused with no message that names the cause. Because nothing in the response says “your address is not listed”, the symptom looks like a broken proxy, an expired plan or a network fault.

Two habits prevent the wasted hour:

- **Record which address you registered,** in the same place as the rest of the configuration.

- **Check the current address first** whenever a working setup stops working: `curl -s https://api.ipify.org`.

On a dynamic connection, prefer [credentials](/glossary/proxy-authentication/). They travel with the request, so they survive an address change.

## Frequently asked questions

### Why did my proxy stop working without any error?

An address allow-list refuses unlisted sources without explaining why. If your connection has a dynamic address, it changed, and the entry no longer matches. Check your current address and compare it with the one you registered.

### Can I use an allow-list and credentials together?

Many providers allow both, and the combination is stronger than either alone: the request must come from a listed address and carry valid credentials. Check whether your provider treats them as alternatives or as requirements.

### Is an allow-list safer than credentials?

For a fixed address, generally yes, because nothing secret travels with the request. For a changing address it is worse, because it breaks without warning and tempts you to widen the entry to a whole range.

## Sources

1. [RFC 9110: HTTP Semantics, authentication and access control](https://www.rfc-editor.org/rfc/rfc9110.html)