如果你也正在给后台管理系统做访问入口改造想把原来那串IP:端口换成好记的域名那么这篇文章就是围绕使用域名访问后台管理系统(Nginx)的一份实战记录。我这次改造的背景很简单后台系统一直挂在 192.168.x.x:8080 上开发同学自己随手能背出来但每次换环境、加新人、问题排查都要重新翻文档更麻烦的是登录密码还是明文走HTTP心里始终不踏实。后来我用一个后台管理域名把入口收口到Nginx再配上HTTPS整个访问体验和安全性都上了个台阶。这篇文章适合正在部署后台系统的开发、运维也适合第一次碰Nginx但想把事情做规范的同学。我尽量不堆配置而是把链路拆开讲说清楚每一步为什么这样选、不这么做会遇到什么坑。下面所有配置都是可以直接复制改一改就能用的。1. 为什么后台管理系统一定要走域名而不是裸IP加端口1.1 裸IP加端口在真实业务里的三种痛点先说说我一直坚持让后台管理系统走域名的原因。最直接的一个问题就是记忆和分享成本。IP 加端口这种东西本质上是给机器看的不是给人看的。一个人面对一台服务器的时候还好一旦后台系统要交接、要给别人开权限、要让财务或者运营也进去看数据那串 192.168.x.x:8080 就会被复制到各种地方多一个字符少一个字符都看不出来出了问题你都不知道访问的到底是不是那个环境。第二个痛点是端口会越开越多。今天上一个监控系统占 8080明天内部工具占 9090后天日志平台又占 5601。时间一长服务器上到底开了哪些端口、哪个端口对应哪个系统全靠一张快过期的 Excel 表。而且端口全部暴露在防火墙上外部扫描一眼就能看到你在跑什么服务安全上也不体面。第三个痛点是IP一旦变化所有入口跟着失效。后端服务换个机器、机房迁移、IP重新规划这些都是说不准哪天就来的事。如果业务方只记住了 IP:端口环境一变就彻底找不到入口。域名则把用户访问的地址和后端真实地址彻底解耦IP 变了域名不动Nginx 里改一行转发目标就恢复。1.2 域名访问给后台管理带来的四个便利域名带来的便利不是锦上添花而是实打实的管理收益。首先是可读性。admin.你的域名 和 192.168.x.x:8080 放在一起谁更容易被记住、更不容易被写错一目了然。给新人发链接的时候也不用再反复叮嘱前面还有一段是 http://。其次是可以用 server_name 做二级域名分流。你完全可以把订单后台、用户后台、运维平台分别挂到不同的子域名下Nginx 根据域名把请求分发到不同后端。这样所有入口都收口在同一个公网IP上只开放 80/443 两个端口后台端口不再暴露维护面也小很多。再者是后端迁移对使用者完全透明。后端应用从物理机换到容器、从 A 机器换到 B 机器只要把 Nginx 的 proxy_pass 改一下并 reload用户访问的域名还是那个收藏夹里的地址也不会失效。这个迁移成本几乎是零。最后是让上 HTTPS 成为顺理成章的事。证书绑定的是域名不是IP没有域名你连正规证书都申请不了。后台管理系统承载的是账号密码和管理操作这类系统在公网上裸奔HTTP风险确实有点高。1.3 什么时候可以暂时不折腾域名当然也有一种情况暂时可以不折腾系统只在你的笔记本上本地跑或者在一个完全封闭的内网里只有你一个人用IP 也长期不变。这种情况折腾域名确实收益不大。但只要系统要交给别人用或者要放到公网服务器上我建议还是别偷懒域名加Nginx这套组合早配早省心。2. 把域名访问后台系统整条链路拆开看2.1 浏览器输入域名之后发生了什么想配置不出错先得在脑子里建立一条完整的请求链路。假设你在浏览器地址栏输入 admin.example.com整个过程是这样的首先浏览器向DNS服务器查询 admin.example.com 对应哪个IP然后把HTTP请求发到这个IP的 80 或 443 端口服务器上Nginx收到请求后根据请求头里的 Host 字段去匹配配置好的 server_name匹配成功后Nginx 作为反向代理把请求转发给实际运行后台服务的端口后端处理完返回响应Nginx 再原样带回给浏览器。这条链路里最关键的一个认知变化是从用户的角度看后台系统的地址变成了域名浏览器永远只和 Nginx 建立连接而你的后端应用可以安心地监听在 127.0.0.1 上外部完全碰不到它。原来直接暴露在公网上的 8080 端口相当于从入口链路上消失了。2.2 端口规划与监听地址我给这次改造画的表动手之前建议先把规划写清楚避免临时东改一处西改一处。下面是我这次改造用的规划你可以照着替换成自己的实际地址角色地址与端口说明DNS A记录admin.example.com - 服务器公网IP负责把域名解析到服务器Nginx监听0.0.0.0:80 / 0.0.0.0:443对外只暴露这两个端口后端应用监听127.0.0.1:8080仅有Nginx能访问外部不可达前端静态资源/data/www/admin前后端分离时由Nginx直接读取HTTPS证书/etc/nginx/cert/admin.example.com.pem证书私钥存放在服务器指定目录这里特别提醒一下监听地址。很多后台服务默认监听 0.0.0.0也就是所有网卡都可达。如果它监听在 127.0.0.1只有本机Nginx能转发到它跳到公网的安全风险直接小一截。如果后端和Nginx不在同一台机器那就监听在内网网卡地址并确认防火墙只允许Nginx所在机器访问。2.3 理解 proxy_pass 的路径拼接规则Nginx新手最常见的配置困惑就是 proxy_pass 后面到底要不要带斜杠。这直接决定了转发给后端时路径是原样还是被改写。当 proxy_pass 后面不带 URI 时比如 proxy_pass http://127.0.0.1:8080;Nginx 会把原始请求的完整URI原样转发给后端例如请求 /api/user 转给后端还是 /api/user。当 proxy_pass 后面带了路径或斜杠时情况就变了例如 proxy_pass http://127.0.0.1:8080/;Nginx 会把 location 匹配到的前缀拿掉再把剩余部分拼到代理地址后面。假设 location 是 /api/请求来了 /api/user转发给后端的实际路径就成了 /user。这个特性常常被用来做前缀剥离比如前端只认识 /api后端接口却是 /v1/user。用错的话后端会返回一堆 404页面白屏你还以为是后端挂了。3. 第一个能直接复用的Nginx配置先跑通HTTP域名访问3.1 动手前先确认三件事配置Nginx之前别急着写文件先把环境摸清楚。第一确认后端服务已经正常监听在 127.0.0.1:8080。在服务器上执行 ss -lntp | grep 8080能看到 LISTEN 状态基本就没问题再执行 curl http://127.0.0.1:8080如果后端有响应说明可以进入下一步。第二确认Nginx已经安装并且正在运行执行 nginx -v 看版本执行 systemctl status nginx 看运行状态。第三登录你的域名管理控制台先把 A 记录加上指向这台服务器的公网IPTTL 可以设短一点比如 600 秒方便测试期调整。这一步很多新手会跳过结果配置写完发现后端其实监听在别的端口白白排查半天。我自己的习惯是先用 curl 验证后端通再动Nginx顺序永远别反。3.2 最基础的 server 块以及每行配置的含义先给一个最简配置目标是把 HTTP 跑通server { listen 80; server_name admin.example.com; location / { 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; proxy_set_header X-Forwarded-Proto $scheme; } }这段配置里listen 80 表示Nginx监听80端口接收 HTTP 请求server_name admin.example.com 告诉Nginx只有当请求头里的 Host 是这个域名时才走这个 server 块。这也是同一台服务器上放多个域名的基础Nginx 靠它区分站点。关键在下面四行 proxy_set_header。Host $host 是把浏览器请求里的域名透传给后端。很多后端框架会拿 Host 去生成绝对链接如果不传后端看到的 Host 可能就是 127.0.0.1:8080生成的跳转地址、重置密码链接、Cookie 作用域全都会错。X-Real-IP 和 X-Forwarded-For 是为了让后端知道真实访客IP不然日志里全是 127.0.0.1你根本无法分辨谁在访问。X-Forwarded-Proto 则是告诉后端用户用的是 HTTP 还是 HTTPS后面配 HTTPS 时尤其重要。3.3 加域名解析A记录与本地 hosts 速验配置写好后去域名控制台添加 A 记录主机记录填 admin记录值填服务器公网IP。添加后可以通过 nslookup admin.example.com 或在线DNS工具确认解析是否生效。如果当前还没有域名或者想绕过DNS立刻测试可以改本地 hosts 文件在 /etc/hostsWindows 是 C:\Windows\System32\drivers\etc\hosts里加一行服务器公网IP admin.example.com提示hosts 只对当前设备生效适合测试Nginx配置用。域名在多个客户端都能访问最终还是要靠 DNS 解析。加完 hosts 后打开浏览器访问 http://admin.example.com如果能看到后台登录页说明 Nginx 这一层已经通了。3.4 前后端分离时的静态资源与 history 路由处理刚才的配置能跑通后台系统但如果你的后台是前后端分离的项目一般不建议让后端应用同时承担静态文件响应更合理的做法是让 Nginx 直接读前端构建产物接口再反代给后端接口服务。配置可以这样写server { listen 80; server_name admin.example.com; root /data/www/admin; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/; } location / { try_files $uri $uri/ /index.html; } }root 指向前端打包后的目录比如 Vue 或同类框架构建出来的 dist 上传到 /data/www/admin。location /api/ 这段把接口请求转发给后端注意我用的 proxy_pass 带了尾部斜杠意思是把 /api/ 前缀剥掉再转发这样后端就不用额外加一层 /api 前缀。如果后端本来就有 /api 前缀那就不要带斜杠写成 proxy_pass http://127.0.0.1:8080;。最后那行 try_files 也很关键。现代前端框架多数是 history 路由访问后台某个子页面时URL 是 /user/list 这种真实路径但服务器上并不存在这个文件。try_files 的作用是先找真实文件找不到就回退到 /index.html把路由控制权交回前端框架。不写这行你一刷新子页面就 404。这个坑我见过太多次了。3.5 nginx -t 与平滑重载配置文件写完后别直接 restart先检查语法nginx -t只要输出显示 syntax is ok 和 test is successful就可以平滑重载systemctl reload nginxnginx -s reload 也能达到同样效果。注意 reload 和 restart 的区别reload 是让Nginx重新读配置已经建立的连接继续走旧配置新连接走新配置对正在使用的用户影响极小restart 则会瞬间断开所有连接。后台管理系统虽然用户量不大但养成用 reload 的习惯没有坏处。4. 从HTTP升级到HTTPS证书申请与Nginx配置要点4.1 后台管理系统的密码不该在链路上裸奔如果后台管理域名要面向公网那 HTTPS 基本是必须的。原因很简单登录时输入的账号密码如果走 HTTP就是明文在网络上传输中间任何一个环节被截获都能直接看到。尤其后台管理系统的账号通常权限高一旦被拿到后果不是开玩笑的。另外现代浏览器对非 HTTPS 页面会直接标不安全对用户心理也有负面影响。免费证书已经很成熟给一个后台管理子域名申请证书的成本几乎为零实在没有理由不走 HTTPS。4.2 免费证书申请与放置流程证书申请的大致流程是在证书服务商处申请一张 DV 域名证书绑定 admin.example.com然后通过 DNS 添加一条 TXT 记录或者在你的网站根目录放一个验证文件用来证明你确实拥有这个域名。验证通过后你会拿到两个文件一个是证书文件通常以 .pem 或 .crt 结尾一个是私钥文件以 .key 结尾。拿到文件后放到统一目录比如 /etc/nginx/cert/ 下面然后收紧权限mkdir -p /etc/nginx/cert chmod 600 /etc/nginx/cert/admin.example.com.key注意私钥文件等同于密码别传到代码仓库别共享到群里服务器上建议限制只有 root 能读。漏私钥等于前面所有安全措施白做。4.3 HTTPS server 配置与 HTTP 自动跳转证书文件放好后在同一个 server 配置里加一组 HTTPS 监听server { listen 443 ssl; server_name admin.example.com; ssl_certificate /etc/nginx/cert/admin.example.com.pem; ssl_certificate_key /etc/nginx/cert/admin.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { 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; proxy_set_header X-Forwarded-Proto $scheme; } }如果希望用户访问 http://admin.example.com 时自动跳到 https不用加额外页面单独写一个 80 端口的 server 块做跳转server { listen 80; server_name admin.example.com; return 301 https://$host$request_uri; }这里有一点我要特别提醒regarding HSTS 响应头也就是 Strict-Transport-Security。它告诉浏览器以后这个域名只能用 HTTPS一旦下发浏览器会在你设定的时间范围内强制走 HTTPS。这个头很有用但如果你的证书续期流程还不稳定或者还在频繁回滚 HTTP我建议先不要加或者把 max-age 设得短一些比如 3600等稳定了再加长。否则证书到期没续上用户浏览器还会强行 HTTPS连降级访问的机会都没有。4.4 证书续期与自动化别等过期那天DV 证书有效期通常只有三个月到期没续真的会有人打电话问你系统怎么打不开了。建议直接配自动续期。现在主流 ACME 客户端都支持签发免费证书并且可以通过 crontab 定时任务自动续期。大致思路是每月定时执行一次续期命令续期成功后执行 nginx -s reload 让新证书生效0 3 1 * * /usr/bin/某acme客户端续期命令 --renew-hook nginx -s reload这句话的意思是每月的凌晨3点执行一次续期检查续期成功就重载Nginx。具体命令以你用的工具为准但套路就是这样。配好自动续期后平时基本可以不用管证书偶尔瞄一眼到期时间就行。5. 从IP切到域名后必踩的坑Cookie、跨域与WebSocket5.1 登录失效的元凶Cookie 的 Domain 和 SameSite我这次改造遇到的最棘手问题不是Nginx配置而是切到域名后登录状态保不住。现象是登录跳转成功但刷新一下又回到登录页看了后台日志发现用户确实认证通过了但浏览器并没有把登录凭证保存下来。排查后发现原因是后端在返回 Set-Cookie 时Cookie 的 Domain 被写死成了旧IP。浏览器接收到一个和当前域名不匹配的 Cookie会直接拒绝存储。解决办法是改后端配置把 Cookie 的 Domain 改成空让它跟随当前请求域名生成或者改成 admin.example.com。如果后端不方便改也可以看下应用框架有没有类似信任代理的开关开启后 Cookie 会按请求里的 Host 生成。另一个容易忽略的是 SameSite 属性。很多后台系统会被嵌入到内部办公平台里用 iframe 打开如果 Cookie 的 SameSite 是比较严格的模式在跨站 iframe 场景下 Cookie 可能不会携带导致登录失效。这种问题不一定和域名切换直接相关但切域名后更容易被暴露出来。遇到这种场景需要检查后端 Set-Cookie 的 SameSite 设置必要时改成兼容方式。5.2 同域代理是最省心的跨域方案在域名改造前前端页面可能部署在一个域名接口服务在另一个IP上开发调试时天天遇到跨域报错。切到域名并由 Nginx 反代之后前端页面和接口路径天然同域跨域问题直接消失。这也是我坚持让接口和前端共用同一个域名的原因。但在某些场景下后端接口可能还要给别的系统用比如从另一个管理平台通过接口拉数据这时就会涉及 CORS。Nginx 侧加响应头也能处理add_header Access-Control-Allow-Origin https://other.example.com always;不过我要提醒一句如果后端应用本身也配置了 CORS两层都加会造成响应头重复或者冲突。最好确认一下策略边界Nginx 管好域名层应用层该管业务就管业务别两个地方都写。最省心的原则仍然是一个域名同域访问不加跨域头。5.3 WebSocket 连接在反向代理下的升级配置后台管理系统里如果带有实时告警、在线日志查看、流水推送这类功能通常会有 WebSocket 长连接。Nginx 默认的 HTTP 代理配置不会自动处理协议升级你会发现页面能打开但实时推送一直连不上。需要在 location 里加上协议升级的头location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }这里解释一下原理WebSocket 连接建立前客户端会通过 HTTP 请求头里的 Upgrade 字段发起协议切换Nginx 要原样把这个请求透传给后端就必须关掉默认的 proxy_http_version 1.0改用 1.1并显式传递 Upgrade 和 Connection 头。最后那行 proxy_read_timeout 也很重要默认 60 秒没有数据就会被判定超时断开长连接场景下建议拉长时间否则日志看一会儿就断线。5.4 页面白屏、接口 404排查写死IP和端口的埋雷域名改造最隐蔽的坑是前端代码或者后端配置里把之前的 IP:端口写死了。常见情况有两种一种是前端代码的接口地址写的是 http://192.168.x.x:8080/api无论你在地址栏输入哪个域名页面加载后真正发请求的还是那个IP一旦IP访问权限收紧接口立刻全挂表现就是页面白屏控制台一片红。另一种是后端生成的回调链接写死了IP常见于重置密码邮件、单点登录回调、文件下载地址等。这类问题的排查顺序我建议是先在浏览器 F12 的 Network 面板看请求发到哪个地址然后在前端源码里全局搜索之前的IP串。全部改成相对路径或者根据当前请求域名动态拼接才是根治方案。5.5 重定向循环和请求被重定向到 http还有一个很不起眼但很折磨人的问题用户访问 https 域名后登录成功后端却把请求重定向到 http 地址浏览器又强制跳回 https来回几次直接报重定向次数过多。根因是后端不知道自己其实是在 HTTPS 后面。它看到请求是 HTTP 就认为不安全于是生成一个跳转让它换成 HTTPS可实际上浏览器已经在用 HTTPS 了。解决方式就在前面反复提到的 X-Forwarded-Proto $scheme。只要 Nginx 把原始协议传给后端后端再配合框架的信任代理相关开关就能正确识别用户使用的是 HTTPS。需要注意的是信任代理接口有安全边界不要无条件信任外部传入的 X-Forwarded-* 头只要保证只有 Nginx 能直连后端端口即可。6. 切换前后的验证清单与回滚预案6.1 先验证 Nginx 转发再动客户端我习惯在浏览器配置之前先用命令行把链路验证完整。验证分三层。第一层验证 Nginx 对域名的匹配是否正常在服务器本机执行curl -H Host: admin.example.com http://127.0.0.1/这一步不会真的走 DNS而是手动指定 Host直接打到 Nginx 上。如果返回的是后台页面内容说明 server_name 匹配成功。如果返回的是默认站点页面说明你的 server 块没生效多半是配置没加载或 server_name 写错。第二层验证域名解析和公网链路curl -I http://admin.example.com curl -kI https://admin.example.comcurl -k 的意思是跳过证书校验用来确认证书路径放好后 HTTPS 端口能不能正常响应。如果看到 HTTP/1.1 301 这样的返回说明跳转配置起了作用如果直接 200说明服务正常。第三层验证转发是否到达后端打开Nginx访问日志 tail -f /var/log/nginx/access.log再访问一次域名能看到对应请求记录就说明整条链路完整。6.2 浏览器与客户端侧检查清单命令行验证通过后一定要在真实浏览器里走一遍完整流程。我建议用无痕窗口避免旧 Cookie 干扰。清单大致是这样打开 https://admin.example.com确认地址栏不出现不安全警告。输入用户名密码登录确认登录成功后刷新页面登录态还在。按 F12 打开 Network 面板确认页面所有请求都是 https 开头且 API 请求域名一致。检查控制台有没有被浏览器拦截的混合内容比如 HTTPS 页面里加载了 HTTP 资源。换个网络环境或者用手机连一下确认 DNS 解析对所有人都生效而不只是你本机。如果有 WebSocket 功能打开对应页面确认连接状态是已连接并且能收到实时推送。其中混合内容拦截要重点留意。有些页面看起来一切正常但某些图标、字体或附件下载地址还是 http浏览器会直接拦截表现就是资源加载不出来。这个在切换时最容易被漏掉。6.3 回滚预案域名不可用时怎样快速恢复入口计划再好也要有退路。我强烈建议域名切换初期别急着把原来的 IP:端口 访问方式关掉防火墙端口也先保留。等域名方案跑稳了比如连续几天无人报障再逐步收紧暴露面。这不是拖泥带水而是给自己的容错空间。Nginx 配置层面的回滚最稳妥的办法是用独立配置文件。每个站点一个文件比如 /etc/nginx/conf.d/admin.example.com.conf改之前先复制一份备份cp /etc/nginx/conf.d/admin.example.com.conf /etc/nginx/conf.d/admin.example.com.conf.bak配置出了问题直接执行 nginx -t 检查再根据情况回滚cp /etc/nginx/conf.d/admin.example.com.conf.bak /etc/nginx/conf.d/admin.example.com.conf nginx -t systemctl reload nginx如果问题出在 DNS 还没生效而你又在赶时间可以在需要访问的机器上临时加 hosts 记录跳过 DNS 直接解析到目标服务器。证书如果暂时有问题则先把 80 跳到 443 的那段配置注释掉回退到 HTTP 先恢复业务等证书处理好再切回去。记住回滚要快、要简单不要在用户已经报障的时候还做复杂的验证。这次改造下来我最大的体会是Nginx 的配置本身并不算复杂真正花时间的是让后端应用感知到环境变了。Cookie 的域名、回调地址、重定向协议判断这些问题每一个都足以让域名切换看起来像是个大型翻车现场。最后分享一个习惯把每个站点的 Nginx 配置独立拆成一个文件命名带域名改之前先备份再小的改动也走检查、备份、写入、reload这套流程。靠这个习惯我在好几次手滑的时候都只用几十秒就完成了回滚希望你也能用上。