Different ports = different origins
- Input
- http://localhost:5173 → http://localhost:3000
- Expected output
- Bloqueado sem CORS configurado no servidor da porta 3000
Even with both running on your own machine.
Carregando ferramenta… / Loading tool…
CORS blocked on localhost
Frontend on port 5173 and API on port 3000, both on your own computer, and the browser still treats it as a real cross-origin call, blocking it without CORS configured on the server.
Even with both running on your own machine.
The most common pattern in Node.js APIs.
That's exactly the symptom of a CORS block: the browser rejects the fetch() promise before handing any data to JavaScript, without detailing why. The catch is that this same generic message also shows up for DNS, TLS or connectivity failures, so the browser does not distinguish the two for the script that made the call.
Yes, and that is exactly why this tool explains that a "Failed to fetch" can be either CORS or a connectivity failure, the browser does not distinguish the two for the page's JavaScript. First check whether the server is actually running (e.g. by opening the URL directly in the browser).
Yes, if the frontend and API are on different domains or subdomains in production, you need the same CORS configuration on the server, now pointing at the real production domain instead of localhost.
Your browser makes the real request to the URL you enter, exactly like any page would. If the call completes, the current origin was authorized. If it's blocked, the browser never shows the page any data, that alone is the result.
This request only uses a method and headers CORS considers "safe" (GET/HEAD/POST with a simple Content-Type and standard headers), so the browser sends it directly, with no OPTIONS check first.
The test request leaves your browser directly for the URL you entered, the J-Kit server never sees, resolves or intermediates that address. It's the same kind of call any script on your own page would make.