Last updated August 16, 2026. Machine-readable contact details: /.well-known/security.txt
If you are looking at a log entry and trying to work out what connected to your network, this page is meant to answer that quickly. If it does not, write to help@testmyfirewall.com and a person will read it.
TestMyFirewall.com is a firewall and open-port test. Someone on your network opened the site and pressed a button, and our server made a single TCP connection back to the public address their browser was connecting from, so they could see whether that port was reachable from outside.
There is no field on the site where anyone can type in an address to test. The only address we will ever connect to is the one the request itself came from, which is a deliberate design limit rather than a policy we apply after the fact.
Each connection follows a person pressing a button, so someone working through several ports will produce several connections. They arrive at human speed and each one is a separate deliberate action on their part. Requests from a single address are also rate limited at our edge — no more than a few connections per ten seconds from any one address, even if it is scripted.
This runs on Cloudflare Workers, and outbound connections from Workers leave through Cloudflare's shared infrastructure. The address you see is not ours, it is not stable, and it is shared with a very large amount of unrelated Cloudflare traffic.
We would rather say that plainly than publish a number that would be wrong. Blocking the address you happened to observe would block far more than us, and would probably stop working the next day. If you need the full picture of Cloudflare's ranges, they are published at cloudflare.com/ips, but it is worth knowing that those ranges carry a large share of the web.
If you are responsible for a network and you do not want it tested, we will honour
that. Email help@testmyfirewall.com
with the ranges in CIDR form, for example 198.51.100.0/24 or
2001:db8::/32, and enough context for us to see that the ranges are
yours — a message from an address in the domain that holds them, a WHOIS or
RIR contact, or an abuse-desk address already published for them.
If your network has both, send us the IPv4 and the IPv6 prefixes. An exclusion only covers the family it is written in, so an IPv4 range on its own would still leave anyone on your network who reaches us over IPv6 able to run a test. We would rather ask than half-honour it.
Once a range is excluded, the tool refuses to test any address inside it for everyone, including people on that network who ask it to. They are shown a message saying the operator of their network has asked us not to run tests against it.
The exclusion is a change to the code the service runs, not a note in a file someone has to remember to consult. Every range is checked when the service starts, so a mistyped one stops the deployment outright instead of being accepted and then quietly ignored — if we tell you a range is excluded, the running service parsed it and is enforcing it. You are welcome to confirm it yourself: open the site from an address inside the range and the test will decline to run.
In the meantime you are free to drop the traffic at your own edge. If your firewall already dropped it, nothing reached the host and it did exactly what it should have — a single unsolicited SYN that gets no reply is precisely the result the person running the test was hoping to see.
Requests are reviewed promptly. We would rather say that than promise a response time we cannot keep, so if a request is urgent, say so in the subject line and it will be treated that way.
Some networks are refused before any connection is attempted, because a result there would not mean anything useful and the connection is more likely to be unwelcome:
Port 25 is never tested, and only TCP is ever used. We cannot send UDP.
Since August 16, 2026 we keep a short request log, added specifically so that the question that probably brought you to this page can be answered. Until then this page said the service stored nothing, which was true and which also meant that anyone asking "was this you?" got no better answer than a description of what our traffic usually looks like. That seemed like the wrong trade.
One line is written per request: the address the test ran against, the port, the result, the time, the network number, the Cloudflare data centre that handled it, and a request identifier. Refused requests are logged the same way as completed ones.
Retention is short — days, not months. That is worth knowing before you write: if the connection you are looking at is recent, we can usually confirm or rule it out against our own records rather than reasoning from general behaviour. If it is weeks old, we will tell you the record has aged out instead of guessing. Cloudflare, which serves the site, keeps its own operational and security logs under its own retention policy, and we cannot make any claim on its behalf. The full statement is in the Terms of Use.
For a security issue in the site itself, or any other abuse concern, the same address reaches us: help@testmyfirewall.com. Please include timestamps with time zone, the destination address and port, and a log excerpt if you have one. With those we can look the connection up directly and tell you whether it came from here, rather than leaving you to infer it — provided it is recent enough to still be in the log.