Español
English
Català
FrançaisQue una petició funcioni al teu ordinador no demostra que també funcioni des del web publicat. En local, el frontend i l’API poden compartir origen, un proxy de Vite pot reescriure el camí o el navegador pot fer servir una URL que només existeix a la teva màquina. En producció canvien el domini, el protocol, les rutes i la política del navegador. Comença identificant quina petició surt realment del navegador i quina resposta rep.
Aquesta guia diagnostica el límit entre frontend i API. No explica com construir i publicar una aplicació React ni com configurar variables públiques de Vite: consulta la guia per publicar React i Vite des de Git i la documentació de variables d’entorn de Vite. Si has de decidir on executar cada component, llegeix quin allotjament necessita un web creat amb IA.
1. Inspecciona la petició a Network
Obre les eines de desenvolupador, selecciona Network/Xarxa, repeteix una acció i selecciona la petició fallida. Anota’n l’URL completa, el mètode, l’estat, el Content-Type, l’iniciador i si abans apareix una petició OPTIONS. No comparteixis galetes, capçaleres d’autorització, cossos amb dades personals ni claus.
Comprova el nom de l’amfitrió. Si conté localhost, 127.0.0.1 o una adreça privada, el navegador del visitant intentarà connectar-se al seu propi dispositiu o xarxa, no al teu ordinador ni al teu servidor. Canvia-la per una ruta d’API accessible des del web o per un domini HTTPS real que controlis. Cerca també aquestes cadenes als fitxers compilats: una variable que es digui «producció» no canvia el valor incrustat si no tornes a construir l’aplicació.
Una ruta com /api/orders es demana al mateix origen que ha servit la pàgina. Només funcionarà si la plataforma, el servidor web o un proxy de producció envia aquesta ruta a la teva API. server.proxy de Vite pot ajudar durant npm run dev, però no s’incorpora als fitxers estàtics que crea npm run build. La descàrrega del navegador no pot crear un servei backend.
2. Separa el preflight de la petició real
Quan una crida entre orígens fa servir JSON, Authorization o altres capçaleres no simples, el navegador sol enviar primer OPTIONS. El servidor ha de respondre amb l’origen, els mètodes i les capçaleres permesos. Si rebutja aquest preflight, el navegador no envia la petició principal posterior.
Això és diferent d’una petició simple, com alguns POST amb Content-Type: text/plain. El servidor pot rebre-la i modificar l’estat encara que CORS impedeixi a JavaScript llegir la resposta. CORS controla quines respostes pot llegir el navegador; no autentica l’usuari ni garanteix que el servidor no hagi processat l’escriptura. No utilitzis Access-Control-Allow-Origin: * com a pedaç o control d’accés. Autentica i autoritza al backend, valida el cos i aplica protecció CSRF quan correspongui. Comprova Origin segons el disseny; aquesta capçalera, tota sola, tampoc no és autenticació.
3. Un estat HTTP 200 pot contenir la pàgina equivocada
Mira el tipus i el cos de la resposta. Si /api/profile retorna 200 i text/html amb l’HTML de l’aplicació, pot ser que una regla alternativa hagi enviat la portada en comptes de la resposta de l’API. El transport s’ha completat, però el codi esperava JSON. Un 404, 502 o una pàgina d’error HTML a la ruta de l’API és un altre indici.
No donis l’operació per desada només perquè fetch() no ha llançat una excepció: els estats HTTP d’error normalment també generen una resposta. Comprova response.ok i el tipus de contingut abans de processar la resposta. Per exemple:
const response = await fetch('/api/status');
const type = response.headers.get('content-type') || '';
if (!response.ok || !type.includes('application/json')) {
throw new Error(`Resposta inesperada: HTTP ${response.status}`);
}
const data = await response.json();Això només comprova l’estat HTTP, el MIME i que el cos es pugui interpretar com a JSON; no en valida els camps. Comprova la forma de l’objecte i el resultat de l’operació abans de dir que s’ha desat. Tampoc no corregeix l’encaminament ni crea una API.
4. Reprodueix l’error per capes
Prova l’URL exacta del backend fora del navegador amb un client HTTP i dades sintètiques. Si també falla, revisa DNS, TLS, ruta, procés, mètode i registres del backend. Si el client HTTP funciona però Chrome falla, revisa el preflight, l’origen i les capçaleres. Si Chrome mostra 200 amb un cos HTML, corregeix l’encaminament del servidor o la regla alternativa. Després repeteix una operació només de lectura; evita fer proves d’escriptura sobre dades reals.
Al backend, confirma si la petició ha arribat i si ha tingut efecte. Un missatge «blocked by CORS» a la consola del navegador no demostra que no s’hagi escrit res. Fes servir identificadors de petició i registres sense secrets per relacionar el resultat.
Què s’ha provat i què no
L’assaig local d’aquest article va executar deu casos amb HTTP i Chrome sobre un fixture sintètic: proxy de desenvolupament, absència de proxy en un build estàtic, alternativa HTML amb estat 200, ruta del mateix origen, preflight permès i rebutjat, escriptura simple amb resposta que CORS amaga, controls d’escriptura independents, cicle de vida del procés i rutes/assets en dues mides de finestra. Tots van passar en aquell fixture. També es va comprovar que un Origin falsificat podia escriure a la demostració protegida per origen, cosa que confirma que aquest control no és autenticació.
El fixture no és una integració del producte Hostbrid ni d’un compte de client. No prova autenticació, galetes, pagaments, base de dades, correu, TLS, persistència ni desplegaments de clients. La demostració només amb CORS permet expressament una escriptura sintètica i no s’ha de copiar com a patró de producció. La prova tampoc no demostra indexació ni posicionament.
Per a una aplicació que necessiti un procés en execució, comprova la disponibilitat i els límits de Projects. Si necessites controlar el sistema operatiu i fer-te càrrec de l’operació, consulta VPS. Tria segons el procés real que necessita el backend i confirma l’abast i el preu del pla abans de contractar.