尧图网页设计 
这篇不是科普文是我自己最近在项目里折腾nginx给nacos做反向代理的记录。之前有人在群里问“nginx配置nacos返向代理”怎么写还有人把“反向代理”打成“返向代理”我觉得这词儿其实也挺形象的——请求在外面绕一圈再返回到nacos就是“返向”了嘛。玩笑归玩笑这个需求在真实环境里出现得特别频繁尤其是你部署了nacos注册中心、配置中心以后不可能让它裸奔在公网或者让每个客户端直接改hosts去访问内网节点这时候就需要nginx在中间做一层统一入口。我这次把单机版、集群版、HTTPS终止、还有那些踩过的坑全部梳理了一遍代码都是直接能抄的抄完按你的实际IP和域名替换就能用。适合刚接触nacos和nginx的读者也适合已经在用但被各种诡异问题卡住的老哥。1. 为什么需要给nacos做反向代理1.1 先说说我遇到的实际场景我这边的情况是nacos以集群方式部署在三台内网服务器上默认端口8848控制台和客户端请求都得走这个端口。一开始开发环境无所谓都是内网IP直连可一旦到了测试环境、预发环境问题就来了——前端和外部系统根本不知道这三台机器的真实地址也不应该让它们知道。你不可能在每台业务服务器上写死多个nacos地址更不可能让外部系统直接访问内部机器。所以最省事、最合理的方案就是nginx放在前面对外只暴露一个地址负载均衡到后面的三台nacos节点。另一个更常见的场景是安全合规。nacos控制台自带权限认证但在很多公司流程里直接把8848端口映射到公网或者办公网是大忌审计过不去。nginx在前面做四层或七层代理配合IP白名单、限流、HTTPS卸载能挡掉一大半的风险。运维同学找你要端口开放清单的时候你也只需要申请一个443或者80端口成本低很多。1.2 反向代理到底解决了什么问题如果只用一句话总结那就是把多个后端节点聚合成一个稳定对外入口同时把协议、端口、路径这些细节全部封装在nginx这一层。具体拆开有几个比较实际的价值统一访问入口和域名绑定。客户端只需要知道一个域名比如nacos.example.internalnginx根据这个域名把请求分到对应后端的nacos节点。后端怎么扩容、怎么下线客户端完全无感。负载均衡。nacos集群模式下多节点之前本身有Nacos-Sync或者自身集群同步但客户端不能只连其中一个节点否则单点故障直接就挂。nginx用upstream可以配置轮询、最小连接数、IP哈希等策略把请求均匀分摊到每个nacos节点。SSL终止。如果公司要求所有链路加密传统做法是每个nacos节点都得配证书维护成本翻三倍。nginx统一卸载HTTPS后端继续走内网HTTP证书只在nginx上管一份省心太多了。安全隔离。nginx层可以做allow/deny、做access_log、做请求体大小限制这些都是nacos自带的Tomcat容器不太方便做的事情。比如某些不需要暴露给外部的接口直接在nginx层直接拦掉比去nacos源码里改逻辑优雅得多。2. 动手前需要确认的事2.1 理清你的nacos部署方式是单机还是集群有的朋友配置半天连不上不是nginx写错了而是压根没搞清楚nacos到底是怎么部署的。单机和集群的nginx配置差别很大。单机nacos比如你在一台机器上解压了nacos-server-2.2.3.tar.gz默认就是8848端口那nginx里只需要一个server块、一个location块就够了。集群nacos比如用了三台机器部署了集群模式或者用了Rancher/K8s部署每台nacos都暴露了不同端口那nginx里就要写upstream做负载均衡而且要考虑nacos 2.x的gRPC长连接端口偏移问题这个后面细说。一定要先搞清楚一件事nacos的版本。1.x和2.x在客户端通信方式上差别巨大。nacos 2.x默认开启了gRPC通信客户端不仅连8848还会连88481000的gRPC端口也就是9848。如果你只代理了8848客户端会出现“注册成功但过一会儿就掉线”的诡异现象因为gRPC长连接端口不通。这一点我吃过亏后文会专门说。2.2 检查nginx的安装情况和关键模块确认nginx已经装好并且带上了stream模块如果是四层代理和http_sub之类的常用模块。绝大多数发行版编译的nginx都自带--with-stream你可以用下面命令确认nginx -V 21 | grep stream如果输出里有--with-stream说明四层转发能力没问题。如果一个nginx要同时承担多个web项目这是热词里经常出现的“nginx部署多个web项目”建议把nacos代理单独写一个/etc/nginx/conf.d/nacos.conf文件不要一股脑全塞进主配置文件里后面维护会想哭。还有一个细节nacos的context path默认是/nacos控制台地址是http://ip:8848/nacos/。这个路径在nginx配置里非常重要因为你要保证nginx对外路径和后端路径能正确衔接特别是proxy_pass后面要不要带/nacos/这直接影响到404问题我在第三节详细拆解。2.3 建议先在本机用curl验证nacos可用性在动nginx之前先通一通后端服务这是基本功。我在服务器上执行curl http://127.0.0.1:8848/nacos/v1/console/health/readiness如果返回{status:UP}说明nacos本体健康。如果连本机都访问不了先排查nacos侧问题别急着折腾nginx否则你根本分不清故障出在哪一层。这个习惯帮我省下了大量排查时间强烈建议你养成。3. nginx反向代理nacos的核心配置3.1 单实例nacos的最小可用配置如果你是单机nacos只需要一个最简配置。这里假设你的nginx对外域名是nacos.example.comnacos监听内网192.168.1.10:8848。直接新建/etc/nginx/conf.d/nacos.confupstream nacos_server { server 192.168.1.10:8848; } server { listen 80; server_name nacos.example.com; client_max_body_size 50m; location /nacos/ { proxy_pass http://nacos_server/nacos/; 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_set_header X-Forwarded-Proto $scheme; } location / { return 404; } }这个配置看起来简单但有几个必须注意的点proxy_pass http://nacos_server/nacos/;这一行upstream名字后面加了/nacos/这代表把原始请求的URI前缀替换掉。什么意思呢客户端请求http://nacos.example.com/nacos/v1/console/health/readinessnginx到了upstream这一层时实际转发给nacos的就是http://192.168.1.10:8848/nacos/v1/console/health/readiness路径保持完整。如果你在proxy_pass里写成http://nacos_server;而没有带/nacos/那么nginx会把原始的完整URI直接拼到后端变成http://192.168.1.10:8848/nacos/v1/...其实也一样。关键看你的location匹配粒度。但也有一个经典坑location /nacos/与proxy_pass http://upstream/nacos/是绝配而location /nacos不加末尾斜杠时行为会不一样。location /nacos能同时匹配/nacosabc这会导致不该被代理到nacos的路径也被转发。稳妥做法是location和proxy_pass两边都统一带/语义清晰也避免别人接手时产生歧义。client_max_body_size 50m;是为了防止配置中心的大配置内容、或者上传配置时body超限。nacos默认Tomcat对POST大小限制比较小nginx默认是1m如果你通过控制台直接粘贴大段配置很容易出现413 Request Entity Too Large这个我后面在问题表里也会提到。3.2 集群场景下的负载均衡和gRPC支持如果你有三台nacos节点那么upstream里写三个地址这就够了。但要注意nginx的upstream默认是轮询这没问题nacos节点之间是有数据同步的客户端无论打到哪个节点都能读到配置。不过nacos 1.x的鉴权和配置推送机制以及2.x的gRPC长连接都要求会话尽量固定在同一个节点否则可能出现“客户端上线后反复重新注册”的现象。解决办法很简单给upstream加ip_hash或hash指令。我这边使用的是upstream nacos_cluster { ip_hash; server 192.168.1.10:8848 max_fails2 fail_timeout30s; server 192.168.1.11:8848 max_fails2 fail_timeout30s; server 192.168.1.12:8848 max_fails2 fail_timeout30s; keepalive 32; } server { listen 80; server_name nacos.example.com; client_max_body_size 50m; location /nacos/ { proxy_pass http://nacos_cluster/nacos/; proxy_http_version 1.1; proxy_set_header Connection ; 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_set_header X-Forwarded-Proto $scheme; } }ip_hash之后同一个客户端IP总是被路由到同一台nacos节点gRPC长连接不会频繁迁移体验稳定得多。你可能会担心ip_hash造成某台节点压力大这在nacos场景下问题不大因为nacos集群本身就是多副本配置和服务的读写都需要内部一致单台节点压力不是瓶颈稳定才是第一位的。还有一点非常重要2.x客户端用的gRPC端口是主端口1000。也就是说8848的gRPC端口是9848。如果你用nginx七层代理做location /nacos/只代理了8848的HTTP请求但gRPC长连接绕过nginx直连节点会有两个问题一是防火墙只放行了nginx地址gRPC端口不通服务频繁掉线二是你压根没法和“注册中心地址填nginx域名”这个需求兼容因为gRPC需要的服务发现IP默认是注册时客户端看到的地址而客户端看到的可能是nginx的IP但9848端口不通。简化处理方式有两种第一用nginx的stream模块做四层转发直接把8848和9848端口都代理了。stream { upstream nacos_http { server 192.168.1.10:8848; server 192.168.1.11:8848; server 192.168.1.12:8848; } upstream nacos_grpc { server 192.168.1.10:9848; server 192.168.1.11:9848; server 192.168.1.12:9848; } server { listen 8848; proxy_pass nacos_http; } server { listen 9848; proxy_pass nacos_grpc; } }这种方式优点是简单粗暴客户端完全无感也不用管路径匹配。但你想在nginx层做域名分发、做HTTPS终止就做不了了只能做端口转发。第二继续用七层HTTP代理但在nacos端关闭gRPC或者保证客户端能直通9848端口。nacos 2.x有参数nacos.server.grpc.port.offset默认是1000。你可以在application.properties里显式调整偏移。但我不建议关闭gRPC因为2.x的很多特性依赖它关了等于把版本退回1.x的体验。最稳妥的做法是如果网络环境里9848端口无法打通那就用stream四层方案把8848和9848都代理到nginx客户端只认nginx的IP和端口。3.3 HTTPS终止与SSL配置公司内部如果强制要求加密或者你要把这个地址映射出去给外部系统访问那么直接在nginx上做HTTPS后面nacos保持HTTP就够了。证书可以用自签名也可以用内部CA签发的证书。如果你只是内网测试自签名证书完全够用但要注意客户端JVM是否信任这个CA否则Java程序调用nacos会报SSL握手失败。一个典型的HTTPS配置server { listen 443 ssl http2; server_name nacos.example.com; ssl_certificate /etc/nginx/certs/nacos.example.com.crt; ssl_certificate_key /etc/nginx/certs/nacos.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; access_log /var/log/nginx/nacos_access.log; error_log /var/log/nginx/nacos_error.log; location /nacos/ { proxy_pass http://nacos_cluster/nacos/; proxy_http_version 1.1; proxy_set_header Connection ; 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_set_header X-Forwarded-Proto $scheme; } }这里有个小坑proxy_set_header Host $host;这行如果你把Host改成$proxy_host后端收到的Host就会变成192.168.1.10:8848nacos控制台里“当前集群节点”的连接地址就会显示成内网IP跳转的时候可能跳到内网地址导致浏览器访问不了。所以一定用$host保持域名透传。另一个HTTPS坑是重定向。nacos某些接口会返回302重定向Location头里是http://还是https://取决于后端拿到的协议。因为nginx做了SSL终止后端看到的是HTTP所以Location头可能生成http://nacos.example.com/...浏览器会自动跳到80端口造成死循环。解决方式是在nginx里加上proxy_redirect http:// https://;或者精确一点proxy_redirect http://nacos.example.com/ https://nacos.example.com/;这个我遇到过当时控制台死活打不开报“重定向次数过多”查日志发现全是302就是这个原因。加了proxy_redirect立刻就好了。4. 核心机制代理过程中必须搞懂的细节4.1 proxy_pass结尾斜杠的一字之差这个细节我单独拿一节来讲因为太多人在这里翻车。location /nacos/和proxy_pass http://nacos_cluster/nacos/这两端末尾斜杠的有无直接决定路径拼接结果proxy_pass http://nacos_cluster;不带斜杠没有URI路径nginx会将原始URI完整传给后端适合location精确匹配或根路径代理。proxy_pass http://nacos_cluster/;带斜杠且URI为空nginx会把location匹配部分替换为/比如请求/nacos/v1/console会被变成/v1/console前后缀对不上直接404。proxy_pass http://nacos_cluster/nacos/;带路径nginx会把location匹配部分替换为/nacos/请求/nacos/v1/console还是/nacos/v1/console这才是你要的。用生活类比来说这就像是快递转寄地址栏上写“杭州市”和“杭州市/西湖区”快递员拆包裹后重新打包的方式完全不同。你如果不确认对方收件地址到底接受不带前缀还是带前缀的格式就会出现包裹发出去但对方拒收——对应到HTTP就是404或502。我建议的策略是location带斜杠proxy_pass也完整复制后端路径形成一一对应关系。这样最直观后来接手的同事也不容易误解。4.2 长连接、超时与会话保持nacos客户端和配置中心之间有很多依赖长连接的场景配置变更监听、服务实例心跳、gRPC流式通信。nginx默认的proxy_read_timeout是60秒如果后端在这段时间内没有返回任何数据nginx会直接断开连接。nacos的配置监听长轮询通常设计成30秒左右能拿到响应但如果你的网络稍慢或者nacos节点恰好卡顿超过60秒没有数据返回nginx就会切断连接。客户端重新连接时如果恰逢注册中心正在做数据同步就可能报错。稳妥的做法是适当调大超时时间proxy_connect_timeout 10s; proxy_read_timeout 300s; proxy_send_timeout 300s;我这里把proxy_read_timeout调到300秒是为gRPC长连接留足了余量。如果只是做控制台反向代理不涉及客户端长连接60秒默认值问题不大但如果你有大量微服务通过nginx访问nacos建议按这个配置来。另外如果nginx和nacos之间走HTTP/1.0每次请求都要新建TCP连接对高并发场景不友好。我在集群配置里写proxy_http_version 1.1;和proxy_set_header Connection ;就是让nginx与后端之间启用keepalive减少握手开销。配合upstream里的keepalive 32连接复用效果很明显。4.3 服务注册地址、回源地址的IP/域名问题这是nacos代理里最容易引发玄学故障的点。微服务客户端通过nginx注册到nacos时nacos保存的服务实例IP是客户端进程中配置的spring.cloud.nacos.discovery.ip还是客户端实际握手时的源IP取决于nacos的识别方式。默认情况下nacos识别的是客户端的socket源IP。如果客户端也通过nginx去注册那么nginx的IP会成为源IP注册到nacos上的服务地址就变成nginx的IP。如果nginx和微服务在同一台机器或者同一内网可能还能通但如果你配置了nginx代理客户端的所有请求到nacos那么注册到nacos上的服务地址全部是nginx的IP别的服务调用时就会去连nginx而不是连实际提供服务的实例结果就是调用失败或端口不对。这个问题在“客户端通过nginx访问nacos”时特别明显。解决办法通常是在客户端明确指定注册IP。Spring Cloud Alibaba的配置里加上spring.cloud.nacos.discovery.ip实际内网IP spring.cloud.nacos.discovery.port实际服务端口这样nacos注册表里保存的就是服务真实地址不走nginx转发。也可以配置spring.cloud.nacos.discovery.net-interface指定网卡自动获取IP。另外X-Forwarded-For和X-Real-IP这些header主要用于控制台显示客户端真实来源、以及权限日志审计不能用于修正注册中心的实例地址。这个机制要清楚别在错误的地方解决问题。4.4 健康检查与故障转移nginx upstream自带的被动健康检查max_fails和fail_timeout只对“转发时出现连接失败或超时”的请求生效如果nacos服务保持在但端口异常或者返回500nginx默认不会把它摘掉。生产环境要求高的话建议配合nginx的主动健康检查模块或者每台nacos上自己挂一个监控脚本检测到异常直接修改nginx upstream配置文件并reload。我在配置里写了max_fails2 fail_timeout30s意思是30秒内最多失败2次就把该节点标记为不可用不再转发流量。但对nacos这种需要长连接的服务被动健康检查并不完美因为很多故障是“连接建立了但响应变慢”而不是“连接失败”。如果条件允许用nginx商业版的health_check或者开源模块nginx-upsync配合consul做动态后端发现体验会好很多。不过对大多数中小团队被动检查加Cloud Alert已经足够用。5. 常见问题排查实录5.1 先放一个速查表我在排查过程中遇到的问题都整理到了表里按“症状—原因—解法”来描述方便你直接对号入座。症状可能原因解决方案浏览器访问nginx域名返回404proxy_pass路径拼接不对或location匹配到了别的块检查proxy_pass是否完整带/nacos/location和proxy_pass末尾斜杠保持一致控制台能打开但服务注册不上2.x的gRPC端口9848不通或注册地址变成nginx IP用stream代理8848和9848客户端显式指定discovery.ip页面一直302重定向nginx做SSL终止后Location头还是http加上proxy_redirect http:// https://;上传/拉取大配置时报413nginx默认client_max_body_size只有1m在server块里设置client_max_body_size 50m;配置变更后客户端没有及时刷新gRPC长连接被nginx断开客户端重连慢调大proxy_read_timeout启用upstream keepalive登录nacos控制台后跳转到内网IPHost头传递错误或nacos使用绝对地址拼接设置proxy_set_header Host $host;集群节点显示全部下线客户端与nacos之间的健康检查IP不通检查nacos节点IP配置确认注册地址能互通同时代理多个web项目时互相干扰多个server_name或location块混在一起每个项目独立conf文件用server_name区分CentOS Stream 9上nginx启动失败SELinux或依赖库缺失检查nginx -t、journalctl日志、确认libssl等依赖表格里的内容都是我真实遇到的只有一个“同时代理多个web项目”的问题是我帮同事排查的。他那台nginx上挂了三个项目其中nacos的location /nacos/写到了默认server里被其他项目的location /拦截了导致nacos控制台永远返回404。5.2 一次“控制台能打开但服务注册不上”的完整排查记录这个案例我印象最深因为我花了大半天才定位到问题。现象是通过nginx域名访问nacos控制台完全正常登录、配置列表、服务列表都能看到但新启动的微服务一直注册失败日志里报currentServerAddr: http://nacos.example.com, err: connect timed out。一开始我以为是nginx配置问题反复改了proxy_pass都没用。后来在微服务所在机器上手动测试curl http://nacos.example.com:80/nacos/v1/ns/instance/list?serviceNametest能正常返回。问题在于服务注册时nacos客户端不仅要发HTTP请求还要建立gRPC长连接而客户端的gRPC地址是自动拼接的它会把spring.cloud.nacos.server-addrnacos.example.com解析出主机名和端口80然后推断gRPC端口是8010001080。实际上nacos真实gRPC端口是9848而1080在nginx上根本没监听所以一直超时。找到原因后解决方案就很清晰了如果坚持七层HTTP代理就必须让nacos的gRPC端口也能通。最直接的办法是改nginx监听端口和nacos gRPC端口保持一致。既然nacos主端口是8848gRPC是9848我们直接让nginx在8848和9848上做四层stream转发问题彻底解决。微服务只认一个地址10.0.0.5:8848nginx把HTTP转发到后端的8848把gRPC转发到后端的9848。排查这类的通用思路是先抓住报错关键字比如connect timed out、Connection refused、No provider再逐层测试。我曾经把这些关键字整理成一个脚本批量检查端口连通性和HTTP响应。最常用的是nc -vz 10.0.0.5 9848和curl -v看握手过程基本能定位90%的网络问题。5.3 nginx日志里的线索怎么看遇到问题第一件事永远是看日志而不是瞎改配置。nginx的access log能看到请求进来了没有error log能看到upstream连接失败的具体原因。我比较习惯把nacos的请求单独写一个access log配置里加上access_log /var/log/nginx/nacos_access.log; error_log /var/log/nginx/nacos_error.log warn;排错的时候切到日志目录tail -f /var/log/nginx/nacos_access.log grep -i error /var/log/nginx/nacos_error.log比如你看到access log里有大量499状态码说明客户端主动断开了连接大概率是等待时间过长和proxy_read_timeout有关。如果看到502或504说明upstream对应的nacos节点连接不上或超时下一步就用curl直接访问那个节点确认它是否存活。记住一点nginx日志是第一手现场证据别在没有任何证据的情况下反复reload配置。reload本身不会造成大问题但你改来改去如果没有确定依据只会让问题更乱。6. 几个容易忽略的高级细节6.1 代理nacos open API时注意body大小和鉴权如果你在业务系统里直接通过HTTP调用nacos的open API比如发布配置、查询配置、触发服务心跳那么nginx的client_max_body_size和鉴权透传就会变得关键。nacos 2.2.0以后默认开启了鉴权open API需要在header里带Authorization: Bearer token或者用户名密码。如果通过nginx代理要确保请求头不被篡改Authorization默认是透传的问题不大。但如果你在nginx层加了proxy_set_header去覆盖一些不必要的头极有可能把Authorization也覆盖掉这时候调open API会一直返回403。另外发布大配置时如果client_max_body_size不够nginx直接返回413根本到不了nacos。我在配置里写50m是因为我们有一个包含大量数据源和路由规则的配置文件超过了默认的1m。你可以根据自己实际情况调整但别设太小也别无脑设成1g容易造成内存压力。6.2 日志、监控和告警的小建议nginx层启日志后最好用logrotate定期切割否则/var/log/nginx分区会被打满。可以用现成的logrotate配置也可以cron里加一行/usr/sbin/logrotate /etc/logrotate.d/nginx针对nacos的可用性监控最简单的做法是cron脚本每分钟curl一次登录页或健康检查接口*/1 * * * * curl -s -o /dev/null -w %{http_code} http://127.0.0.1:80/nacos/v1/console/health/readiness | grep -q 200如果返回不是200就触发告警。要注意的是健康检查接口响应可能不一定是200而是其他状态码用curl -s看返回内容更可靠。我这边是把检查结果写入Prometheus的自定义exportergrafana上挂了一个“nacos代理可用性”的仪表盘效果直观。6.3 优雅下线与摘流还有一个小技巧当nacos节点要做维护升级时直接在nginx upstream里把这个节点注释掉然后reload流量就不会再打过去了。但要注意reload会导致已有的gRPC长连接断开如果客户端重连逻辑不健壮可能造成短暂的服务注册抖动。所以尽量在业务低峰期操作且一次只摘一个节点等客户端全部重连稳定后再摘下一个。举一个实际例子。有一次我们要升级nacos集群的三台节点我把upstream里第一台注释掉reload观察日志等客户端陆续注册到另外两台再把这台的nacos进程停掉。整个过程大概花了5分钟服务无感知。如果一次性三台全部注释那nacos集群直接没有可用节点所有依赖配置中心的微服务都会启动失败或拉取配置超时这就是事故了。至于下线后的配置同步nacos集群节点之间会自动处理不用人工干预。只要保证同一时间至少有一台节点存活集群就能继续对外提供服务。7. 最后再分享一个小技巧做完nginx代理后可以用openssl或nginx的sub_filter给控制台页面加一些额外响应头比如X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN安全性会更好。虽然不是必需但在安全扫描的时候能少几个告警。nginx配置里加add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always;如果这台nginx只代理nacos加这些没问题。如果nginx还代理了其他web项目别全局加只加到nacos这个server块里否则某些第三方页面可能因为X-Frame-Options被拦而无法嵌入。还有个更实用的小技巧就是nginx里给nacos的/nacos/v1/ns/健康检查路径配置缓存。如果你有很多微服务频繁调用健康检查或心跳接口而这些接口对实时性要求没那么高可以用proxy_cache缓存几秒减少后端压力。但心跳接口不建议缓存因为nacos需要看到实时的心跳数据缓存可能导致误判实例下线。配置变更查询接口也不好缓存会破坏“动态刷新”的效果。能缓存的一般是服务列表查询这类只读接口实际收益有限所以不展开。根据我个人经验nginx配nacos并不难难点在于nacos 2.x的gRPC端口和注册IP这两个点很多配置看起来“通了”但其实只是控制台通了客户端压根没连上。只要把这两点想清楚其他都是常规操作。希望这篇记录能让你少走一点弯路。 Nginx反向代理Nacos实战：单机集群HTTPS与gRPC端口避坑指南
这篇不是科普文是我自己最近在项目里折腾nginx给nacos做反向代理的记录。之前有人在群里问“nginx配置nacos返向代理”怎么写还有人把“反向代理”打成“返向代理”我觉得这词儿其实也挺形象的——请求在外面绕一圈再返回到nacos就是“返向”了嘛。玩笑归玩笑这个需求在真实环境里出现得特别频繁尤其是你部署了nacos注册中心、配置中心以后不可能让它裸奔在公网或者让每个客户端直接改hosts去访问内网节点这时候就需要nginx在中间做一层统一入口。我这次把单机版、集群版、HTTPS终止、还有那些踩过的坑全部梳理了一遍代码都是直接能抄的抄完按你的实际IP和域名替换就能用。适合刚接触nacos和nginx的读者也适合已经在用但被各种诡异问题卡住的老哥。1. 为什么需要给nacos做反向代理1.1 先说说我遇到的实际场景我这边的情况是nacos以集群方式部署在三台内网服务器上默认端口8848控制台和客户端请求都得走这个端口。一开始开发环境无所谓都是内网IP直连可一旦到了测试环境、预发环境问题就来了——前端和外部系统根本不知道这三台机器的真实地址也不应该让它们知道。你不可能在每台业务服务器上写死多个nacos地址更不可能让外部系统直接访问内部机器。所以最省事、最合理的方案就是nginx放在前面对外只暴露一个地址负载均衡到后面的三台nacos节点。另一个更常见的场景是安全合规。nacos控制台自带权限认证但在很多公司流程里直接把8848端口映射到公网或者办公网是大忌审计过不去。nginx在前面做四层或七层代理配合IP白名单、限流、HTTPS卸载能挡掉一大半的风险。运维同学找你要端口开放清单的时候你也只需要申请一个443或者80端口成本低很多。1.2 反向代理到底解决了什么问题如果只用一句话总结那就是把多个后端节点聚合成一个稳定对外入口同时把协议、端口、路径这些细节全部封装在nginx这一层。具体拆开有几个比较实际的价值统一访问入口和域名绑定。客户端只需要知道一个域名比如nacos.example.internalnginx根据这个域名把请求分到对应后端的nacos节点。后端怎么扩容、怎么下线客户端完全无感。负载均衡。nacos集群模式下多节点之前本身有Nacos-Sync或者自身集群同步但客户端不能只连其中一个节点否则单点故障直接就挂。nginx用upstream可以配置轮询、最小连接数、IP哈希等策略把请求均匀分摊到每个nacos节点。SSL终止。如果公司要求所有链路加密传统做法是每个nacos节点都得配证书维护成本翻三倍。nginx统一卸载HTTPS后端继续走内网HTTP证书只在nginx上管一份省心太多了。安全隔离。nginx层可以做allow/deny、做access_log、做请求体大小限制这些都是nacos自带的Tomcat容器不太方便做的事情。比如某些不需要暴露给外部的接口直接在nginx层直接拦掉比去nacos源码里改逻辑优雅得多。2. 动手前需要确认的事2.1 理清你的nacos部署方式是单机还是集群有的朋友配置半天连不上不是nginx写错了而是压根没搞清楚nacos到底是怎么部署的。单机和集群的nginx配置差别很大。单机nacos比如你在一台机器上解压了nacos-server-2.2.3.tar.gz默认就是8848端口那nginx里只需要一个server块、一个location块就够了。集群nacos比如用了三台机器部署了集群模式或者用了Rancher/K8s部署每台nacos都暴露了不同端口那nginx里就要写upstream做负载均衡而且要考虑nacos 2.x的gRPC长连接端口偏移问题这个后面细说。一定要先搞清楚一件事nacos的版本。1.x和2.x在客户端通信方式上差别巨大。nacos 2.x默认开启了gRPC通信客户端不仅连8848还会连88481000的gRPC端口也就是9848。如果你只代理了8848客户端会出现“注册成功但过一会儿就掉线”的诡异现象因为gRPC长连接端口不通。这一点我吃过亏后文会专门说。2.2 检查nginx的安装情况和关键模块确认nginx已经装好并且带上了stream模块如果是四层代理和http_sub之类的常用模块。绝大多数发行版编译的nginx都自带--with-stream你可以用下面命令确认nginx -V 21 | grep stream如果输出里有--with-stream说明四层转发能力没问题。如果一个nginx要同时承担多个web项目这是热词里经常出现的“nginx部署多个web项目”建议把nacos代理单独写一个/etc/nginx/conf.d/nacos.conf文件不要一股脑全塞进主配置文件里后面维护会想哭。还有一个细节nacos的context path默认是/nacos控制台地址是http://ip:8848/nacos/。这个路径在nginx配置里非常重要因为你要保证nginx对外路径和后端路径能正确衔接特别是proxy_pass后面要不要带/nacos/这直接影响到404问题我在第三节详细拆解。2.3 建议先在本机用curl验证nacos可用性在动nginx之前先通一通后端服务这是基本功。我在服务器上执行curl http://127.0.0.1:8848/nacos/v1/console/health/readiness如果返回{status:UP}说明nacos本体健康。如果连本机都访问不了先排查nacos侧问题别急着折腾nginx否则你根本分不清故障出在哪一层。这个习惯帮我省下了大量排查时间强烈建议你养成。3. nginx反向代理nacos的核心配置3.1 单实例nacos的最小可用配置如果你是单机nacos只需要一个最简配置。这里假设你的nginx对外域名是nacos.example.comnacos监听内网192.168.1.10:8848。直接新建/etc/nginx/conf.d/nacos.confupstream nacos_server { server 192.168.1.10:8848; } server { listen 80; server_name nacos.example.com; client_max_body_size 50m; location /nacos/ { proxy_pass http://nacos_server/nacos/; 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_set_header X-Forwarded-Proto $scheme; } location / { return 404; } }这个配置看起来简单但有几个必须注意的点proxy_pass http://nacos_server/nacos/;这一行upstream名字后面加了/nacos/这代表把原始请求的URI前缀替换掉。什么意思呢客户端请求http://nacos.example.com/nacos/v1/console/health/readinessnginx到了upstream这一层时实际转发给nacos的就是http://192.168.1.10:8848/nacos/v1/console/health/readiness路径保持完整。如果你在proxy_pass里写成http://nacos_server;而没有带/nacos/那么nginx会把原始的完整URI直接拼到后端变成http://192.168.1.10:8848/nacos/v1/...其实也一样。关键看你的location匹配粒度。但也有一个经典坑location /nacos/与proxy_pass http://upstream/nacos/是绝配而location /nacos不加末尾斜杠时行为会不一样。location /nacos能同时匹配/nacosabc这会导致不该被代理到nacos的路径也被转发。稳妥做法是location和proxy_pass两边都统一带/语义清晰也避免别人接手时产生歧义。client_max_body_size 50m;是为了防止配置中心的大配置内容、或者上传配置时body超限。nacos默认Tomcat对POST大小限制比较小nginx默认是1m如果你通过控制台直接粘贴大段配置很容易出现413 Request Entity Too Large这个我后面在问题表里也会提到。3.2 集群场景下的负载均衡和gRPC支持如果你有三台nacos节点那么upstream里写三个地址这就够了。但要注意nginx的upstream默认是轮询这没问题nacos节点之间是有数据同步的客户端无论打到哪个节点都能读到配置。不过nacos 1.x的鉴权和配置推送机制以及2.x的gRPC长连接都要求会话尽量固定在同一个节点否则可能出现“客户端上线后反复重新注册”的现象。解决办法很简单给upstream加ip_hash或hash指令。我这边使用的是upstream nacos_cluster { ip_hash; server 192.168.1.10:8848 max_fails2 fail_timeout30s; server 192.168.1.11:8848 max_fails2 fail_timeout30s; server 192.168.1.12:8848 max_fails2 fail_timeout30s; keepalive 32; } server { listen 80; server_name nacos.example.com; client_max_body_size 50m; location /nacos/ { proxy_pass http://nacos_cluster/nacos/; proxy_http_version 1.1; proxy_set_header Connection ; 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_set_header X-Forwarded-Proto $scheme; } }ip_hash之后同一个客户端IP总是被路由到同一台nacos节点gRPC长连接不会频繁迁移体验稳定得多。你可能会担心ip_hash造成某台节点压力大这在nacos场景下问题不大因为nacos集群本身就是多副本配置和服务的读写都需要内部一致单台节点压力不是瓶颈稳定才是第一位的。还有一点非常重要2.x客户端用的gRPC端口是主端口1000。也就是说8848的gRPC端口是9848。如果你用nginx七层代理做location /nacos/只代理了8848的HTTP请求但gRPC长连接绕过nginx直连节点会有两个问题一是防火墙只放行了nginx地址gRPC端口不通服务频繁掉线二是你压根没法和“注册中心地址填nginx域名”这个需求兼容因为gRPC需要的服务发现IP默认是注册时客户端看到的地址而客户端看到的可能是nginx的IP但9848端口不通。简化处理方式有两种第一用nginx的stream模块做四层转发直接把8848和9848端口都代理了。stream { upstream nacos_http { server 192.168.1.10:8848; server 192.168.1.11:8848; server 192.168.1.12:8848; } upstream nacos_grpc { server 192.168.1.10:9848; server 192.168.1.11:9848; server 192.168.1.12:9848; } server { listen 8848; proxy_pass nacos_http; } server { listen 9848; proxy_pass nacos_grpc; } }这种方式优点是简单粗暴客户端完全无感也不用管路径匹配。但你想在nginx层做域名分发、做HTTPS终止就做不了了只能做端口转发。第二继续用七层HTTP代理但在nacos端关闭gRPC或者保证客户端能直通9848端口。nacos 2.x有参数nacos.server.grpc.port.offset默认是1000。你可以在application.properties里显式调整偏移。但我不建议关闭gRPC因为2.x的很多特性依赖它关了等于把版本退回1.x的体验。最稳妥的做法是如果网络环境里9848端口无法打通那就用stream四层方案把8848和9848都代理到nginx客户端只认nginx的IP和端口。3.3 HTTPS终止与SSL配置公司内部如果强制要求加密或者你要把这个地址映射出去给外部系统访问那么直接在nginx上做HTTPS后面nacos保持HTTP就够了。证书可以用自签名也可以用内部CA签发的证书。如果你只是内网测试自签名证书完全够用但要注意客户端JVM是否信任这个CA否则Java程序调用nacos会报SSL握手失败。一个典型的HTTPS配置server { listen 443 ssl http2; server_name nacos.example.com; ssl_certificate /etc/nginx/certs/nacos.example.com.crt; ssl_certificate_key /etc/nginx/certs/nacos.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; access_log /var/log/nginx/nacos_access.log; error_log /var/log/nginx/nacos_error.log; location /nacos/ { proxy_pass http://nacos_cluster/nacos/; proxy_http_version 1.1; proxy_set_header Connection ; 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_set_header X-Forwarded-Proto $scheme; } }这里有个小坑proxy_set_header Host $host;这行如果你把Host改成$proxy_host后端收到的Host就会变成192.168.1.10:8848nacos控制台里“当前集群节点”的连接地址就会显示成内网IP跳转的时候可能跳到内网地址导致浏览器访问不了。所以一定用$host保持域名透传。另一个HTTPS坑是重定向。nacos某些接口会返回302重定向Location头里是http://还是https://取决于后端拿到的协议。因为nginx做了SSL终止后端看到的是HTTP所以Location头可能生成http://nacos.example.com/...浏览器会自动跳到80端口造成死循环。解决方式是在nginx里加上proxy_redirect http:// https://;或者精确一点proxy_redirect http://nacos.example.com/ https://nacos.example.com/;这个我遇到过当时控制台死活打不开报“重定向次数过多”查日志发现全是302就是这个原因。加了proxy_redirect立刻就好了。4. 核心机制代理过程中必须搞懂的细节4.1 proxy_pass结尾斜杠的一字之差这个细节我单独拿一节来讲因为太多人在这里翻车。location /nacos/和proxy_pass http://nacos_cluster/nacos/这两端末尾斜杠的有无直接决定路径拼接结果proxy_pass http://nacos_cluster;不带斜杠没有URI路径nginx会将原始URI完整传给后端适合location精确匹配或根路径代理。proxy_pass http://nacos_cluster/;带斜杠且URI为空nginx会把location匹配部分替换为/比如请求/nacos/v1/console会被变成/v1/console前后缀对不上直接404。proxy_pass http://nacos_cluster/nacos/;带路径nginx会把location匹配部分替换为/nacos/请求/nacos/v1/console还是/nacos/v1/console这才是你要的。用生活类比来说这就像是快递转寄地址栏上写“杭州市”和“杭州市/西湖区”快递员拆包裹后重新打包的方式完全不同。你如果不确认对方收件地址到底接受不带前缀还是带前缀的格式就会出现包裹发出去但对方拒收——对应到HTTP就是404或502。我建议的策略是location带斜杠proxy_pass也完整复制后端路径形成一一对应关系。这样最直观后来接手的同事也不容易误解。4.2 长连接、超时与会话保持nacos客户端和配置中心之间有很多依赖长连接的场景配置变更监听、服务实例心跳、gRPC流式通信。nginx默认的proxy_read_timeout是60秒如果后端在这段时间内没有返回任何数据nginx会直接断开连接。nacos的配置监听长轮询通常设计成30秒左右能拿到响应但如果你的网络稍慢或者nacos节点恰好卡顿超过60秒没有数据返回nginx就会切断连接。客户端重新连接时如果恰逢注册中心正在做数据同步就可能报错。稳妥的做法是适当调大超时时间proxy_connect_timeout 10s; proxy_read_timeout 300s; proxy_send_timeout 300s;我这里把proxy_read_timeout调到300秒是为gRPC长连接留足了余量。如果只是做控制台反向代理不涉及客户端长连接60秒默认值问题不大但如果你有大量微服务通过nginx访问nacos建议按这个配置来。另外如果nginx和nacos之间走HTTP/1.0每次请求都要新建TCP连接对高并发场景不友好。我在集群配置里写proxy_http_version 1.1;和proxy_set_header Connection ;就是让nginx与后端之间启用keepalive减少握手开销。配合upstream里的keepalive 32连接复用效果很明显。4.3 服务注册地址、回源地址的IP/域名问题这是nacos代理里最容易引发玄学故障的点。微服务客户端通过nginx注册到nacos时nacos保存的服务实例IP是客户端进程中配置的spring.cloud.nacos.discovery.ip还是客户端实际握手时的源IP取决于nacos的识别方式。默认情况下nacos识别的是客户端的socket源IP。如果客户端也通过nginx去注册那么nginx的IP会成为源IP注册到nacos上的服务地址就变成nginx的IP。如果nginx和微服务在同一台机器或者同一内网可能还能通但如果你配置了nginx代理客户端的所有请求到nacos那么注册到nacos上的服务地址全部是nginx的IP别的服务调用时就会去连nginx而不是连实际提供服务的实例结果就是调用失败或端口不对。这个问题在“客户端通过nginx访问nacos”时特别明显。解决办法通常是在客户端明确指定注册IP。Spring Cloud Alibaba的配置里加上spring.cloud.nacos.discovery.ip实际内网IP spring.cloud.nacos.discovery.port实际服务端口这样nacos注册表里保存的就是服务真实地址不走nginx转发。也可以配置spring.cloud.nacos.discovery.net-interface指定网卡自动获取IP。另外X-Forwarded-For和X-Real-IP这些header主要用于控制台显示客户端真实来源、以及权限日志审计不能用于修正注册中心的实例地址。这个机制要清楚别在错误的地方解决问题。4.4 健康检查与故障转移nginx upstream自带的被动健康检查max_fails和fail_timeout只对“转发时出现连接失败或超时”的请求生效如果nacos服务保持在但端口异常或者返回500nginx默认不会把它摘掉。生产环境要求高的话建议配合nginx的主动健康检查模块或者每台nacos上自己挂一个监控脚本检测到异常直接修改nginx upstream配置文件并reload。我在配置里写了max_fails2 fail_timeout30s意思是30秒内最多失败2次就把该节点标记为不可用不再转发流量。但对nacos这种需要长连接的服务被动健康检查并不完美因为很多故障是“连接建立了但响应变慢”而不是“连接失败”。如果条件允许用nginx商业版的health_check或者开源模块nginx-upsync配合consul做动态后端发现体验会好很多。不过对大多数中小团队被动检查加Cloud Alert已经足够用。5. 常见问题排查实录5.1 先放一个速查表我在排查过程中遇到的问题都整理到了表里按“症状—原因—解法”来描述方便你直接对号入座。症状可能原因解决方案浏览器访问nginx域名返回404proxy_pass路径拼接不对或location匹配到了别的块检查proxy_pass是否完整带/nacos/location和proxy_pass末尾斜杠保持一致控制台能打开但服务注册不上2.x的gRPC端口9848不通或注册地址变成nginx IP用stream代理8848和9848客户端显式指定discovery.ip页面一直302重定向nginx做SSL终止后Location头还是http加上proxy_redirect http:// https://;上传/拉取大配置时报413nginx默认client_max_body_size只有1m在server块里设置client_max_body_size 50m;配置变更后客户端没有及时刷新gRPC长连接被nginx断开客户端重连慢调大proxy_read_timeout启用upstream keepalive登录nacos控制台后跳转到内网IPHost头传递错误或nacos使用绝对地址拼接设置proxy_set_header Host $host;集群节点显示全部下线客户端与nacos之间的健康检查IP不通检查nacos节点IP配置确认注册地址能互通同时代理多个web项目时互相干扰多个server_name或location块混在一起每个项目独立conf文件用server_name区分CentOS Stream 9上nginx启动失败SELinux或依赖库缺失检查nginx -t、journalctl日志、确认libssl等依赖表格里的内容都是我真实遇到的只有一个“同时代理多个web项目”的问题是我帮同事排查的。他那台nginx上挂了三个项目其中nacos的location /nacos/写到了默认server里被其他项目的location /拦截了导致nacos控制台永远返回404。5.2 一次“控制台能打开但服务注册不上”的完整排查记录这个案例我印象最深因为我花了大半天才定位到问题。现象是通过nginx域名访问nacos控制台完全正常登录、配置列表、服务列表都能看到但新启动的微服务一直注册失败日志里报currentServerAddr: http://nacos.example.com, err: connect timed out。一开始我以为是nginx配置问题反复改了proxy_pass都没用。后来在微服务所在机器上手动测试curl http://nacos.example.com:80/nacos/v1/ns/instance/list?serviceNametest能正常返回。问题在于服务注册时nacos客户端不仅要发HTTP请求还要建立gRPC长连接而客户端的gRPC地址是自动拼接的它会把spring.cloud.nacos.server-addrnacos.example.com解析出主机名和端口80然后推断gRPC端口是8010001080。实际上nacos真实gRPC端口是9848而1080在nginx上根本没监听所以一直超时。找到原因后解决方案就很清晰了如果坚持七层HTTP代理就必须让nacos的gRPC端口也能通。最直接的办法是改nginx监听端口和nacos gRPC端口保持一致。既然nacos主端口是8848gRPC是9848我们直接让nginx在8848和9848上做四层stream转发问题彻底解决。微服务只认一个地址10.0.0.5:8848nginx把HTTP转发到后端的8848把gRPC转发到后端的9848。排查这类的通用思路是先抓住报错关键字比如connect timed out、Connection refused、No provider再逐层测试。我曾经把这些关键字整理成一个脚本批量检查端口连通性和HTTP响应。最常用的是nc -vz 10.0.0.5 9848和curl -v看握手过程基本能定位90%的网络问题。5.3 nginx日志里的线索怎么看遇到问题第一件事永远是看日志而不是瞎改配置。nginx的access log能看到请求进来了没有error log能看到upstream连接失败的具体原因。我比较习惯把nacos的请求单独写一个access log配置里加上access_log /var/log/nginx/nacos_access.log; error_log /var/log/nginx/nacos_error.log warn;排错的时候切到日志目录tail -f /var/log/nginx/nacos_access.log grep -i error /var/log/nginx/nacos_error.log比如你看到access log里有大量499状态码说明客户端主动断开了连接大概率是等待时间过长和proxy_read_timeout有关。如果看到502或504说明upstream对应的nacos节点连接不上或超时下一步就用curl直接访问那个节点确认它是否存活。记住一点nginx日志是第一手现场证据别在没有任何证据的情况下反复reload配置。reload本身不会造成大问题但你改来改去如果没有确定依据只会让问题更乱。6. 几个容易忽略的高级细节6.1 代理nacos open API时注意body大小和鉴权如果你在业务系统里直接通过HTTP调用nacos的open API比如发布配置、查询配置、触发服务心跳那么nginx的client_max_body_size和鉴权透传就会变得关键。nacos 2.2.0以后默认开启了鉴权open API需要在header里带Authorization: Bearer token或者用户名密码。如果通过nginx代理要确保请求头不被篡改Authorization默认是透传的问题不大。但如果你在nginx层加了proxy_set_header去覆盖一些不必要的头极有可能把Authorization也覆盖掉这时候调open API会一直返回403。另外发布大配置时如果client_max_body_size不够nginx直接返回413根本到不了nacos。我在配置里写50m是因为我们有一个包含大量数据源和路由规则的配置文件超过了默认的1m。你可以根据自己实际情况调整但别设太小也别无脑设成1g容易造成内存压力。6.2 日志、监控和告警的小建议nginx层启日志后最好用logrotate定期切割否则/var/log/nginx分区会被打满。可以用现成的logrotate配置也可以cron里加一行/usr/sbin/logrotate /etc/logrotate.d/nginx针对nacos的可用性监控最简单的做法是cron脚本每分钟curl一次登录页或健康检查接口*/1 * * * * curl -s -o /dev/null -w %{http_code} http://127.0.0.1:80/nacos/v1/console/health/readiness | grep -q 200如果返回不是200就触发告警。要注意的是健康检查接口响应可能不一定是200而是其他状态码用curl -s看返回内容更可靠。我这边是把检查结果写入Prometheus的自定义exportergrafana上挂了一个“nacos代理可用性”的仪表盘效果直观。6.3 优雅下线与摘流还有一个小技巧当nacos节点要做维护升级时直接在nginx upstream里把这个节点注释掉然后reload流量就不会再打过去了。但要注意reload会导致已有的gRPC长连接断开如果客户端重连逻辑不健壮可能造成短暂的服务注册抖动。所以尽量在业务低峰期操作且一次只摘一个节点等客户端全部重连稳定后再摘下一个。举一个实际例子。有一次我们要升级nacos集群的三台节点我把upstream里第一台注释掉reload观察日志等客户端陆续注册到另外两台再把这台的nacos进程停掉。整个过程大概花了5分钟服务无感知。如果一次性三台全部注释那nacos集群直接没有可用节点所有依赖配置中心的微服务都会启动失败或拉取配置超时这就是事故了。至于下线后的配置同步nacos集群节点之间会自动处理不用人工干预。只要保证同一时间至少有一台节点存活集群就能继续对外提供服务。7. 最后再分享一个小技巧做完nginx代理后可以用openssl或nginx的sub_filter给控制台页面加一些额外响应头比如X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN安全性会更好。虽然不是必需但在安全扫描的时候能少几个告警。nginx配置里加add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always;如果这台nginx只代理nacos加这些没问题。如果nginx还代理了其他web项目别全局加只加到nacos这个server块里否则某些第三方页面可能因为X-Frame-Options被拦而无法嵌入。还有个更实用的小技巧就是nginx里给nacos的/nacos/v1/ns/健康检查路径配置缓存。如果你有很多微服务频繁调用健康检查或心跳接口而这些接口对实时性要求没那么高可以用proxy_cache缓存几秒减少后端压力。但心跳接口不建议缓存因为nacos需要看到实时的心跳数据缓存可能导致误判实例下线。配置变更查询接口也不好缓存会破坏“动态刷新”的效果。能缓存的一般是服务列表查询这类只读接口实际收益有限所以不展开。根据我个人经验nginx配nacos并不难难点在于nacos 2.x的gRPC端口和注册IP这两个点很多配置看起来“通了”但其实只是控制台通了客户端压根没连上。只要把这两点想清楚其他都是常规操作。希望这篇记录能让你少走一点弯路。