企业官网建设流程全解析

很多人第一次遇到“本地HTTP转HTTPS”这个需求，多半不是闲着没事，而是被现实逼的：小程序或公众号后台的回调地址要求必须是HTTPS、浏览器里用到摄像头或地理位置需要安全上下文、联调第三支付接口时对方要求验签地址必须走HTTPS、又或者你只是想在外网被朋友访问一下本机服务，先加一层SSL再说。Nginx在这类场景里几乎是标准答案，它本身就是一个高性能的反向代理，放着它就是劫持本机的HTTP端口流量，在Nginx这层把TLS终结掉，再转回后端的HTTP服务。整个过程不需要改业务代码，所有HTTP流量统统强制跳到HTTPS，后端甚至不知道外面发生了什么。

这篇文章我会从零开始，把Nginx实现本地HTTP强制转HTTPS的完整过程理顺，包括自签名证书怎么生成、nginx.conf怎么配、坑在哪里，以及局域网里手机访问时怎么让证书不报错。适合正在做本地开发、前后端联调、想给本地服务套一层HTTPS但不想花钱买证书的人，也适合刚接触Nginx、对SSL配置还不太熟悉的读者，照着抄基本能跑通。

1. 内容整体设计与思路拆解

1.1 为什么是Nginx而不是直接在业务代码里开HTTPS

先说说方案选型。本地服务如果要支持HTTPS，理论上可以直接在应用服务器里配置证书，比如Spring Boot里塞一个tomcat证书、Node.js里用https模块启动。但这样做有很明显的问题：每换一个项目就要重新配一遍，有些框架配SSL挺折腾的，还有的就是一些嵌入式HTTP库根本不支持HTTPS，你总不能把底层库都改了吧。

用Nginx做统一入口就好办多了。Nginx监听443端口，负责处理TLS握手、证书下发、加解密，然后它把解密后的普通HTTP请求转发给后端的本地服务。对后端来说，它看到的还是HTTP请求，不用做任何改动。这个模式就是标准的TLS终结，Nginx在这个架构里扮演的是反向代理+TLS网关的角色。

另外，Nginx做HTTPS还有一个隐藏好处：证书、跳转逻辑、HTTP/2这些能力都集中在代理层统一管理，以后想换证书、想调整跳转策略，改配置文件reload一下就完事，不需要重新编译或者重启业务进程。这也是很多线上架构把Nginx放在最前面统一处理SSL的原因，本地开发其实只是把线上这套玩法缩小的版本。

1.2 证书方案选型：自签名还是公共CA签发

HTTPS必须要证书，但证书从哪来是个绕不开的问题。线上的网站一般用Let's Encrypt这类免费CA签发证书，浏览器天然信任，不用任何额外操作。但本地开发环境的域名通常是一个外部无法访问的地址，比如localhost、127.0.0.1，又或者是局域网里的192.168.x.x，CA全球签发机构一般不会给纯IP或者非公网域名签证书，就算签了也只能用几十天、验证也麻烦。

所以本地场景最常用的是自签名证书，用OpenSSL自己生成一个，然后让Nginx加载。自签名证书的缺点是浏览器不信任，访问时会有一个红色警告页，点“高级-继续前往”就能进。对于本地调试来说，这个警告完全可以接受，因为证书加密本身是有效的，只是没有权威CA给它背书而已。

如果你实在不想要那个警告页，后面我会提到mkcert这个工具，它可以生成本地根证书并安装到系统信任列表里，让浏览器完全信任自签名证书，体验和正式证书几乎一样。但在那之前，先把最基础的自签名方案跑通，理解链路是怎么走的。

2. 环境准备与证书生成实操

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

Nginx的安装很简单，不同操作系统各有各的装法，我把自己用过的几种列出来供参考。Linux系（Ubuntu/Debian）用apt即可：

sudo apt update sudo apt install nginx

CentOS/RHEL用yum或dnf：

sudo yum install nginx

macOS用户有Homebrew最方便：

brew install nginx

Windows用户可以直接去Nginx官网下载Windows版本，解压后执行nginx.exe就能跑起来，但Windows下把它注册成服务稍微麻烦点，建议优先用WSL或者虚拟机做测试。

安装完成后，建议先确认一下服务和版本：

nginx -v sudo systemctl status nginx

把Nginx跑起来后，浏览器访问http://localhost如果能出现Nginx欢迎页，说明基础环境没问题。这里有一个小坑，就是80端口被占用会导致Nginx启动失败，排查的时候可以先执行sudo lsof -i:80看看是谁占着端口。

2.2 用OpenSSL生成自签名证书的完整命令

证书生成的工具就是OpenSSL，几乎所有Linux和macOS都自带。没有的话可以用sudo apt install openssl或者brew install openssl补上。生成证书前，我习惯建一个专门的目录收拾证书文件，别堆在/etc/nginx下乱七八糟的：

sudo mkdir -p /etc/nginx/ssl cd /etc/nginx/ssl

然后生成自签名证书和私钥，核心命令如下：

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout nginx-selfsigned.key \ -out nginx-selfsigned.crt \ -subj "/C=CN/ST=Beijing/L=Beijing/O=DevLocal/OU=IT/CN=localhost" \ -addext "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:192.168.1.10"

这里每个参数都简单解释一下。-x509表示直接生成自签名证书而不是证书签名请求；-nodes表示私钥不加密，这样Nginx启动时不用我们手动输密码，这个在自动化启动场景下很关键；-days 365表示证书有效期一年；-newkey rsa:2048生成一个2048位的RSA私钥，强度足够日常开发用；-subj是证书的主体信息，里面的CN=localhost会作为默认匹配的域名；最后那个-addext是重中之重，它给证书加了Subject Alternative Name扩展，写明了这个证书同时也匹配localhost、127.0.0.1和你局域网的IP。

为什么要特别强调SAN这个参数？因为新版的Chrome和Firefox已经不再信任不含SAN扩展的证书，如果你偷懒只写-subj不写-addext，浏览器会直接提示"证书链无效"或者"NET::ERR_CERT_COMMON_NAME_INVALID"，就算点继续都很难进去。这是一个相当容易踩的坑，我最早做的时候就是少了这一步，折腾了半小时才反应过来。生成完可以用下面命令看一眼证书内容：

openssl x509 -in nginx-selfsigned.crt -text -noout | grep -A 1 "Subject Alternative Name"

能看到DNS:localhost, IP Address:127.0.0.1, IP Address:192.168.1.10这样的输出，就说明证书的SAN已经加进去了。

2.3 证书文件的安全权限设置

这一步很多人会忽略，但实际很重要。私钥文件一旦泄露，相当于你HTTPS加密的大门钥匙被人复制了，所以在生成完证书后我习惯把私钥权限收紧：

sudo chmod 600 nginx-selfsigned.key sudo chmod 644 nginx-selfsigned.crt

私钥文件权限是600，只有root能读写；证书文件是644，因为证书本身是公开的，Web服务器进程需要读取它，不能设太严。Nginx的worker进程通常以nginx用户运行，但它启动时读配置文件用的是root权限，所以636这种极端权限反而可能出问题。保持上述权限后，启动阶段不会遇到权限拒绝的报错。

3. 核心Nginx配置：HTTP强制跳转HTTPS

3.1 一份可用的完整配置模板

安装和证书准备好以后，重点就落在nginx的配置上了。Nginx的配置入口是nginx.conf，如果嫌主配置文件太长，可以在conf.d目录下新建一个文件，例如local-https.conf，然后在nginx.conf的http块里把该目录include进来。Debian系的Nginx默认就有/etc/nginx/sites-available和/etc/nginx/sites-enabled的方案，我们用哪种都行，本质是一样的。

下面这份配置是我手写精简过的，直接复制后改改后端端口就能用：

server { listen 80; listen [::]:80; server_name localhost 192.168.1.10; return 301 https://$host$request_uri; } server { listen 443 ssl; http2 on; server_name localhost 192.168.1.10; ssl_certificate /etc/nginx/ssl/nginx-selfsigned.crt; ssl_certificate_key /etc/nginx/ssl/nginx-selfsigned.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; } }

这里我假设后端的本地业务服务跑在8080端口，比如一个Spring Boot服务、一个Node.js服务或者一个Flask应用。你只需要把proxy_pass里的端口改成你真正的服务端口就行。

3.2 配置拆解：80跳转块和443监听块各自做了什么

上面这份配置其实就是两个server块，一个是80端口的入口，一个是443端口的入口。第一个server块监听80端口，收到请求后执行return 301 https://$host$request_uri;，意思就是告诉浏览器：这个页面已经永久迁移到HTTPS地址了，请直接去新的HTTPS链接。$host变量会自动替换成你请求里的域名或IP，$request_uri会带上原始路径和查询参数，所以从http://localhost:80/foo?bar=1会被完整跳转到https://localhost/foo?bar=1，参数一个都不会丢。

为什么不直接把80端口的请求转发到443端口里呢？return 301是标准做法，搜索引擎和客户端都能理解「这个网址以后都用HTTPS」。而且301跳转是永久性的，浏览器会记住这个跳转，下次直接访问HTTPS，减小一次不必要的往返。

第二个server块是核心。listen 443 ssl;告诉Nginx这个server块专门处理443端口的SSL连接；http2 on;开启HTTP/2协议，多路复用能明显提升本地请求并发时的体验；ssl_certificate和ssl_certificate_key指向我们刚才生成的两个文件；ssl_protocols TLSv1.2 TLSv1.3;表示只启用这两个较新且安全的TLS版本，老旧的TLSv1.0和TLSv1.1有已知漏洞，本地开发也没必要兼容古董客户端。

location /块里的proxy_pass http://127.0.0.1:8080;才是真正的反向代理转发，它把443端口收到的HTTPS请求解密之后，再以HTTP协议转发给本机的8080端口。后面几行proxy_set_header非常重要，它们把原始请求的信息传递给后端，特别是X-Forwarded-Proto $scheme，这个头告诉后端请求原来是HTTPS协议进来的，后端如果要做协议相关的逻辑判断（比如生成回调地址、重定向地址），就需要看这个头才知道该返回HTTPS链接而不是HTTP链接。后面这几个头也是同样的道理。

3.3 校验配置并加载生效

配置改完之后，千万不要直接重启Nginx，先跑一遍语法检查：

sudo nginx -t

如果输出nginx: configuration file /etc/nginx/nginx.conf test is successful，说明配置格式没问题。接着执行：

sudo systemctl reload nginx

reload是平滑重载，它不会中断正在处理的请求，只是让Nginx重新读取配置。如果改坏了或者端口被占用，reload时会报错并且保持旧配置继续运行，这是个比较安全的机制。

3.4 局域网内其他设备访问时的配置要点

本地环境跑通之后，很多人接下来就想让同一局域网下的手机或者另一个电脑访问。这一步除了Nginx配置外，还有几个容易忽略的细节。首先Nginx如果监听的是listen 443 ssl;，默认会同时绑定0.0.0.0:443，也就是所有网卡接口，理论上局域网设备可以访问。但如果你的配置文件里写的是listen 127.0.0.1:443 ssl;，那就只有本机能访问了，这个问题出现过不少次。

其次是系统防火墙，Ubuntu的ufw、CentOS的firewalld都可能在默默拦着端口。放行443：

sudo ufw allow 443 # 或者 sudo firewall-cmd --permanent --add-port=443/tcp && sudo firewall-cmd --reload

最后是证书里的SAN要包含你访问时用的IP，这点在生成证书那一步已经加入了IP:192.168.1.10，所以局域网设备访问https://192.168.1.10时证书匹配上，只有一个不受信任的警告，不会有域名不匹配的额外报错。如果手机连不上，先用电脑在同一个WiFi下ping一下这个IP，再把后端服务的host从127.0.0.1改成0.0.0.0，因为有些开发服务器默认只监听localhost。

4. 启动验证与常见问题排查实录

4.1 验证跳转是否生效的几个命令

配置好了，验证环节要系统一点，别光靠浏览器看一下就完事。我一般会按顺序跑这几条命令。

第一条，验证80端口能否按预期跳转：

curl -I http://localhost

如果配置正确，返回的HTTP状态码应该是301 Moved Permanently，并且响应头里的Location字段是https://localhost/，这就说明HTTP到HTTPS的强制跳转已经在工作了。

第二条，验证443端口的TLS握手是否正常：

curl -k https://localhost

这里的-k表示忽略证书不受信任的报错，如果后端服务正常，你会看到后端应用返回的内容。如果看到curl: (60) SSL certificate problem之类的内容，别慌，这正是自签名证书没有被curl信任的正常表现，用-k绕过即可。

第三条，用OpenSSL工具检查证书链：

openssl s_client -connect localhost:443 -servername localhost

这条命令会输出一大段TLS握手信息，包括证书序列号、签发者、加密套件、协议版本等，你可以从中确认证书是否被正常加载、TLS版本是否匹配。

浏览器端验证更直观。访问http://localhost会立刻跳转到https://localhost，出现警告页后依次点“高级-继续前往”，就能看到后端服务的页面。若一切正常，地址栏左侧有一个小锁图标但带横线，表示证书不受信任，但连接是加密的，这个状态在本地开发场景下是完全可用的。

4.2 常见报错现象与解决办法速查表

在实际操作中，各步骤的报错五花八门，我把这几年见过的高频错误和排查思路整理成了表格，按现象查原因最省事。

4.3 进阶方案：用mkcert让浏览器完全信任自签名证书

如果你实在受不了浏览器每次弹出的警告页，这里有一个很成熟的本地开发方案：mkcert。它的原理是生成本地根证书，然后把这根证书安装到系统的信任列表里，之后mkcert签出来的自签名证书就会被浏览器当作合法证书，不再有警告。安装和使用都很简洁：

brew install mkcert # macOS # 或者 sudo apt install libnss3-tools mkcert -install mkdir -p /etc/nginx/ssl && cd /etc/nginx/ssl mkcert localhost 127.0.0.1 192.168.1.10

执行完后，当前目录会出现localhost+2.pem和localhost+2-key.pem两个文件，把nginx配置里的ssl_certificate和ssl_certificate_key指向它们，reload一下Nginx，再用浏览器访问，地址栏就是一把正常的小锁了，这在调试一些对安全上下文有严格要求的浏览器API时非常有用。

需要注意，mkcert的根证书装进了系统信任库，只影响本机信任链，局域网里的其他设备如果不安装这个根证书，依然会看到警告。所以在多设备联调时，要么每台设备都装一次根证书，要么就用上一节里的-k方案忍受警告。

4.4 补充场景：Nginx反向代理WebSocket的配置

本地开发时如果后端服务里有WebSocket接口，比如一些热更新工具、在线协作应用，简单拷贝上面的location配置会发现WebSocket握手总是失败。原因在于WebSocket协议升级需要传Upgrade和Connection两个请求头，Nginx默认不会透传，需要在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_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

这里关键就是proxy_http_version 1.1和那两行头信息。HTTP/1.0不支持WebSocket，Nginx默认使用HTTP/1.0转发，所以必须显式设为1.1。如果你要转发的服务路径不止/ws/一个，可以把WebSocket单独放在一个location，其他HTTP请求走普通的location，两个块互不干扰。

这种情况下，前端代码连接WebSocket时也要用wss://localhost/ws/xxx而不是ws://localhost/ws/xxx，因为外面整条链路已经HTTPS了，明文WebSocket会被浏览器拦截。这是一个特别容易漏的细节，前端控制台会报Mixed Content: The page at 'https://...' was loaded over HTTPS, but attempted to connect to an insecure WebSocket endpoint，排查半天才发现是ws和wss用错了。

4.5 给本地HTTPS环境预留的排错小技巧

如果页面打开后还是各种不对，最后分享一个通用的排查思路。先在浏览器开发者工具的Network面板里看请求是不是全部走的https，被浏览器拦掉的http资源会直接显示为blocked；再在控制台看有没有混合内容提示。然后去Nginx的访问日志和错误日志里找线索：

sudo tail -f /var/log/nginx/access.log sudo tail -f /var/log/nginx/error.log

错误日志里常见的SSL_do_handshake() failed大多是因为客户端用了老旧的协议，不是配置问题；upstream timed out说明Nginx连不上后端端口，先确认后端服务有没有起来、监听的是不是127.0.0.1:8080。如果日志全部正常但页面还是不对，用curl -k -v https://localhost -H "Host: localhost"打印完整请求过程，一般能定位到是TLS阶段的问题还是后端响应的问题。

这整个方案我在本地联调中用过很多回，最大的感受是：Nginx做HTTP转HTTPS的成本极低，真正花时间的全是证书信任和细节转发这一类的小问题。只要把证书文件和location头信息这两块搞明白，后面换端口、换域名都只是改个参数的事。如果你在配置过程中遇到什么奇怪的报错，先对照上面的排查表一条条过，大概率不用折腾太久。