没想到 2026 年，还要浪费大量时间在跨域问题上

还有这么菜的开发吗，这种还能混下去真幸福啊

之前我司有个人把解决跨域写在了年会上

菜鸡互啄

想知道后续那个后端怎么处理的跨域（狗头）

你别说 如果是 server 开发来顶替 web 开发
确实很多浏览器的行为不是很清楚

虽然我觉得很菜，但是部分螺丝钉企业还这能理解。。。因为跨域本身是浏览器的行为，如果部署的时候再用容器化技术，响应头都是运维来设置，开发测试的时候前端再用个反代，后端没接触过也正常

前端自己配个代理不就完事了么。自己解决就没那多 b 事了。

如果是纯后端，没有深度理解跨域也很正常，感觉很多跨域问题的帖子都是前端开发提出来的

@Cruzz #7 6

@Cruzz #7 还是你懂

我多年前实习的时候也碰到过一个这种后端，技术拉完了，登录接口来个 url 参数传账号密码，还要明文。然后每天都会提到他的摸摸唱经历，还好那家公司一个月不到就倒闭了。

一说又想起来，那老板也是奇葩，国外留学回来的一个女的，上来说什么武汉有几千万环卫...过于愚蠢我都没有插话。

这个为啥要截图发给后端开发？为什么部署到测试环境才发现跨域？不是开发环境就应该知道跨域了并通过 dev server proxy 解决了？测试生产配个 ng 反代自己解决就是了。你还心累上了

有没有可能是你的问题

@programMrxu 咱们该叫啥来着

@Cruzz 确实，服务也应该前端写

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers *;
add_header Access-Control-Allow-Methods *;

@Cruzz 然后上生产还是跨域，哥两一起加班

从描述上无法判断楼主是后端还是前端

才十几个回复就有好几个不懂的了，跨域问题让前端配代理。
AI 淘汰的人还是太少了。

这玩意对于 AI 就 1 分钟解决的事情。。

@xxyang 无条件放行，这么勇？

@lujiaosama 真的要搞你，岂是几个头能拦住

@xxyang 别的不说，至少对象存储得拦一下吧。

正确方法是前端配置代理+后端配置 nginx 转发解决跨域。所以这不是前后端两个人的问题么

@Garwih 测试环境本地 hosts 写个转发，本地 nginx 监听，转发的时候强行加个头，咋不行了，又不是发布环境，如果后端真不懂，你等他搞还真不如本地转发下

@Garwih op 是测试环境发现跨域，这样解决也没啥问题啊

@Garwih 感觉是你不懂，AI 淘汰的说不定就是你咯。。。

开发环境下，跨域一直都是前端配置的，比如 vite/webpack 都提供的有配置
上线之后，有 BFF 层的项目也是前端处理的。没有 BFF 层的还有一部分是运维处理的，真让后端处理的才是比较少的。

而且因为有 access-control-allow-headers 这个配置，具体怎么配置，一定是有前端参与沟通的指定的，反而是后端不一定会管这个事。

不要笑。现在 AI 厂家原生支持跨域的有多少？

甚至明明可以 API key <-> origin 双向绑定加强安全性的。

接口部署到了测试环境你不应该在本地代理测试环境或者也发到测试环境吗

@ARIInV2 #16 上纲上线来说，这是测试环境，如果你用测试环境页面访问测试环境接口跨域，找后端，找运维都没问题，自己本地连测试环境接口跨域不很正常，不解决不也正常？不上纲上线，你都说了他菜，费半天劲解决不了，浪费时间浪费精力，自己反代一下很困难么，不会就别说人家菜了。最烦 bb 赖赖的。越菜的 b 话越多。

@Cruzz #7 6 ，去养猪吧

- 如果你的应用本身只是小应用，用的人不多，那么你用「 BFF/反向代理」简易搭一个都没问题
- 但是如果你的应用相对比较大，复杂度比较高，我觉得还是应该老老实实配置 CORS ，多一层「 BFF/反向代理」反而会带来很多麻烦，包括性能、成本，还有「代理」本身还需要监控、管理，错误排查链路更复杂，SSE 之类支持更复杂等，除非你真的需要「 BFF 」，不然的话，加多一个实体就是加多一层麻烦。

@Cruzz 配代理如果出了问题，会说你为什么配代理，导致安全扫描 balabala 有问题。还是得后端自己启动，前端不管，后端想办法去

合久必分，分久必合

另外，测试环境跟生产环境有架构上的差异会导致测试环境丢失很多它原来能起到的作用。

这玩意不都是运维搞吗，运维会在 nginx 处拦截，判断是否是公司域名或者白名单域名，使用“add_header Access-Control-Allow-Origin 请求域名;”设置跨域，并且还要使用"proxy_hide_header Access-Control-Allow-Origin;"隐藏后端返回的跨域，防止双重跨域并且禁止使用*设置跨域值。

要么一直做前后端同源的项目
要么大公司出来的，这种事情有 SRE 来负责
要么做的项目 nginx 反代 cors 配置都是别人弄好了 不需要他关心
我也不知道楼里在优越什么。。。

日常前端吐槽后端不懂 CORS

@sagnitude
@andyskaura
@lscho #28 楼主都说了上测试环境了，明显开发环境已经配了反向代理。测试环境还让前端用 vite/webpack 配代理就是完全不懂 CORS 。作为 Web 后端不懂 CORS ，要么就是纯螺丝钉，工作过的公司都是运维弄好。要么就是菜了。

正式、开发和测试环境跨域由运维配置，前端本地联调两个方案：
1. 让运维把 localhost/127.0.0.1 加白名单；
2. 前端自己启动一个 nginx 再反代；
如果公司有明确的运维，除非你直接调用后端服务，不走任何代理，否则跨域不该后端管（我司后端在代码中手动写跨域也不生效），后端兼管反代程序的另算；

@X0V0X #18 可能他们不需要上生产、也不需要发测试，本地写好就可以了。请访问 http://localhost:5173

@Cenat 正解，很多人以为自己遇到过跨域问题并且解决了跨域问题，就想当然以为别家公司也有很多人应该懂，从来没去考虑过为啥很多人都不懂，难道大家伙天天都要面对跨域这个问题吗？有些操作后端开发其实都不需要处理的，不懂也正常，不要简单套用自己的规则强加给别的开发

我也不是懂哥什么都懂，但是我感觉都是打个螺丝没必要比谁更专业。

一个茅坑能有不同物种的大便吗？

@yakumo520 我找运维给把页面配置到接口的同一个域名和端口下面了

@Garwih #40 你的主题已经飘了，以及，跨域问题你聊到反向代理，vite/webpack ，有一定联系，但还是很奇怪，不太确定。 建议你多回复几条大家再看看

有些后端不是一般的菜，例如：

- 公司后端写的接口部署到测试环境了，访问之后发现跨域了 [测试环境跨域，后端部署之前不检查吗？]
- 把浏览器的跨域截图发给后端开发，问我报什么错了？ [娘 xp ，都 2026 年，跨域报错都看不懂？]

楼上还有说，本地配置代理？你 tm ，真是个人才。

现在都 2026 年，后端不懂跨域，理所应当？

标准方案就是前端自己配代理服务，前端既然要搞工程化就要解决这种问题，后端不仅不用帮你解决跨域而且还要限制死，毕竟这是运维的事

后端能解决,前端也能解决,看谁去解决

前后端互相看不起，那看看谁先被 AI 淘汰咯

@lscho #28 有时候感觉前端挺迷惑的，本来专心写写页面改改样式就好了，数据就让前后端联调，他们非要搞一套工程化，一上来就安装各种服务各种包，越搞越复杂，但是稍微涉及到点原理的他们又理解不了

@Cruzz #31 上纲上线来说，测试环境出的问题不解决，反而取巧，正式仍然会出问题。

@hushuikun 在这种问题上还能吵几十层楼，说明全部都应该被干碎淘汰，愚蠢的碳基人类。

不知道为什么很多人有优越感 很多大公司大项目复杂度高 有专门一个团队来做 项目部署上线 服务器管理与交互
一般开发者不懂不是很正常 还是说大家都是做小项目全栈一把梭？没有任何分工？

哈，看我这个 800+收藏的老帖子就知道了
t/1056504

@guansixu *

@yakumo520 *

因为跨域问题在部署环节解决比较合理，反代/LB 上做个配置就行了，不必把问题扩散到后端开发业务功能的环节。

现实中哪怕是在眉毛胡子一把抓的小公司，做业务功能开发的一般对操作系统 API 、网络、现成基础设施的熟悉程度都比较低。早些年遇到一些这种类型公司的开发者来做项目，他们的程序员很倾向于什么需求都“开发”，但我更希望他们能尽量用好基础设施，能用运维手段解决的就不要写到业务代码里去。

搞了半天还是要运维去解决，吐槽后端干什么呢，后端有权限修改 nginx 解决？

@andyskaura #46 开发环境用 vite/webpack 配置 proxy 就是本地 node.js 开发服务器的反向代理。
部署到测试环境之前，要么用 CI/CD 工具自动化打包，要么前端手动打包，最后提交到测试服务器只会有静态文件。
楼上很多让前端在测试环境配置代理的，至少一大半都觉得前端可以用 vite/webpack 配置来解决这个问题。什么草台班子会在测试服务器安装 vite/webpack 还启动开发服务器做代理？
Web 后端在纯螺丝钉的工作流程中，有运维处理这种问题，没配过可以理解。但是工作多年多多少少会遇到过这种问题，连跨域报错都看不懂，这是一个合格的 Web 后端？

这东西不是在 nginx 里反向代理，转发请求给到后端服务？后端服务看看是不是监听在 0.0.0.0.问题在于 nginx 在哪里配置的问题罢了。

还在这分前后端呢，各位早些走全干路线吧

看了下时间，确实是 2026 年

t/1056504#reply272
不懂的来这里学习一下

@Garwih #61 不好意思 刚刚戾气重，先道个歉。
你说的这种场景下确实不应该前端配，毕竟和前端没关系了。
但 op 说的是接口部署到测试环境，理解上有偏差。
最后 我支持你的观点，专职 web 的后端必须要理解跨域。

直接上 BFF 算了，给那帮菜鸡擦屁股又不是一次两次了。都 2026 年了，还以为前端完全不懂后端，就能把锅全给前端是吧

你这话说的, 那 claude 把源代码打包 push 上去的,算什么,还两次,低频次的问题花点时间解决有什么问题吗? 又不是每天都能遇到跨域问题,可能职业生涯也就能遇到 2,3 次需要后端自己解决配置跨域

发消息只发截图吗

@xxyang 但是通配符会拦住你自己： https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors/CORSNotSupportingCredentials

看来今年真的不是 2026 年啊

你们后端 api server 的需求分析里面没有跨域相关参数的配置项开关和支持的域名么

如果没有，那就上会轮需求分析人员呗

跟开发较什么劲

俺一直不理解，不是前端早就可以全栈了吗，难道用 nodejs 转发下请求都不行吗

这不是 nginx 上配置一下就可以了么？我们当时是这样操作

这不应该由前端自己解决吗，开发有 vite 生产有 nginx ，不然后端天天改白名单。

在大厂，其实我也至今不知道怎么解决跨域。因为前端到我具体服务后端套了 n 层服务和网关，我也不知道中间哪一层拦截的，找谁或者找哪个服务配置，或者具体怎么配置

前端眼里的后端：产品+运维+后端，深有体会

我们公司的前段连 nginx 配置都不懂

看了这个帖子，唉

@Cruzz #7 要不后端代码也让前端顺手写了得了

没想到 2026 年，还要浪费大量时间在跨域问题上

我没明白,既然 op 需要花费大量时间解决这个问题,那为什么要嘲笑别人呢?如果不需要花费大量时间,那直接解决不就行了吗?我确实没明白这个简单问题为啥需要花大量时间

这里目测一大半的人仿佛只要不报错就算是解决了, 而完全不在乎是否违背了同源策略的本意.

有很多方式可以让浏览器不报错, 但浏览器为什么报错? 总不能是为了故意给你找事吧? 绕过了报错那安全风险你愿意承担吗

另一方面很多公司前端甚至没有碰服务器的权限, 配代理就完了, 谁来配, 你配吗? 开发环境测试环境前端自己本地可以配代理, 生产环境你让用户本地配代理吗?

顶楼上，不知道大量是多大量

@faust24601 不是楼上，是楼楼上

炸出了这么多不懂装懂的

www.taobao.com 请求 api.taobao.com ，楼上的大佬们能不能教我一下前端怎么配代理？

后端真难。要懂运维，要做 dba ，甚至还要做 ba 。 不会一种就是菜。 为啥前端没试过自己去尝试？我们公司部署前端都要后端来，也没说过他们这都不懂。 本地代理能解决的自己解决，线上我觉得开放全部或者指定域名也不是两个开发拍个脑袋能决定的。 你自己也可以去配 nginx 代理，为什么默认这是后端的工作呢

如果是额外加了 header 导致跨域，你给我个截图 我问你什么报错的意思大概是要你复制文字吧

这个问题，一般是 infra 网管层去解决，既然提了这个问题，那估计直连后端 server 了。

后端都是大爷

本人后端，api server 从来不会去设置和配置跨域等相关配置。为什么呢，因为 api server 压根不会直接暴露给前端，而是通过网关（简单点的可能是 nginx ）转发过去的，所以跨域这一层，肯定是网关上配置的。优先权限级别低的后端，压根不了解网关这一层该怎么处理。所以嘛，都是草台班子。

明明是浏览器的问题，关我后端批屁事？ /s

CORS 应该是运维解决的问题吧？

@guansixu 牛鼻，从根本上解决问题，

一个简单问题炸出来这么多自以为是的人

我呆过的这种问题都是 infra 解决，不是业务后端该考虑的

熟悉了 v 站回来了，比那些家庭类、情感类、选车类的破贴有意思多了

不理解，一个跨域为什么需要浪费大量时间

后端：我用 Postman 测过了，接口完全正常。前端怎么还能出错？真的水，难怪说前端娱乐圈。
前端：奶奶滴，要不是你们不搞跨域，我完全可以用代理解决啊。但这代理一搭，后面又出各种问题，天天踩坑，谁受得了？

直接 chrome --disable-web-security

公司里不会跨域的后端现在送外卖可溜了，一送一个不吱声

CORS （跨域资源共享）是浏览器的安全限制，不是后端拦截了你，而是浏览器拦截了后端的响应，不交给前端。
解决方案有三个:后端声明;前端代理;运维反代
无脑把问题甩给后端那就是纯菜鸡