> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/network-tests/proxy-rule-test.md).

# Proxy Rule Test

## What it does

Most proxy and VPN clients route traffic by **rules**: this domain goes direct, that one goes through the Japan node, another through the work server. This is usually called split routing or rule-based routing.

The problem is that rules are silent. Nothing tells you whether a rule actually matched, or whether traffic quietly fell through to your default policy.

**Rule Test** — listed as *Proxy Rule Test* in this handbook — solves that. It gives you **8 test domains**:

```
ptest-1.ipcheck.ing
ptest-2.ipcheck.ing
...
ptest-8.ipcheck.ing
```

You point each domain at a different rule group in your client. MyIP then opens all eight and shows you the exit IP each one came out of. One card per domain, eight cards in total.

{% hint style="info" %}
This tool is for people who run a proxy or VPN client with a rules file. If you just use a simple VPN app with an on/off switch, you do not need it — see [Is My VPN or Proxy Working?](/knowledge-base/diagnose/is-my-vpn-working.md) instead.
{% endhint %}

## How to set it up

{% stepper %}
{% step %}

### Add the rules to your client

Open your client's configuration and add one rule per test domain, each pointing at a different policy or proxy group. The exact syntax depends on your client; a common form is `DOMAIN,ptest-3.ipcheck.ing,POLICY`.

{% code title="proxy rules" overflow="wrap" %}

```ini
# Rule Testing
DOMAIN,ptest-1.ipcheck.ing,Proxy1
DOMAIN,ptest-2.ipcheck.ing,Proxy2
DOMAIN,ptest-3.ipcheck.ing,Proxy3
DOMAIN,ptest-4.ipcheck.ing,Proxy4
DOMAIN,ptest-5.ipcheck.ing,Proxy5
DOMAIN,ptest-6.ipcheck.ing,Proxy6
DOMAIN,ptest-7.ipcheck.ing,Proxy7
DOMAIN,ptest-8.ipcheck.ing,Proxy8
```

{% endcode %}

Replace `Proxy1` … `Proxy8` with the names of the policies or groups you actually want to test. You do not have to use all eight.
{% endstep %}

{% step %}

### Reload the configuration

Rules only take effect after your client reloads them. Restart the client, or use its reload button.
{% endstep %}

{% step %}

### Open the tool

Open **Rule Test** in the Advanced Tools. It starts checking the eight domains as soon as it opens. Use **Refresh All** to run it again after changing rules.
{% endstep %}
{% endstepper %}

<details>

<summary>Bonus rules for the main dashboard</summary>

The project also suggests these rules, so the dashboard can show your real IP and your proxied IP side by side:

```ini
# IP Testing
IP-CIDR,1.0.0.2/32,Proxy,no-resolve
IP-CIDR6,2606:4700:4700::1111/128,Proxy,no-resolve
DOMAIN,4.ipcheck.ing,DIRECT
DOMAIN,6.ipcheck.ing,DIRECT
```

</details>

## Reading your results

Each card shows one slot:

| Field        | What it tells you                                     |
| ------------ | ----------------------------------------------------- |
| `#1` … `#8`  | Which test domain the card belongs to                 |
| The domain   | `ptest-N.ipcheck.ing`, the address that was requested |
| IP           | The exit IP the request actually came from            |
| ISP          | Which company owns that IP                            |
| Proxy region | The country that exit sits in                         |

Now compare the cards:

* **Different IPs across cards** — each rule went to a different exit. Your split routing works.
* **Two cards with the same IP** — both rules ended at the same exit. Either the two policies point at the same node, or one rule never matched and fell through to the same default as the other.
* **A card showing your home ISP and your own country** — that slot went direct, without the proxy. Correct if you meant it to; a mistake if you did not.
* **A card showing an unexpected country** — that rule matched a different group than you think. Check the rule order: most clients apply the *first* matching rule, so a broad rule higher up can swallow a specific one below.

### Status labels

| Label                       | Meaning                                                  |
| --------------------------- | -------------------------------------------------------- |
| Awaiting Test or Test Error | The check has not finished yet, or it could not complete |
| Test Error                  | That domain could not be reached at all                  |

A persistent error on one card usually means the policy it maps to is down, unreachable, or is blocking the request. An error on every card points at your client or your connection, not at the rules.

## Things to keep in mind

* These are **domain** rules. If your configuration routes by IP range, by GeoIP, or by application, those rules are not exercised here.
* Your client may cache DNS answers or connections. If a change does not show up, reload the client and press **Refresh All**.
* The country shown is where the exit node appears to be, which is not always where the server physically sits. See [GeoIP: How IP Geolocation Works](/knowledge-base/concepts/geoip-explained.md).

## What to do next

* Confirm the proxy is applied to normal browsing → [Is My VPN or Proxy Working?](/knowledge-base/diagnose/is-my-vpn-working.md)
* A site sees an IP you did not expect → [Why Do Sites See a Different IP?](/knowledge-base/diagnose/why-do-sites-see-a-different-ip.md)
* Check that DNS follows the same route → [DNS Leak Test](/knowledge-base/connection-tools/dns-leak-test.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/network-tests/proxy-rule-test.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.