code前端网Nginx反向代理技巧，管理员用好，准时下班陪女神！
在一步步提问的引导下，我发现了小G的问题...
问题的呈现
我想很多前端朋友都已经抱怨了在线调试时npm run dev或npm start太耗时（这里提到的两个npm脚本是指启动前端dev服务器）。
由于环境差异，我们提供的后端服务域名在开发和生产环境中是不同的。所以我们在查找生产问题的时候，不可避免的需要更改webpack devServer proxy的配置，指向生产环境的域名，然后重启开发环境。这个过程通常很慢。 。
有时候错误可以在测试环境中重现，所以只要到达测试环境，也可以修复问题的原因。但这不是本文的重点。这篇文章主要是关于提高调试效率。
webpack-dev-server 反向代理
0202，如果你作为开发者对反向代理不熟悉，你应该注意一下。
我们知道，域之间的连接是前端不可避免的问题。如果开发过程中不想打扰后台同事，那么前端小伙子就应该使用自己的工具来解决跨域问题。当然，如果你帮后台同事买一包辣条，他通过CORS给你解决跨域问题也是可以的。
幸运的是，webpack-dev-server可以帮助解决这个难题。节点代理中间件基于http-proxy-middleware实现。
配置也很简单：
proxy: {
// 需要代理的url规则
"/api": {
target: "https://dev.xxx.tech", // 反向代理的目标服务
changeOrigin: true, // 开启后会虚拟一个请求头Origin
pathRewrite: {
"^/api": "" // 重写url，一般都用得到
}
}
}
然后小G打断了我，表达了他的困惑。 
反向代理是什么意思？比如说我想向马云借钱，那么马云肯定不会借给我。 
但是我有一个好朋友老张，所以我就向老张借了1000块钱。但没想到这个朋友和马云关系很好。他向马云借了1000块钱，然后转给了我。换句话说，我不知道借的钱到底从哪里来。我只知道我向朋友老张借了钱，老张给我创建了一个反向代理。
具体在开发过程中，我的前端必须从域名https://dev.xxx.tech调用后端，但我的前端开发服务运行在。 http://本地主机:8080。直接跨域调用后端，会被浏览器同源策略拦截，所以这条路由行不通。
所以我需要从前端服务器创建一个代理，以便以http://localhost:8080/api/user/login的形式调用接口。前端自己的设置界面是一样的（因为我访问的是前端URL）。
但是前端服务器实际上创建了一个代理层，接口http://localhost:8080/api/user/login是://dev。 。技术/用户/登录。这对于前端开发人员来说很不方便。 
简单总结：反向代理隐藏了真实服务器；相反，转发代理隐藏了真实的客户端，类似于科学商网。
调试痛点
问题来了。假设我们在 feature 分支中开发需求。然后老板通知我们立即修复并解决制造错误。假设生产环境的域名是https://product.xxx.tech。我们通常编码sStash，然后剪切Fix分支，将Target的值更改为“://production.❀xx.tech”。 ，然后重新运行 npm start 重启开发服务器，进入生产环境，静静等待，放飞自我...
这时候我们想象“哦，如果不是等很久就好了”时间！”
是的，很多时候一个Bug并不复杂，修复Bug可能只需要1分钟，但是换环境、重新运行程序就需要1分钟。开发服务器（大多数情况下可能超过这个时间）。怎么解决这个问题呢？
代理层分离
是的，有同学已经想到了，只要把代理服务器解压就可以解决问题了，没必要将前端翻译过程与服务代理目标捆绑在一起 在生产环境中，这种 Nginx 转发为大多数人所熟悉，但很少有人在开发环境中进行同样的尝试。那么为什么不尝试一下呢！
Nginx下载
我们照常下载Nginx，并选择Windows的稳定版本。
修复了前端代理
为了在出现在线问题时不必更改代理目标并重新运行npm start，我们修复了前端代理层的目标。 。比如我总是到达地址127.0.0.1:8090（当然实际访问端口可以根据个人情况更改）。
proxy: {
"/api": {
target: "127.0.0.1:8090", // 固定代理目标
changeOrigin: true,
pathRewrite: {
"^/api": ""
}
}
}
那么从127.0.0.1:8090肯定无法访问后台界面，继续往下看！
Nginx代理
由于前端接口访问固定为127.0.0.1:8090，所以剩下的工作就交给Nginx了。我们只需要监听Nginx本地的8090端口，并将所有请求转发到目标服务器即可。配置如下：
server {
listen 8090;
server_name 127.0.0.1;
location / {
proxy_pass https://dev.xxx.tech;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
# proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
可以看到，我在配置中注明了X-Real-IP，生产环境中配置了Nginx。通常，这些由 Host、X-Real-IP 和 X-Forwarded-For 保存，以保存请求服务器的域名、原始客户端的 IP 地址和代理服务器等信息。
如果不注释X-Real-IP，则前端访问入口的真实IP地址为 。 Nginx 无法识别这样的本地 IP，并直接返回 404 给客户端。客户端请求不会被代理到其他远程服务器。不废话了，这里具体原因我也不知道。如果有人知道原因，请告诉我。非常感谢。 好了，回到正题，通过上面的配置，我们就可以将前端代理层和Nginx代理层分开了。前台通过本地地址 Nginx 热重启速度非常快，只需一条命令即可访问，几乎零延迟。 闻言，小G重新加入了我的军队。 幸运的是，我做好了准备，没有遇到任何问题。 如果您确实遇到本地端口繁忙的情况，最简单的方法当然是更改端口。 为了防止这种情况，我们可以引入具有“假”效果的本地域名。 我们知道，只有解锁域名后才能获得真正的服务IP。域名解析过程中还有一些关键节点是我们需要了解的。 借用一张网上的图片（以说明删除和大致过程）。 上图中没有包含hosts文件，但这并不影响我们的魔法修改。我们只需要在OS的hosts文件节点做一些事情就可以访问本地域名了。 首先我们找到文件 然后保存这个文件，保存hosts文件时需要用到。管理员权限。 这相当于告诉本地操作系统，如果用户访问 最后，我们只需在前端项目中将代理目标设置为 这样前端访问的某个接口 不管怎样， 来源 |前端司南（ID：is_coder）127.0.0.1或localhost127.0.0.1:8090访问后台。 Nginx 确定给定的接口是开发环境、测试环境还是生产环境的代理。只需要修改nginx.conf，然后重启即可。 // windows下是这个命令
nginx.exe -s reload
// linux是这样的
nginx -s reload
本地域名
C:\Windows\System32\drivers\etc\hosts。打开后在最后添加一条分析记录127.0.0.1 www.devtest.com
www.devtest.com那么我会解析为127.0.0.1isis♺❀ mi A 在Nginx中，只需听端口127.0.0.1。配置如下。 server {
listen 80;
server_name 127.0.0.1;
location / {
proxy_pass https://dev.xxx.tech;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
www.devtest.com即可。 proxy: {
"/api": {
target: "http://www.devtest.com", // 固定代理目标
changeOrigin: true,
pathRewrite: {
"^/api": ""
}
}
}
http://localhost:8080/api/user/login就被代理到了comhttp://www.devtest。本地主机文件中的 /user/login 和 www.devtest.com 127.0.0.1x，然后x，然后。 .0.180端口，将请求转发到真正的后端服务，完美！ www.devtest.com是我专门命名的不可访问域名，所以不应该链接到，是www.taobao.com不然别怪我，如果你不能给女神买礼物。 。 。 
版权声明
本文仅代表作者观点，不代表Code前端网立场。
本文系作者Code前端网发表，如需转载，请注明页面地址。
