反向代理

YARP 1.0曾经公布了，当初能够从 NuGet 下载。YARP（Yet Another Reverse Proxy）是应用 .NET 构建的高度可定制的反向代理。YARP 与其余反向代理的最大区别在于它是如何构建和打包的——YARP 作为库和示例提供，展现了如何创立依据特定场景的需要定制的代理。 什么是反向代理？反向代理用于侦听传入的 HTTP 申请并依据申请的内容将申请转发到适当的服务器。与在第 4 层 (TCP/IP) 起作用的典型防火墙/路由器不同，反向代理通常在第 7 层工作，因而它们了解 http 并基于 http 字段工作。 当 YARP 代理申请时，它会解决来自客户端的 HTTP 连贯，而后创立本人到指标服务器的连贯，单方都能够从连接池中受害。 应用反向代理有很多长处： 它充当站点或一组服务的公共端点，使裸露的 url 空间独立于理论实现将调用转发到后端服务器以执行理论工作，均衡它们之间的负载能够从后端服务器卸载工作，例如 TLS 加密、Auth 2、压缩、缓存什么是 YARPYARP 是一个提供基于 .NET 的开源反向代理服务器的我的项目。它始于大概两年前，过后咱们留神到微软团队提出的一种问题模式，这些团队要么为他们的服务构建反向代理，要么始终在询问构建一个反向代理的 API 和技术。咱们决定让他们一起钻研一个通用的解决方案，这就是 YARP。 YARP 是一个反向代理工具包，用于应用 ASP.NET 和 .NET 的基础设施并在 .NET 中构建疾速代理服务器。YARP 的要害区别在于它的设计易于定制和调整，以匹配每个部署场景的特定需要。 咱们在与创立 Microsoft 服务的团队交谈时发现，每项服务都稍微偏离惯例，他们都在构建本人的解决方案，或者尝试自定义第三方代理。尽管他们有 HTTP/1.1 的解决方案，但他们须要 HTTP/2——通常用于 gRPC，而 HTTP/2 应用二进制帧格局，实现起来要简单得多。YARP 使开发人员可能齐全管制，同时利用通过验证的 ASP.NET Core 和 .NET 功能集，以及 C#（或其余 .NET 语言）的生产力。 ...

原文地址 https://mojotv.cn/go/hardware-footprint-gui-proxy

何为反向代理镜像网站举个栗子：有小明、小刚、小红三个好朋友，小明喜欢小红，那么小明可以有两种方式向小红表白： 第一种：直接表白（直接访问）小明跑到小红面前说：我喜欢你！小红回答说：我也喜欢你！ 第二种：小明找小刚传话给小红（反向代理）小明不好意思表白，找来小刚做中间人传话，小明告诉小刚：我喜欢小红。小刚跑去对小红说：小明喜欢你。小红害羞的回答道：我也喜欢小明。小刚回去告诉小明：你两成了。 通过上面这个栗子，应该对反向代理网站有了一个比较直观的认识了。一般情况下，我们可以通过反向代理去制另一个网站的内容，一模一样，就像镜像一样。 下面我们来看如何在５分钟内快速搭建一个反向代理网站。 搭建反向代理镜像站首先选择使用Ubuntu系统来部署镜像网站，然后我们需要借助URLOS帮我们快速实现安装和部署。我们可以通过以下命令安装URLOS： curl -LO www.urlos.com/siu && sh siu安装成功后，通过浏览器访问http://服务器ip:9968，使用默认账号密码登录URLOS面板。然后在应用市场中搜索“反向代理”，点击安装即可：在基本信息中填写服务名称、选择运行节点、填写端口号：然后在网站中填写域名：在反向代理中填写需要代理的网站域名以及IP地址：完成以上步骤之后，点击提交按钮即可。部署完成之后，在浏览器中访问看一下是否已经成。

欢迎关注个人微信公众号: 小哈学Java, 文末分享阿里 P8 高级架构师吐血总结的 《Java 核心知识整理&面试.pdf》资源链接！！个人网站: https://www.exception.site/docker/docker-install-nginx 本节中，我们将学习如何通过 Docker 快速安装&搭建 Ngnix, 为您的服务添加反向代理功能。 一、下载 Nginx 镜像docker pull nginx:alpinePS：我这里用的是 alipne 轻量级的镜像.下载完成后，通过 docker images 命令检查一下镜像是否下载成功： 二、先以简单的方式运行镜像docker run -d --name nginx nginx:alpine-d: 以后台方式运行镜像；—name: 指定容器的名称为 nginx;命令执行完成后，通过 docker ps命令确认一下容器是否启动成功。确认成功后，再访问一下 80 端口，看看 nginx 服务是否启动成功： 三、复制相关配置文件至宿主机复制运行中 nginx 相关配置文件到宿主机的指定路径下： # 复制名称为 nginx 容器中 /etc/nginx/nginx.conf 文件夹到宿主机的 /docker/nginx 路径下docker cp nginx:/etc/nginx/nginx.conf /docker/nginx# 复制名称为 nginx 容器中 /etc/nginx/conf.d 文件到宿主机的 /docker/nginx 路径下docker cp nginx:/etc/nginx/conf.d /docker/nginx复制完成后，查看指定路径的配置文件，如下： 四、修改 Nginx 配置文件，添加反向代理先通过命令 ifconfig 命令获取 docker0网卡的 ip 地址： ...

原文链接：https://ssshooter.com/2019-05... 反向代理是什么放两个神图，图片来自这里。 这是正向代理 这是反向代理 正向代理是你发出请求的时候先经过代理服务器，所以实际上发出请求的是代理服务器。反向代理是“代理你的目标服务器”，请求目标服务器的代理，做一些处理后再真正请求。在这篇文章里，反向代理用于处理跨域问题。 测试环境的跨域module.exports = { publicPath: '/', devServer: { proxy: { '/wiki': { target: 'http://xxx.com.cn', // 代理到的目标地址 pathRewrite: { '^/wiki': '' }, // 重写部分路径 ws: true, // 是否代理 websockets changeOrigin: true, }, }, },}我们神奇的 webpack 有一个可以帮你实现测试跨域的插件，相信大家都比较熟悉，本质上这个插件的功能来自 http-proxy-middleware。 * 关于 changeOrigin：这个选项的作用真的看不懂（下面是源码），看代码貌似是改变 headers 的 host 字段，但是实际上我修改成 true 和 false 测试，请求头好像并没有变化。但是以前的一个项目中有一个情况是必须把这个选项设定为 true 才能正常跨域，所以保险起见设 true。这个问题先放下吧，或者大家知道的话在评论区留言指导一下 OTL。 // 附源码if (options.changeOrigin) { outgoing.headers.host = required(outgoing.port, options[forward || 'target'].protocol) && !hasPort(outgoing.host) ? outgoing.host + ':' + outgoing.port : outgoing.host}按照上面的配置启动测试环境之后，直接在浏览器输入 http://localhost/wiki/rest/api/2/user/picker 就等于访问 http://xxx.com.cn/rest/api/2/user/picker。 ...

问题背景在Web应用开发中，经常会需要获取客户端IP地址。一个典型的例子就是投票系统，为了防止刷票，需要限制每个IP地址只能投票一次。 如何获取客户端IP在Java中，获取客户端IP最直接的方式就是使用request.getRemoteAddr()。这种方式能获取到连接服务器的客户端IP，在中间没有代理的情况下，的确是最简单有效的方式。但是目前互联网Web应用很少会将应用服务器直接对外提供服务，一般都会有一层Nginx做反向代理和负载均衡，有的甚至可能有多层代理。在有反向代理的情况下，直接使用request.getRemoteAddr()获取到的IP地址是Nginx所在服务器的IP地址，而不是客户端的IP。 HTTP协议是基于TCP协议的，由于request.getRemoteAddr()默认获取到的是TCP层直接连接的客户端的IP，对于Web应用服务器来说直接连接它的客户端实际上是Nginx，也就是TCP层是拿不到真实客户端的IP。 为了解决上面的问题，很多HTTP代理会在HTTP协议头中添加X-Forwarded-For头，用来追踪请求的来源。X-Forwarded-For的格式如下： X-Forwarded-For: client1, proxy1, proxy2X-Forwarded-For包含多个IP地址，每个值通过逗号+空格分开，最左边（client1）是最原始客户端的IP地址，中间如果有多层代理，每一层代理会将连接它的客户端IP追加在X-Forwarded-For右边。 下面就是一种常用的获取客户端真实IP的方法，首先从HTTP头中获取X-Forwarded-For，如果X-Forwarded-For头存在就按逗号分隔取最左边第一个IP地址，不存在直接通过request.getRemoteAddr()获取IP地址： public String getClientIp(HttpServletRequest request) { String xff = request.getHeader("X-Forwarded-For"); if (xff == null) { return request.getRemoteAddr(); } else { return xff.contains(",") ? xff.split(",")[0] : xff; }}另外，要让Nginx支持X-Forwarded-For头，需要配置： proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;$proxy_add_x_forwarded_for会将和Nginx直接连接的客户端IP追加在请求原有X-Forwarded-For值的右边。 伪造X-Forwarded-For一般的客户端（例如浏览器）发送HTTP请求是没有X-Forwarded-For头的，当请求到达第一个代理服务器时，代理服务器会加上X-Forwarded-For请求头，并将值设为客户端的IP地址（也就是最左边第一个值），后面如果还有多个代理，会依次将IP追加到X-Forwarded-For头最右边，最终请求到达Web应用服务器，应用通过获取X-Forwarded-For头取左边第一个IP即为客户端真实IP。 但是如果客户端在发起请求时，请求头上带上一个伪造的X-Forwarded-For，由于后续每层代理只会追加而不会覆盖，那么最终到达应用服务器时，获取的左边第一个IP地址将会是客户端伪造的IP。也就是上面的Java代码中getClientIp()方法获取的IP地址很有可能是伪造的IP地址，如果一个投票系统用这种方式做的IP限制，那么很容易会被刷票。 伪造X-Forwarded-For头的方法很简单，例如Postman就可以轻松做到： 当然你也可以写一段刷票程序或者脚本，每次请求时添加X-Forwarded-For头并随机生成一个IP来实现刷票的目的。 如何防范方法一在直接对外的Nginx反向代理服务器上配置： proxy_set_header X-Forwarded-For $remote_addr;如果有多层Nginx代理，内层的Nginx配置： proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;在最外层Nginx（即直接对外提供服务的Nginx）使用$remote_addr代替上面的$proxy_add_x_forwarded_for，可以防止伪造X-Forwarded-For。$proxy_add_x_forwarded_for会在原有X-Forwarded-For上追加IP，这就相当于给了伪造X-Forwarded-For的机会。而$remote_addr是获取的是直接TCP连接的客户端IP，这个是无法伪造的，即使客户端伪造也会被覆盖掉，而不是追加。 需要注意的是，如果有多层代理，只在直接对外访问的Nginx上配置X-Forwarded-For为$remote_addr，内层的Nginx还是要配置为$proxy_add_x_forwarded_for，不然内层的Nginx又会覆盖掉客户端的真实IP。 完成以上配置后，业务代码中再通过上面的getClientIp()方法，获取X-Forwarded-For最左边的IP地址即为真实的客户端地址，且客户端也无法伪造。 方法二Tomcat服务器解决方案：org.apache.catalina.valves.RemoteIpValve RemoteIpValve可以替换Servlet API中request.getRemoteAddr()方法的实现，让request.getRemoteAddr()方法从X-Forwarded-For头中获取IP地址。也就是在业务代码中不需要再自己实现类似于上面的getClientIp()方法来从X-Forwarded-For中获取IP，而是直接使用request.getRemoteAddr()方法。想要使用RemoteIpValve，仅需要在Tomcat配置文件server.xml中Host元素内末尾加上： <Valve className="org.apache.catalina.valves.RemoteIpValve" ... />RemoteIpValve有一套防止伪造X-Forwarded-For的机制，实现思路：遍历X-Forwarded-For头中的IP地址，和方法一不同的是，不是直接取左边第一个IP，而是从右向左遍历。遍历时可以根据正则表达式剔除掉内网IP和已知的代理服务器本身的IP（例如192.168开头的IP），那么拿到的第一个非剔除IP就会是一个可信任的客户端IP。这种方法的巧妙之处在于，即使伪造X-Forwarded-For，那么请求到达应用服务器时，伪造的IP也会在X-Forwarded-For值的左边，真实的IP为放到右边的某个位置，从右向左遍历就可以避免取到这些伪造的IP地址。 方法三Node.js 框架 Egg.js 的解决方案：https://eggjs.org/zh-cn/tutor... Egg.js 可通过设置maxProxyCount指定代理层数，然后取X-Forwarded-For头中从右往左数第maxProxyCount个IP即为真实 IP 地址，如果有伪造 IP 地址了必然在最左边，就会被忽略掉。 ...

Nginx通过反向代理做负载均衡时，如果被代理的其中一个服务发生错误或者超时的时候，通常希望Nginx自动重试其他的服务，从而实现服务的高可用性。实际上Nginx本身默认会有错误重试机制，并且可以通过proxy_next_upstream来自定义配置。 如果不了解HTTP协议以及Nginx的机制，就可能在使用过程中遇到各种各样的坑。例如服务出现了错误或超时却未重试，或者一些例如创建订单或发送短信这类的HTTP接口，客户端只发送一次请求，后台却由于Nginx重试导致创建了多个订单，或者收到多条短信，导致一些业务上的问题。 proxy_next_upstream在Nginx配置文件中，proxy_next_upstream用于指定在什么情况下Nginx会将请求转移到其他服务器上。其默认值是proxy_next_upstream error timeout，即发生网络错误以及超时，才会重试其他服务器。默认情况下服务返回500状态码是不会重试的，如果想在响应500状态码时也进行重试，可以配置： proxy_next_upstream error timeout http_500;当然还有http_502、http_503、http_404等可以指定在出现哪些状态码的情况下需要重试。具体配置项可以参考官方文档: http://nginx.org/en/docs/http... 。 用一个最简单的例子来测试一下该特性，例如下面是Spring Boot写了一个简单的HTTP接口，返回500状态码： @SpringBootApplicationpublic class NginxRetryApplication { public static void main(String[] args) { SpringApplication.run(NginxRetryApplication.class, args); }}@RestControllerclass TestController { @RequestMapping("/") public String test() { System.out.println("收到一个请求"); // 打印日志 throw new RuntimeException(); // 抛出异常, 返回500状态码 }}分别使用9030和9031两个端口号启动该Spring Boot服务，然后Nginx配置好负载均衡： upstream nginxretry { server 127.0.0.1:9030 max_fails=0; server 127.0.0.1:9031 max_fails=0;}server { listen 9039; location / { proxy_pass http://nginxretry; proxy_next_upstream error timeout http_500; }}注意：以上配置中max_fails=0是为了更方便的测试Nginx错误重试机制。max_fails默认值是1，用于指定一个server在一段时间内（默认10s）发生错误次数达到多少次，Nginx就会自动将该服务器下线。这里设置为0是禁用这个特性，防止在测试过程中服务器被踢下线不好测试。线上环境下一般不会设置max_fails=0。 配置完成后重启Nginx，使用GET方式请求 http://localhost:9039/ ，再分别查看9030和9031两个端口号对应的服务日志，可以发现两个服务都收到请求，也就是Nginx在访问其中一个服务收到500错误状态码后，又尝试去访问另一个服务。 ...

本文来自于我的慕课网手记：聊聊 Nginx 的反向代理，转载请保留链接 ;)背景最近在优化服务基础设施这块，正好有时间写一下Nginx的体会。相信大家都听说过反向代理，一提到反向代理一定会想到Nginx。什么你没听过Nginx？那么你一定听说过Apache吧！Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。Apache的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多优点：稳定、开源、跨平台等等。它出现的时间太长了，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。所以这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。什么是Nginx俄罗斯的工程师Igor Sysoev，他在为Rambler Media工作期间，使用C语言开发了Nginx。Nginx作为WEB服务器一直为Rambler Media提供出色而又稳定的服务。然后呢，Igor Sysoev将Nginx代码开源，并且赋予自由软件许可证。由于：Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器（这是个开源的时代啊~）Nginx是一个跨平台服务器，可以运行在Linux,Windows,FreeBSD,Solaris, AIX,Mac OS等操作系统上。可以作为反向代理进行负载均衡的实现，带来的极大的稳定性。Nginx这样做的目的主要是将数据的承载量分摊到多个服务器上进行执行，这只是在服务基础设施上提高性能的优化手段之一。从下面图就可以看出：什么是反向代理？看了网上很多篇文章，下面这段话是我个人觉得介绍的最清楚的。反向代理（Reverse Proxy）方式是指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器；并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。所以反向代理服务器是引用在服务端。决定哪台服务器提供服务。那么我就模拟了一个基本的反向代理和负载均衡配置实现，下面是我的操作步骤：反向代理的模拟首先创建多个 tomcat 服务器，我这里创建了三个：然后修改每个 tomcat 运行在不同的端口号上，每个 server.xml配置文件需要修改三处端口：分别在 8080，8081，8082 端口配置 8006，8081，8010 端口，分别进行启动测试，但是注意防火墙配置问题。测试结果如下：接着配置 nginx 的配置文件，进行反向代理：最后不断访问刚配置的 test.tomcats.com 域名，发现三台 tomcat 成功运行的页面都有出现，比例大致 1：1：1：恭喜你，配置成功了！配置负载均衡其实很简单，就是在刚刚配置的 nginx 文件中 的 upstream tomcats 中的 server 后面添加一个 weight, 即可代表权重。权重越高，分派请求的数量就越多。默认权重是 1。

花了 3 天时间，趁着我还没有忘记，先记录下来效果目前有 2 个项目（project1, project2），还有一个 nginx 自带的 index.html，我添加了对应的链接代码（稍后粘贴出来），为了统一管理子项目的路由。我期望实现下面的效果（假设 ip: localhost，port: 8080）：http://localhost:8080/ 进入最外层的 index.htmlhttp://localhost:8080/project1 进入项目一http://localhost:8080/project2 进入项目二废话不多说，开始配置Vue 的配置本人使用的是 vue-cli2 搭建的项目，所以对应的需要修改一些 vue 的配置参数。config 文件夹下的 index.js，因为是打包，所以我们需要在 build.assetsPublicPath 更改对应项目名，譬如// project1module.exports = { dev: {}, build: { assetsPublicPath: ‘/project1/’ // 注意前后的 ‘/’ }}// project2module.exports = { dev: {}, build: { assetsPublicPath: ‘/project2/’ // 注意前后的 ‘/’ }}config 文件夹下的 prod.env.js 修改成这样：// project1module.exports = { NODE_ENV: ‘“production”’, BASE_API: ‘"/api/pro1"’ // 这里待会与 nginx 配置对应}// project2module.exports = { NODE_ENV: ‘“production”’, BASE_API: ‘"/api/pro2"’ // 这里待会与 nginx 配置对应}[注意] 因为我在项目中使用到了 BASE_API 作为代理的前缀，如果你的不在这边，你需要找到你自己的代理配置因为每个人的 vue-router 文件配置不一样，你需要找到你的 router 配置文件，内部修改为：// 我采用了 history 模式，hash 模式我没有测试，感觉应该是一样的效果// project1export default new Router({ base: ‘/project1/’, // 注意更改你子项目名，这个对应你的 build.assetsPublicPath mode: ‘history’, scrollBehavior: () => ({ y: 0 }), routes: []})// project2export default new Router({ base: ‘/project2/’, // 注意更改你子项目名，这个对应你的 build.assetsPublicPath mode: ‘history’, scrollBehavior: () => ({ y: 0 }), routes: []})[注意] 在 npm run build 可能会报错：.tap(*) 之类的，那是因为打包中的 html-webpack-plugin 版本出现了问题，可以执行下面的语句# 这个版本就是你的 package.json 中的版本，只不过你需要重新再指定这个版本$ npm i html-webpack-plugin@4.0.0-alpha -DNginx 的配置首先我的目录是这样的，无关文件全部以 … 展示.├─conf│ ├─… # 其他文件│ └─nginx.conf│├─html # 只看这里，其他暂时我没用到 │ ├─project1│ │ └─static│ │ ├─css│ │ ├─fonts│ │ └─js│ │ ├─g│ │ └─V│ ├─project2│ │ └─static│ │ ├─css│ │ ├─fonts│ │ └─js│ │ ├─g│ │ └─V│ ├─index.html│ └─50x.html└─… # 其他文件[解释] 我的 nginx 目录就是原生的，内部包含了一个 html 文件夹，为了省事，我直接使用这个，当然你也可以指定其他的目录，但是目前还请和我一样的配置，后面可以自己定制化。现在我们开始配置在 conf 文件夹下的 nginx.conf 文件我是直接在原始文件上修改的，而修改的配置都是在 http 模块中，所以其他的不需要的代码我直接用 … 代替。# …# 反向代理http { include mime.types; default_type application/octet-stream; #log_format main ‘$remote_addr - $remote_user [$time_local] “$request” ’ # ‘$status $body_bytes_sent “$http_referer” ’ # ‘"$http_user_agent" “$http_x_forwarded_for”’; sendfile on; keepalive_timeout 65; client_max_body_size 20M; client_body_buffer_size 10M; large_client_header_buffers 4 128k; # 这里可以做集群 upstream p1_server { server localhost:8081; } # 这里可以做集群 upstream p2_server { server localhost:8082; } server { listen 8080; server_name localhost; charset utf-8; proxy_connect_timeout 180; proxy_send_timeout 180; proxy_read_timeout 180; proxy_set_header Host $host; proxy_set_header X-Forwarder-For $remote_addr; root html; # 这里指定刚刚我们的文件夹 # 总的项目路由，我偷懒直接写在了同一个文件 # 如果有很多可以在配置多个 conf 文件，使用 include 关联进来 location / { try_files $uri $uri/ /index.html; # 这里可以理解指定到 html 文件夹下的 index.html } # project1 # 这里就是刚刚我们在 vue 项目中 config/index.js 的配置 build.assetsPublicPath， # 也是 vue 项目中配置的 router 中的 base location ^~ /project1 { try_files $uri $uri/ /project1/index.html; # 这里可以理解指定到 html 文件夹下 project1 文件夹 的 index.html } # project2 # 这里是项目二的配置 location ^~ /project2 { # try_files $uri $uri/ /project2/index.html; # 这里可以理解指定到 html 文件夹下 project2 文件夹 的 index.html } # 这里是 project1 配置需要调用的接口 location /api/pro1 { # 这里就是在 vue 项目中 prod.env.js 的配置 BASE_API proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://p1_server; # 此处的 p1_server 对应的上面的配置 upstream p1_server {}，这里可以做集群，我用不到，就简单配置了 } # 这里是 project1 配置需要调用的接口 location /api/pro2 { # 这里就是在 vue 项目中 prod.env.js 的配置 BASE_API proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://p2_server; # 此处的 p2_server 对应的上面的配置 upstream p2_server {}，这里可以做集群，我用不到，就简单配置了 } # … } # …}最后贴出我修改的 index.html 的代码因为我是追加的，所以直接贴出我追加的代码，其他的采用 ……<p><em>Thank you for using nginx.</em></p> <!– 为了展示位置 –><!– start: 追加–><hr><a href="/project1">项目一</a> | <a href="/project2">项目二</a><!– end: 追加–></body> <!– 为了展示位置 –>最后的调试所有的配置完成，我们就可以启动 nginx 了，这个不会的请自行解决了。启动成功，我们在浏览器输入 http://localhost:8080 我们就可以看到，点击项目一，我们可以看到链接变为 http://localhost:8080/project1点击项目二，链接变为 http://localhost:8080/project2，完全符合我们的期望，那就成功了。[强行解释一下玄学] 那天配置好了，一启动就报错，弄的我最后放弃了。但是第二天，准备在检查下，一启动竟然全好了，我都一脸懵逼啊！ 如果你也遇到和我一样的问题，先放放，说不定隔天就好了。 ...