Last updated September 7, 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.
If the connection landed on your organization's edge, someone inside ran the test from a computer on your network, and the address we tested is the one your network presents to the internet. Before the first test the page asks that person whether the connection is their own or a network they run and are allowed to test, and we keep the answer with the record. When the name of the address looks like a school, college, hospital, or other organization, the "my own connection" answer is not offered at all: the test stays off until they confirm that they run the network.
Send us the address and the time in UTC and we will tell you what the record shows, including the answer that was given. If you would rather the tool never tested your network again, ask for the exclusion in the same message.
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 honor
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-honor 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.
An address whose reverse DNS name carries a government or military label is refused before any connection is attempted, whoever is asking, and the person is told why and how to ask. This works by name, so a government address with no name in reverse DNS is not caught by it. The exclusion list above is the tool for that case.
If you run such a network and want the test available on it, email help@testmyfirewall.com from your organization's own email domain with the address range in CIDR form and your role. We check that the range is registered to your organization, confirm your role through your organization's own website or directory rather than by replying to the message, and answer with the date the permission runs to, normally a year. There is no charge. While the permission is in force, anyone on the range who runs a test is still asked to confirm that they run the network, and that answer is kept with the record.
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 center that handled it, a request identifier, the answer the person gave to the question before the test, and a one-word note of what the address's name suggested (an organization or a government network), if anything. When a written permission covered the address, the line says so. The reverse DNS name itself is shown to the person and not kept. 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 behavior. 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.