企业官网 Nginx 部署完整流程：HTTPS、301、静态缓存与日志配置

企业官网开发完成后，"页面能打开"并不等于部署完成。

真正上线时，至少还要处理：

• 域名解析

• Nginx Server 配置

• HTTP 跳转 HTTPS

• www / 非 www 统一

• SSL 证书

• 静态资源缓存

• Gzip 压缩

• 反向代理或 PHP-FPM

• 访问日志与错误日志

• 404 / 50x

• 安全响应头

• 配置检查与平滑重载

下面以一个典型企业官网为例，整理一套相对完整的 Nginx 部署流程。

---

一、先明确网站部署结构

一个常见企业官网的访问链路大致是：

用户浏览器
    ↓
DNS
    ↓
80 / 443
    ↓
Nginx
    ↓
├── 静态文件 HTML / CSS / JS / 图片
├── PHP-FPM
└── Node.js / Java / API 服务
    ↓
数据库 / Redis / 对象存储

Nginx 在这里主要承担几个角色：

1. Web Server

2. HTTPS 入口

3. 301 跳转

4. 静态资源服务器

5. 反向代理

6. 缓存控制

7. 日志记录

8. 部分基础安全控制

企业官网部署是否稳定，Nginx 配置非常关键。

---

二、准备网站目录

假设域名为：

www.example.com

网站目录：

/www/wwwroot/www.example.com/

推荐结构：

/www/wwwroot/www.example.com/
├── public
├── uploads
├── storage
├── logs
└── backup

如果是 ThinkPHP、Laravel 等框架，真正 Web Root 一般不要直接指向项目根目录，而应该指向：

/public

例如：

root /www/wwwroot/www.example.com/public;

这样可以避免：

.env
composer.json
vendor
application
config

等敏感文件被直接访问。

---

三、先配置最基本的 HTTP 站点

最简单的 Nginx Server 可以这样写：

server {
    listen 80;
    server_name example.com www.example.com;

    root /www/wwwroot/www.example.com/public;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

先不要急着配置 HTTPS。

第一步应该确认：

nginx -t

返回：

syntax is ok
test is successful

然后重载：

nginx -s reload

这时先通过 HTTP 测试网站是否正常。

---

四、统一域名：www 还是非 www？

企业官网建议只保留一个主域名。

例如统一使用：

https://www.example.com

那么：

http://example.com
http://www.example.com
https://example.com

最终全部应该跳转到：

https://www.example.com

这不仅是用户体验问题，也关系到 SEO。

如果多个 URL 都可以访问相同页面，搜索引擎可能认为存在重复页面。

---

五、HTTP 统一 301 到 HTTPS

80 端口可以单独写一个 Server：

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://www.example.com$request_uri;
}

这里：

$request_uri

非常重要。

例如用户访问：

http://example.com/products?id=100

会跳转到：

https://www.example.com/products?id=100

参数不会丢失。

---

六、HTTPS 主站配置

HTTPS 主站可以这样写：

server {
    listen 443 ssl;
    server_name www.example.com;

    root /www/wwwroot/www.example.com/public;
    index index.html index.htm index.php;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

证书通常包含：

fullchain.pem
privkey.pem

修改配置后先检查：

nginx -t

确认无误再：

nginx -s reload

---

七、非 www HTTPS 也要跳转

仅仅处理 80 端口还不够。

如果用户访问：

https://example.com

也应该跳转。

可以单独建立：

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

最终形成：

http://example.com
        ↓
http://www.example.com
        ↓
https://example.com
        ↓
https://www.example.com

准确地说，前三种都直接跳向最后一个主域名。

---

八、PHP 网站如何连接 PHP-FPM

如果企业官网使用 PHP，可以加入：

location ~ \.php$ {
    include fastcgi_params;

    fastcgi_pass unix:/run/php/php8.2-fpm.sock;

    fastcgi_index index.php;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

不同服务器 PHP-FPM 地址可能不同，例如：

/run/php/php8.2-fpm.sock

也可能是：

127.0.0.1:9000

例如：

fastcgi_pass 127.0.0.1:9000;

部署后如果出现：

502 Bad Gateway

第一件事就是检查：

systemctl status php8.2-fpm

以及：

ls /run/php/

确认 PHP-FPM 是否运行、Socket 是否一致。

---

九、Node.js 网站如何反向代理

如果前端或后台是：

Node.js
Next.js
Nuxt
NestJS

通常程序自己监听：

127.0.0.1:3000

Nginx 再做代理：

location / {
    proxy_pass http://127.0.0.1:3000;

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

链路变成：

Browser
   ↓
HTTPS
   ↓
Nginx
   ↓
Node.js :3000

Node.js 不需要直接暴露公网 3000 端口。

---

十、静态资源缓存应该怎么配

企业官网的大部分流量实际上来自：

图片
CSS
JS
字体
WebP
SVG

这些文件如果每次都重新请求，会浪费大量带宽。

可以配置：

location ~* \.(jpg|jpeg|png|gif|webp|svg|ico)$ {
    expires 30d;
    add_header Cache-Control "public";
}

CSS / JS：

location ~* \.(css|js)$ {
    expires 7d;
    add_header Cache-Control "public";
}

字体：

location ~* \.(woff|woff2|ttf|otf)$ {
    expires 30d;
    add_header Cache-Control "public";
}

---

十一、为什么不能所有文件都缓存 30 天？

这是实际项目中经常踩的坑。

例如：

location ~* \.(css|js)$ {
    expires 30d;
}

如果文件名一直是：

main.css
app.js

更新后用户可能依旧读取旧缓存。

更好的做法是构建阶段加入 hash：

main.a83f91.css
app.719bd3.js

内容发生变化以后，文件名也变化。

这时才适合：

expires 365d;

例如：

location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

所以：

缓存时间不是越长越好，而是要配合静态资源版本管理。

---

十二、HTML 页面不要缓存太久

对于企业官网首页、新闻、产品页面，不建议简单配置：

30d
365d

否则企业更新页面以后，部分用户可能迟迟看不到新内容。

例如 HTML 可以：

location ~* \.html$ {
    expires -1;
    add_header Cache-Control "no-cache";
}

动态页面则主要由程序、FastCGI Cache 或 CDN 控制。

---

十三、开启 Gzip 压缩

文本资源开启 Gzip 后，一般能明显减少传输体积。

例如：

gzip on;

gzip_comp_level 5;

gzip_min_length 1024;

gzip_types
    text/plain
    text/css
    application/json
    application/javascript
    application/xml
    image/svg+xml;

对于：

HTML
CSS
JS
JSON
SVG

效果比较明显。

但对于已经压缩过的：

JPEG
WebP
MP4
ZIP
PDF

通常没有必要再次压缩。

---

十四、限制敏感文件访问

企业官网经常会存在：

.env
.git
.svn
.sql
.log

这些文件不应该被浏览器访问。

可以加入：

location ~ /\.(?!well-known) {
    deny all;
}

再单独限制：

location ~* \.(env|ini|log|sql|bak|conf)$ {
    deny all;
}

部署以后建议直接测试：

https://www.example.com/.env
https://www.example.com/.git/config

正常应该无法访问。

---

十五、404 页面也需要处理

企业官网经常有产品删除、新闻下线、URL 调整等情况。

建议定义：

error_page 404 /404.html;

例如：

location = /404.html {
    internal;
}

更重要的是：

不存在的页面必须真正返回 HTTP 404。

不能访问一个错误 URL：

/product/abc-does-not-exist

页面显示：

页面不存在

但 HTTP Status 却是：

200 OK

这种 Soft 404 对 SEO 不友好。

可以使用：

curl -I https://www.example.com/abc-test-404

检查。

正常应该看到：

HTTP/2 404

---

十六、配置访问日志和错误日志

企业网站上线以后，日志非常重要。

建议单独配置：

access_log /var/log/nginx/example_access.log;
error_log  /var/log/nginx/example_error.log warn;

完整一点：

server {

    listen 443 ssl;
    server_name www.example.com;

    access_log /var/log/nginx/example_access.log;
    error_log /var/log/nginx/example_error.log warn;

}

网站出现：

404
403
500
502
504

时，日志往往是最快的排查入口。

---

十七、最常用的实时日志排查方法

查看访问日志：

tail -f /var/log/nginx/example_access.log

查看错误日志：

tail -f /var/log/nginx/example_error.log

查看最近 100 行：

tail -n 100 /var/log/nginx/example_error.log

查 404：

grep " 404 " /var/log/nginx/example_access.log

查 500：

grep " 500 " /var/log/nginx/example_access.log

查某个 IP：

grep "1.2.3.4" /var/log/nginx/example_access.log

企业官网被扫描、攻击或者突然出现异常流量时，这些命令都非常实用。

---

十八、建议自定义 Log Format

默认日志信息有时候不够。

可以增加：

log_format main
    '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" '
    '"$http_user_agent" '
    '$request_time';

然后：

access_log /var/log/nginx/example_access.log main;

其中：

$request_time

尤其有价值。

例如日志：

GET /products/100 200 2.835

说明整个请求耗时：

2.835 秒

如果很多动态页面都是：

2s
3s
5s

就不能只怪 CDN，可能需要继续检查：

PHP
MySQL
接口
第三方 API

---

十九、建议增加几个基础安全响应头

可以加入：

add_header X-Content-Type-Options "nosniff" always;

add_header X-Frame-Options "SAMEORIGIN" always;

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

例如：

server {

    listen 443 ssl;

    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

}

注意：

Content-Security-Policy 不建议直接照抄网上配置。

因为企业网站可能包含：

Google Analytics
Google Maps
YouTube
在线客服
验证码
第三方字体
营销脚本

CSP 配错以后，很容易把正常资源也拦掉。

建议根据实际资源逐步配置。

---

二十、一个相对完整的 Nginx 示例

以 PHP 企业官网为例：

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://www.example.com$request_uri;
}


server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}


server {
    listen 443 ssl;
    server_name www.example.com;

    root /www/wwwroot/www.example.com/public;
    index index.php index.html;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    access_log /var/log/nginx/example_access.log;
    error_log  /var/log/nginx/example_error.log warn;

    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    gzip on;
    gzip_comp_level 5;
    gzip_min_length 1024;

    gzip_types
        text/plain
        text/css
        application/json
        application/javascript
        application/xml
        image/svg+xml;


    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }


    location ~ \.php$ {
        include fastcgi_params;

        fastcgi_pass unix:/run/php/php8.2-fpm.sock;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }


    location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|woff|woff2)$ {
        expires 30d;
        add_header Cache-Control "public";
    }


    location ~* \.(css|js)$ {
        expires 7d;
        add_header Cache-Control "public";
    }


    location ~ /\.(?!well-known) {
        deny all;
    }


    location ~* \.(env|ini|log|sql|bak|conf)$ {
        deny all;
    }


    error_page 404 /404.html;

    location = /404.html {
        internal;
    }
}

这只是一个基础模板。

真实项目还需要根据：

PHP框架
Node.js
WordPress
ThinkPHP
Laravel
CDN
WAF
对象存储
多语言
后台路径
文件上传方式

继续调整。

---

二十一、修改 Nginx 后，不要直接 Restart

每次修改配置以后，第一步一定是：

nginx -t

成功以后：

nginx -s reload

或者：

systemctl reload nginx

尽量不要动不动：

systemctl restart nginx

reload 会让 Nginx 重新加载配置，同时尽量保持已有连接继续处理。

对于线上企业官网来说更加稳妥。

---

二十二、上线以后建议做一轮完整验证

网站正式发布后，我一般建议至少检查下面这些地址：

http://example.com
http://www.example.com

https://example.com
https://www.example.com

最终应该只留下一个主地址，例如：

https://www.example.com

然后继续验证：

curl -I http://example.com

查看：

301

再测试：

curl -I https://www.example.com

查看：

200

还要测试：

404
HTTPS
静态缓存
响应时间
移动端
表单
后台
图片
下载文件

---

二十三、Nginx 配好了，为什么网站还是慢？

这是企业官网运维中非常常见的问题。

Nginx 只是整个链路的一部分。

网站慢还可能来自：

DNS
CDN
服务器带宽
PHP
Node.js
MySQL
Redis
图片体积
第三方 JS
Google Fonts
海外 API
前端渲染

所以排查网站速度时，不能看到：

Nginx 正常运行

就认为服务器端没有问题。

应该把完整链路拆开：

DNS
 ↓
TCP / TLS
 ↓
Nginx
 ↓
Application
 ↓
Database
 ↓
HTML
 ↓
CSS / JS / Image

逐层定位。

---

二十四、部署不是最后一步，长期运维才是

企业官网上线以后，还需要长期关注：

SSL 到期时间
服务器磁盘
CPU / 内存
数据库备份
访问日志
错误日志
异常流量
程序漏洞
PHP / Node 版本
CDN 缓存
网站速度

尤其制造业和外贸企业官网，网站往往要运行很多年。

所以一个完整的网站建设项目，不能只包含：

设计 + 前端

更合理的是：

策划
 ↓
设计
 ↓
前端
 ↓
后台
 ↓
数据库
 ↓
Nginx / Server
 ↓
HTTPS
 ↓
CDN
 ↓
备份
 ↓
监控
 ↓
长期维护

这才是企业官网真正完整的技术交付链路。

---

实际项目中的经验

杭州派迪科技在企业官网、制造业网站和外贸英文网站项目中，网站上线阶段通常不仅处理页面和程序，还会继续检查 Nginx、HTTPS、301、缓存、服务器环境、备份以及后续运维。

很多网站刚上线时看不出区别。

真正运行几个月甚至几年以后，服务器配置是否规范、日志是否完整、备份是否可靠、技术团队还能不能继续维护，才会逐渐体现出来。

所以企业官网部署完成的标准，不应该只是：

网站能打开。

而应该是：

网站能稳定、安全、可维护地长期运行。

这才是 Nginx 部署真正需要解决的问题。