Test HTTP status codes
Quickly verify how clients handle any status from 100 to 599 with plain HTTP calls.
Live snapshot
Connection report
IP address
IPv6 address
IPv6 address
🇺🇸 United States
Headers
Request headers
8 headers
| Header | Value |
|---|---|
| accept | */* |
| accept-encoding | gzip, br, zstd, deflate |
| cache-control | max-age=259200 |
| connection | close |
| host | nossl.sh |
| user-agent | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) |
| via | 1.1 squid-proxy-5b5d847c96-788gb (squid/6.13) |
| x-forwarded-for | 216.73.216.63 |
Copy-and-run examples
Answer the popular "test http status" query with simple curl commands against nossl.sh/status/:code, no setup required.
Everything stays on HTTP so you can run these checks on captive portals, kiosks, and restricted networks.
- curl -i http://nossl.sh/status/418
- curl -i "http://nossl.sh/status/302?location=https://example.com"
- curl http://nossl.sh/status/204 (no body by design)
Why this tester helps
Simulate redirects, client errors, and server errors without standing up a new service or editing configs.
Responses disable caching so every request is fresh when you retest.
- Supports any integer status code from 100 through 599.
- Strips newlines from Location headers to keep output predictable.
- Great for regression checks in CI or monitoring scripts.
Do all codes return a body?
1xx, 204, and 304 responses omit the body to mirror real servers. Others include a short plain-text line.
Can I test HTTPS behavior too?
Yes, but start with HTTP for captive portals or constrained devices. Switch to HTTPS if you need to compare redirect handling across schemes.
Quick steps to trigger captive portals
Apple captive portal check
Open the official Apple CNA page to force the captive assistant on iOS and macOS devices.
Open Apple captive portalAndroid captive portal check
Use the Android connectivity check URL that devices call before presenting the portal dialog.
Open Android captive portal