CORS bloqueado no localhost
Front-end na porta 5173 e API na porta 3000, tudo no seu próprio computador, ainda assim o navegador trata isso como uma chamada cross-origin de verdade, e bloqueia sem um CORS configurado no servidor.
Mesmo com os dois rodando na sua própria máquina.
Padrão mais comum em APIs Node.js.
Esse é justamente o sintoma de um bloqueio de CORS: o navegador rejeita a promise do fetch() antes de entregar qualquer dado ao JavaScript, sem detalhar o motivo. O problema é que essa mesma mensagem genérica também aparece em falhas de DNS, TLS ou conectividade, então o navegador não distingue as duas coisas para o script que fez a chamada.
Sim, e é exatamente por isso que esta ferramenta explica que um "Failed to fetch" pode ser CORS ou uma falha de conectividade, o navegador não distingue as duas coisas para o JavaScript da página. Confira primeiro se o servidor está no ar (ex.: acessando a URL direto no navegador).
Sim, se o front-end e a API em produção estiverem em domínios ou subdomínios diferentes, você precisa da mesma configuração de CORS no servidor, agora apontando para o domínio real de produção em vez de localhost.
O seu navegador faz a requisição de verdade para a URL informada, exatamente como qualquer página faria. Se a chamada for concluída, a origem atual foi autorizada. Se for bloqueada, o navegador nem chega a mostrar dados à página, esse já é o resultado.
Esta requisição usa só método e headers considerados "seguros" pelo CORS (GET/HEAD/POST com Content-Type simples e headers padrão), então o navegador a envia direto, sem checagem prévia via OPTIONS.
A requisição de teste sai diretamente do seu navegador para a URL informada, o servidor do J-Kit nunca vê, resolve ou intermedeia esse endereço. É o mesmo tipo de chamada que qualquer script na sua própria página faria.