跨域请求被浏览器拦截，问题不在小皮面板本身，而在你站点所用的 Web 服务器（Nginx 或 Apache）没有返回正确的 CORS 响应头；只要在站点配置中补上 Access-Control-Allow-Origin 等响应头，或者用 Nginx 反向代理把接口改成同源，跨域报错即可消除。
跨域被拦截是面板的问题还是浏览器的问题？
结论：跨域拦截发生在浏览器端，是小皮面板里 Nginx/Apache 返回的响应缺少 CORS 头导致的，面板只负责托管站点，不会主动拦截请求。
浏览器同源策略要求协议、域名、端口三者完全一致，只要接口地址与页面地址不同源（比如页面跑在 localhost:5173，接口在 localhost:80），浏览器就会先发一个 OPTIONS 预检请求，检查响应头里有没有 Access-Control-Allow-Origin。没有就直接拦掉，请求不进业务代码。所以在小皮面板里排查跨域，看的是「站点配置文件的响应头」，而不是面板的开关。
小皮面板 Nginx 环境怎么加跨域响应头？
结论：在小皮面板【网站】列表中找到目标站点，打开该站点的 Nginx 配置文件，在 server { } 块内加入 add_header 指令并保存重载，是最直接的做法。
可复制的配置片段如下：
location /api/ {
add_header Access-Control-Allow-Origin $http_origin always;
add_header Access-Control-Allow-Credentials true always;
add_header Access-Control-Allow-Methods 'GET,POST,PUT,DELETE,OPTIONS' always;
add_header Access-Control-Allow-Headers 'Authorization,Content-Type,X-Requested-With' always;
add_header Access-Control-Max-Age 86400 always;
if ($request_method = OPTIONS) { return 204; }
}
三个关键点：$http_origin 会原样回显请求来源，避免与 credentials 冲突；always 参数保证 4xx、5xx 响应也带上头；if ($request_method = OPTIONS) { return 204; } 用来直接放行预检请求，不落到 PHP 里被 405 拦住。改完记得重载 Nginx，配置不重载等于没改。
Apache 环境怎么配跨域头？
结论：小皮面板切到 Apache 时，用站点根目录的 .htaccess 加 Header 指令最省事，但前提是 mod_headers 已加载且目录允许 AllowOverride All。
.htaccess 内容：
<IfModule mod_headers.c>
Header always set Access-Control-Allow-Origin "%{HTTP_ORIGIN}e" env=HTTP_ORIGIN
Header always set Access-Control-Allow-Credentials "true"
Header always set Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS"
Header always set Access-Control-Allow-Headers "Authorization,Content-Type,X-Requested-With"
Header always set Access-Control-Max-Age "86400"
</IfModule>
如果 .htaccess 完全不生效，去小皮面板的 Apache 配置文件里确认 LoadModule headers_module modules/mod_headers.so 已解注释，并且对应 <Directory> 段允许 AllowOverride All。这是 Apache 下跨域头「写了没用」的第一大原因。
不想改服务器配置，能不能用反向代理彻底绕过跨域？
结论：可以。Nginx 反向代理会让浏览器看到的请求始终是同源地址，跨域问题从源头消失，也顺便省掉了预检请求。
配置示例：
location /api/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
前端把 baseURL 写成 /api，请求走同源路径，由 Nginx 转发到真实后端端口。注意 proxy_pass 末尾带不带 / 语义不同：带 / 会去掉 location 匹配的前缀，不带则保留，配错会出现一堆 404。
前端本地开发阶段用代理是不是更简单？
结论：开发阶段优先用 Vite/Webpack 的 devServer 代理，改一行配置就能生效，不必动服务器。
Vite（vite.config.js）：
server: {
proxy: {
'/api': {
target: 'http://127.0.0.1:8080',
changeOrigin: true,
rewrite: p => p.replace(/^\/api/, '')
}
}
}
changeOrigin: true 会把请求头里的 Host 改成目标地址，防止后端做了域名校验时返回 403。这种方案只在开发环境生效，上线前必须换成 Nginx 反代或正式 CORS 配置。
头都加了还是报错，通常是哪几个坑？
结论：90% 的「加了头仍报跨域」集中在重复响应头、* 与 credentials 冲突、预检未放行、配置未重载这四类。
- 重复头：Nginx 里加了一次、PHP 代码里又
header() 了一次，浏览器报 The 'Access-Control-Allow-Origin' header contains multiple values——二选一，别叠加。
- 通配符配 Cookie：
Access-Control-Allow-Origin: * 与 Access-Control-Allow-Credentials: true 不能共存，必须回显具体 Origin，否则浏览器直接拒绝。
- 预检返回 405：业务框架没注册 OPTIONS 路由，在服务器层
return 204 拦掉即可。
- 改了没生效：Nginx 未重载，或浏览器缓存了
Access-Control-Max-Age 的预检结果，把缓存时间设小一点（如 600 秒）或用无痕窗口复测。
在小皮面板里定位这类问题，最快的方式是打开浏览器开发者工具的 Network 面板，看那条失败请求的 Response Headers 里到底有没有 Access-Control-Allow-Origin：有但值不对，改头的值；完全没有，说明配置写在了不生效的 location 或没重载。
概括来说：跨域不是面板拦截，而是响应头缺失；Nginx 用 add_header 加 always 并放行 OPTIONS，Apache 靠 .htaccess 加 mod_headers，图省事就直接反向代理变同源，开发阶段用 devServer 代理，最后避开重复头和 * 配 Cookie 这两个高频坑。
