企业官网建设流程全解析

最近帮团队搭本地联调环境，前后端同事差点吵起来。前端说接口全是 http 请求，被浏览器拦得死死的；后端说证书配置太麻烦，根本不想碰。最后我直接用 Nginx 在本地做了一个 http 转 https 的统一入口，前后花了不到十分钟，两边都消停了。

所谓 http 转 https，本质上是让 Nginx 充当一个带 SSL 终结能力的反向代理：客户端通过 https 访问 Nginx，Nginx 解密后，再把请求转发给背后跑着 http 服务的本地应用。后端代码一行不用改，就完成了从明文到加密的切换。

这篇文章我会把整套方案从头到尾过一遍：为什么本地也需要 HTTPS、自签名证书怎么生成、Nginx 配置怎么写、多项目怎么分流、以及我这些年踩过的一堆坑。适合做 Web 开发、前后端联调、以及有本地环境维护需求的运维同学参考，看完就能直接照抄。

1. 方案思路：为什么本地也得折腾 HTTPS

1.1 本地开发逃不掉的三个场景

先说说我为什么要折腾这件事。日常开发里，你至少会遇到下面三种情况，跑都跑不掉：

• 前端页面已经部署在 https 域名下，浏览器会直接拦截从 https 页面发往 http 接口的请求，这就是混合内容（Mixed Content）问题。打开 Chrome 控制台，满屏都是 "This request has been blocked"。
• 微信、小程序、某些 App 的 WebView 对 http 限制更严格，不仅拦截，有的直接白屏。想本地调试这类环境，不搞 https 根本进不去。
• Cookie 的 Secure 属性。线上环境签发 Cookie 时带上了 Secure 标记，本地 http 环境无法回传这种 Cookie，登录态在本地直接失效。联调登录功能时最容易踩这个。

这些问题的根源，就是本地环境和线上环境的“协议不对称”。与其在代码里到处打补丁，不如在入口处统一解决——这就是 Nginx 做 http 转 https 的价值：把所有本地 http 服务统一收口到一个 https 入口后面，前端、后端、联调脚本全部走同一条加密通道。

1.2 HTTP 和 HTTPS 的真实区别

很多同学对这两个协议的理解停留在“HTTPS 更安全”一句话上，但做配置的时候，你得知道它到底改了什么。

HTTP 是明文协议，客户端和服务器之间的请求、响应、Cookie、Token，全部裸奔在网络里，任何能截获流量的人都能直接看到内容。HTTPS 并不是一个全新协议，它是 HTTP 和 TLS/SSL 的组合，核心逻辑是：先通过 TLS 握手完成身份验证和密钥协商，之后所有 HTTP 数据都用对称加密传输。

换句话说，HTTPS 多出来的工作量，全部集中在握手阶段。握手阶段有两件重要的事：第一，服务器向客户端出示数字证书，证明“我是谁”；第二，双方协商出会话密钥，后续数据全部走加密通道。

这也解释了为什么本地开发要用自签名证书。证书的作用是身份证明，自签名证书只是没有经过 CA（证书颁发机构）背书，它在加密能力上和正规证书没有任何区别。本地调试完全够用，唯一的问题是浏览器默认不认它，手动信任一下就好。

1.3 为什么选 Nginx 而不是其他工具

本地实现 https 的方案其实不少，我简单列一下对比：

我推荐 Nginx 的核心原因有三个。一是收口，本地可能有前端 dev server、后端 API、文件服务、Mock 服务等多个进程同时跑，Nginx 一次性全部接管，按域名或路径分流；二是改动小，后端服务完全不用感知 HTTPS，代码一行不用动；三是一致性，线上生产环境通常也是 Nginx 做 SSL 终结，本地和线上配置逻辑一致，调试环境就相当于生产环境的缩小版，排查思路可以无缝复用。

2. 准备工作：安装 Nginx、生成自签名证书

2.1 不同平台下 Nginx 的安装方式

Nginx 的安装方式根据操作系统不同略有差别，我把常用的列出来：

• macOS：直接用 Homebrew，执行brew install nginx。装完配置文件在/usr/local/etc/nginx/nginx.conf（Intel 芯片）或/opt/homebrew/etc/nginx/nginx.conf（Apple Silicon）。
• Ubuntu/Debian：sudo apt update && sudo apt install nginx。配置文件在/etc/nginx/nginx.conf，站点配置习惯放在/etc/nginx/sites-available/和/etc/nginx/sites-enabled/。
• CentOS/RHEL：sudo yum install nginx或sudo dnf install nginx，配置主文件路径同样是/etc/nginx/nginx.conf。
• Windows：去官网下载稳定版 zip 包，解压后直接运行nginx.exe。Windows 下配置语法和 Linux 完全一致，但注意没有守护进程，改配置用nginx -s reload生效。

我自己的习惯是：本地项目单独建一份配置文件目录，不在主配置文件里直接改，而是用include把项目配置引进去。这样不同项目之间互不污染，删除某个项目时直接把对应配置移除就行，非常干净。

提示：装完先跑nginx -t验证语法，再执行nginx -s reload。很多初学者改完配置直接重启，语法报错会导致整个 Nginx 起不来，这是一条被反复验证的教训。

2.2 用 OpenSSL 一键生成自签名证书

Nginx 做 https，必须要有证书和私钥。本地调试不需要去 CA 机构申请，用 OpenSSL 生成自签名证书就行，一条命令搞定：

openssl req -x509 -newkey rsa:2048 -nodes \ -keyout localhost.key \ -out localhost.crt \ -days 365 \ -subj "/CN=localhost"

逐个解释关键参数：

• req -x509：生成自签名证书，而不是生成证书签发请求（CSR）。
• newkey rsa:2048：同时生成新的 RSA 密钥对，长度 2048 位。2048 是当前最低推荐标准，千万别用 1024，浏览器会直接嫌弃。
• -nodes：私钥不加密。生产环境不建议这么干，但本地调试图方便。
• -keyout/-out：分别指定私钥和证书的输出路径。
• -days 365：有效期 365 天。macOS 的 Chrome 对超过 398 天的证书会直接报错，所以设 365 天最稳。
• -subj "/CN=localhost"：证书的 Common Name。如果只是单机本地访问，写localhost就够；如果要用自定义域名，比如dev.example.com，这里要写域名，并且 Nginx 配置里的server_name要和它一致。

如果你想用局域网 IP 在手机上调试，或者一个证书要覆盖多个域名，就需要加 SAN（Subject Alternative Name）扩展：

openssl req -x509 -newkey rsa:2048 -nodes \ -keyout localhost.key \ -out localhost.crt \ -days 365 \ -subj "/CN=localhost" \ -addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1,IP:192.168.1.100"

SAN 里可以混写 DNS 和 IP，浏览器校验证书时优先看 SAN。如果你的页面会通过局域网 IP 被手机访问，务必把 IP 加进去，不然手机端永远报证书错误，而且这种报错在电脑上还复现不出来，非常坑。

2.3 把自签名证书装进系统信任区

生成完证书后，直接访问 https://localhost 会被浏览器拦一大屏。原因前面说过：证书没有 CA 签名，浏览器无法验证身份。解决方案是把它加入系统信任区。

• macOS：双击localhost.crt，在“钥匙串访问”里导入，选择“系统”钥匙串，把证书的信任级别改为“始终信任”。
• Windows：双击 crt 文件，选择“安装证书”，存储位置选“本地计算机”，然后放到“受信任的根证书颁发机构”目录下。
• Ubuntu：sudo cp localhost.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates。
• 移动端：通过邮件或网盘把 crt 传给手机安装。iOS 安装后还要去“设置 - 通用 - 关于本机 - 证书信任设置”里打开开关；Android 不同版本入口略有差异，但逻辑基本一致。

注意：自签名证书只适合开发环境。如果用在生产环境，用户会看到“不安全”警告，而且一旦站点启用了 HSTS 等严格安全策略，浏览器会直接拒绝连接。生产环境请走 Let's Encrypt 或云服务商的证书申请流程。

3. 核心配置：Nginx 实现 HTTP 转 HTTPS

3.1 最基础的 SSL 终结配置

证书和私钥就绪后，先写一个最小的反向代理配置。假设本地有一个服务跑在127.0.0.1:8080，我们需要让 Nginx 监听 443 端口，以 https 接收请求，然后转发到 8080：

server { listen 443 ssl; server_name localhost; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; 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; } }

这套配置的核心逻辑就是“SSL 终结”：客户端和 Nginx 之间是加密的 https，Nginx 和后端服务之间是普通 http。后端代码完全不用管 TLS 的事，只管处理业务逻辑。

几个协议头是必须的：

• Host $host：保留原始请求的域名，否则后端拿到的是127.0.0.1，生成链接、做路由判断时都会出错。
• X-Real-IP和X-Forwarded-For：把客户端真实 IP 传给后端。不加的话，后端看到的全是 Nginx 本机地址，日志和鉴权都会出问题。
• X-Forwarded-Proto $scheme：告诉后端“原始请求是 https”。后端生成重定向、拼接回调地址时都会判断这个头，少了它很容易出现“回调地址变成了 http”的诡异问题。

3.2 HTTP 强制跳转 HTTPS 的三种写法

光有 443 监听还不够，用户访问http://localhost:8080时仍然走的是明文。通常我们要把 80 端口的请求强制跳转到 https。最简单、最常用的写法：

server { listen 80; server_name localhost; return 301 https://$host$request_uri; }

这里return 301返回一个永久重定向，$host和$request_uri会拼出完整的 https 地址。比如用户访问http://localhost/login，会被重定向到https://localhost/login。

第二种写法是用rewrite：

server { listen 80; server_name localhost; rewrite ^(.*)$ https://$host$1 permanent; }

效果上和return 301类似，但官方更推荐用return。因为它直接返回重定向响应，不走正则匹配，性能更好，语义也更清晰。我的建议是直接用return 301，没有特殊情况不需要考虑 rewrite。

第三种是只跳转特定路径。比如你只想让/api走 https，其他路径放行，可以在 80 端口的 location 里单独处理：

server { listen 80; server_name localhost; location /api { return 301 https://$host$request_uri; } location / { proxy_pass http://127.0.0.1:8080; } }

对于本地调试，我一般直接用全量跳转。但要注意：如果你的后端接口同时存在 http 和 https 两种调用方式，全量跳转会导致每次 http 请求都增加一次网络往返。本地无所谓，生产环境需要斟酌。

3.3 单机多项目怎么分流

本地最常见的情况是同时跑好几个项目：一个前端 dev server、一个后端 API、一个管理后台、一个文件服务。Nginx 的强项在于可以用一个 443 端口接收所有请求，然后按域名或按路径分流到不同端口。

按域名分流的配置：

server { listen 443 ssl; server_name project-a.local; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; } } server { listen 443 ssl; server_name project-b.local; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; location / { proxy_pass http://127.0.0.1:4000; proxy_set_header Host $host; } }

使用域名分流时，需要改 hosts 文件把project-a.local和project-b.local指向127.0.0.1。macOS/Linux 的 hosts 文件在/etc/hosts，Windows 在C:\Windows\System32\drivers\etc\hosts。这里有个重点：证书 SAN 里必须包含这些域名，否则浏览器照样报证书错误。

按路径分流的配置：

server { listen 443 ssl; server_name localhost; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; location /api/ { proxy_pass http://127.0.0.1:8080; } location /admin/ { proxy_pass http://127.0.0.1:9000; } location / { proxy_pass http://127.0.0.1:3000; } }

按路径分流有个经典大坑：proxy_pass后面有没有末尾斜杠，行为完全不同。对比一下就明白了：

也就是说，proxy_pass末尾带斜杠，Nginx 会把 location 匹配到的前缀剥掉再转发。这个细节经常导致接口 404，排查半天最后发现是斜杠问题。我的建议是：除了明确要做前缀剥离的场景，一律不加末尾斜杠。

3.4 进阶增强：HTTP/2、WebSocket 与连接复用

基础配置跑通之后，有几个增强项值得加上，能明显改善体验。

HTTP/2 能显著提升页面加载速度，尤其适合有大量并发请求的页面。老版本写法是在listen 443 ssl后面直接加http2参数：

server { listen 443 ssl http2; server_name localhost; # 其余配置略 }

但从 Nginx 1.25.1 开始，这种写法会提示弃用，官方推荐的写法是拆成两条指令：

server { listen 443 ssl; http2 on; server_name localhost; # 其余配置略 }

如果你用的是较新的 Nginx 版本，建议直接使用http2 on;的新写法，避免以后升级时收到一堆警告。

WebSocket 代理是另一个高频场景。前端页面通过ws://或wss://连接后端，Nginx 默认会直接断掉协议升级请求，必须显式配置：

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; }

这里的关键是：把 HTTP 请求里的Upgrade头原样传给后端，并且强制使用 HTTP/1.1（HTTP/1.0 不支持协议升级）。proxy_read_timeout记得设置长一点，否则 WebSocket 空闲一段时间就会被 Nginx 掐断，表现为“连接一会儿就断”。

还有一个容易被忽略的小细节是 http 连接复用。Nginx 到后端服务默认使用 HTTP/1.0，每次请求都会新建 TCP 连接，性能很差。加上两行配置让 Nginx 复用和后端之间的连接：

location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Connection ""; }

本地调试时感知可能不明显，但如果你在本地压测，或者代理的服务本身 QPS 很高，连接复用能明显降低延迟和资源占用。这个习惯建议从一开始就养成。

4. 常见问题与排查要点

4.1 证书报错与浏览器拦截

这是本地 https 最常见的报错。现象是浏览器弹出NET::ERR_CERT_AUTHORITY_INVALID，或者直接显示“您的连接不是私密连接”。排查顺序如下：

第一，确认证书是否加入了系统信任区。前面讲了不同平台的方法，这一步漏掉的概率最大。第二，确认访问的域名和证书的 CN/SAN 是否匹配。证书签的是localhost，你用127.0.0.1访问，照样报错。第三，确认证书有效期，自签名证书设了 365 天，到期后所有浏览器都会拦截，需要重新生成并重新信任。

我个人的习惯是把证书有效期统一设成 365 天，并在日历里加一个提醒，到期前一周重新生成。别用-days 3650，长期有效的本地证书在某些新版本浏览器里反而会触发“证书策略异常”的提示，得不偿失。

注意：修改系统信任区后，需要完全关闭浏览器再重新打开。Chrome 对证书信任有缓存，直接刷新页面有时不生效。

4.2 502 Bad Gateway 与连接失败

Nginx 配置好后访问报 502，说明 Nginx 本身正常运行，但没法把请求转发给后端。排查重点就一个：后端服务到底有没有在监听。

先用curl -v http://127.0.0.1:8080/health或netstat -an | grep 8080确认端口状态。如果后端没启动，或者监听的地址不是127.0.0.1而是::1，Nginx 连不上就会出现 502。很多开发框架默认监听 IPv6 地址，而 Nginx 里proxy_pass写的是 IPv4，这种“地址族不匹配”非常容易踩到。

另一个常见原因是proxy_pass把端口写错了。后端监听在 8081，你写成了 8080。这种低级错误最好用两分钟排查法：先curl -v http://127.0.0.1:端口确认后端连通，再curl -v https://localhost看 Nginx 层是否正常，两步定位，不要一上来就翻配置。

还有一种情况是 WebSocket 连接出现 502，多半是因为Upgrade头没传，或者后端不支持协议升级。参考 3.4 节的配置补上即可。

4.3 混合内容与端口占用

配置好 https 之后，页面打开发现部分资源仍然被拦，比如图片、字体、CSS、接口请求。打开浏览器开发者工具，Console 里会提示 Mixed Content 相关错误。

排查思路：看页面里所有资源的 URL 协议。如果 HTML 是 https 加载的，但里面硬编码了http://的接口地址或资源地址，浏览器就会拦。解决办法分三层：

• 尽快把代码里的地址改成协议相对写法，比如//api.example.com，让浏览器自动跟随当前协议，这是最推荐的做法。
• 如果资源地址是后端返回的，检查后端生成链接时是否带了http。这就是为什么前面反复强调X-Forwarded-Proto，后端拿到这个头才能正确生成 https 链接。
• 如果实在改不动代码，可以用 Nginx 再做一层代理，把页面上引用的 http 资源也代理到 https 入口下。但这只是临时方案，治标不治本。

端口占用是另一个容易忽略的问题。本地多个服务同时监听了 443 端口，Nginx 起不来，报错形如bind() to 0.0.0.0:443 failed。排查时用lsof -i :443看看谁占用了端口，常见冲突源是其他 Nginx 实例、Apache、或者某些 IDE 自带的静态服务器。杀掉占用进程，或者给 Nginx 换一个端口监听。

4.4 配置生效流程与开机自启

很多同学改了nginx.conf之后直接关掉进程再重启，这不是好习惯。正确的操作流程是：

nginx -t # 先检查语法 nginx -s reload # 再平滑重载配置

reload会先完整校验配置，再优雅重启工作进程，已经建立的连接不会被中断。而直接 stop/start 会断开所有连接。本地影响可能不大，但一旦养成这个习惯并带到生产环境，就是在制造事故。

关于 Linux 下的开机自启，如果你是用 apt/yum 安装的 Nginx，系统一般已经集成了 systemd 服务，直接执行：

sudo systemctl enable nginx sudo systemctl start nginx

如果是源码编译安装，需要手动写一个 systemd service 文件，或者把启动命令加到/etc/rc.local。我建议优先用 systemd，因为可以方便地查看日志、配置失败自动重启策略。

还有一个重要建议：改完配置后如果 Nginx 行为不对劲，第一件事不是反复翻配置，而是看错误日志。大多数发行版的 Nginx 错误日志在/var/log/nginx/error.log，macOS 的 Homebrew 版本在/opt/homebrew/var/log/nginx/error.log。日志里会精确到哪一行配置、哪个上游连接出了问题，比盲猜高效得多。

5. 一份可以直接抄的完整配置模板

最后给出一个完整的本地单项目配置模板，包含 http 跳转、https 监听、反向代理、WebSocket、连接复用，基本覆盖了本地开发的所有常见需求：

# /etc/nginx/conf.d/local-dev.conf # 80 端口全部跳转 https server { listen 80; server_name localhost; return 301 https://$host$request_uri; } # https 入口 server { listen 443 ssl; http2 on; server_name localhost; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; client_max_body_size 50m; # 常规 http 服务 location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; 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 Connection ""; } # WebSocket 服务 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; } }

注意client_max_body_size 50m;这一行，建议从一开始就加上。Nginx 默认只允许 1MB 的请求体，本地调试时传大文件、传图片、提交富文本内容，很容易踩到 413 Request Entity Too Large 的错误。顺手加上，能省掉很多莫名其妙的排查时间。

把这份配置放入 Nginx 配置目录并通过include引入，执行nginx -t确认语法，再nginx -s reload加载。之后访问http://localhost会被自动跳转到https://localhost，然后反向代理到本地 8080 服务，整条链路就通了。

最后再分享一个我自己坚持了很久的小习惯：每次生成证书，都把私钥路径、证书路径、配置文件的存放位置记在一个 README 文件里，放在项目根目录。这样不管隔多久回来继续开发，还是团队新人接手，照着 README 五分钟就能把本地 https 环境搭起来。本地环境这种东西，一旦断档，重搭的成本远比你想象中高。