一文带你搞懂如何设置Nginx开机自启动(systemd 方式)

更新时间：2026年07月08日 09:20:33 作者：知远漫谈

本文将带你从零开始,深入理解 systemd 的工作原理,手把手教你配置 Nginx 开机自启动,并结合真实 Java 应用场景,演示如何构建一个“Nginx + Spring Boot + MySQL”的完整高可用架构,有需要的可以了解下

在现代 Linux 服务器运维中，Nginx 作为高性能的 Web 服务器和反向代理，早已成为不可或缺的核心组件。无论是部署 Java Web 应用、静态资源服务，还是作为 API 网关，Nginx 都以其轻量、稳定、高并发的特性赢得了开发与运维团队的广泛信赖。然而，一个看似简单的问题常常被忽视：当服务器重启后，Nginx 是否能自动恢复运行？

答案是：不能默认自动启动，除非你明确配置了开机自启动机制。在传统 SysV init 系统时代，我们通过 chkconfig 或 update-rc.d 来管理服务；而在当今主流的 Linux 发行版（如 CentOS 7+、Ubuntu 16.04+、Debian 9+）中，systemd 已成为标准的系统和服务管理器。掌握如何使用 systemd 配置 Nginx 开机自启动，不仅是运维的基本功，更是保障服务高可用性的关键一步。

本文将带你从零开始，深入理解 systemd 的工作原理，手把手教你配置 Nginx 开机自启动，并结合真实 Java 应用场景，演示如何构建一个“Nginx + Spring Boot + MySQL”的完整高可用架构。我们将通过代码示例、架构图、配置解析和故障排查技巧，让你不仅“会配置”，更“懂原理”。

为什么需要开机自启动？

想象一下这样一个场景：

你是一名 Java 开发工程师，负责公司核心业务系统的部署。你精心优化了 Spring Boot 应用的性能，配置了数据库连接池、线程池、缓存策略，甚至使用了 Prometheus + Grafana 做了全链路监控。一切看起来完美无缺。

直到某天深夜，机房突发断电，服务器意外关机。第二天早上，运维同事发现：

数据库服务已自动恢复（因为配置了 systemd 自启动）；
Redis 缓存也正常运行；
但你的 Java 应用无法访问 —— 因为它依赖的 Nginx 没有启动！

用户投诉：“网站打不开！”

产品经理追问：“为什么上次升级后总是出问题？”

你只能无奈地登录服务器，手动执行：

sudo systemctl start nginx

然后默默在心里记下：“下次一定要配置开机自启。”

这不是技术问题，这是责任心问题。一个没有自启动能力的服务，就像一辆没有自动点火的跑车——再快，也得靠人推。

小贴士：在生产环境中，任何核心服务（Nginx、Java 应用、Redis、MySQL、RabbitMQ）都必须配置开机自启动。这是 DevOps 的“最低道德标准”。

systemd 是什么？它为什么重要？

systemd 是 Linux 系统中用于初始化、管理和监控系统服务的守护进程。它于 2010 年由 Lennart Poettering 发起，如今已被绝大多数主流 Linux 发行版采用，取代了传统的 SysV init 系统。

systemd 的优势包括：

并行启动服务：不再像 SysV 那样串行启动，大幅提升开机速度；
依赖管理：服务之间可以声明依赖关系，比如“Nginx 依赖网络和 MySQL”；
日志统一管理：通过 journalctl 统一查看所有服务日志；
资源控制：可限制 CPU、内存、文件句柄等资源；
进程监控：自动重启崩溃的服务；
灵活的单元配置：通过 .service 文件定义服务行为。

systemd 的核心概念

概念	说明
Unit	systemd 管理的基本对象，如服务（service）、套接字（socket）、目标（target）等
Service Unit	描述一个后台服务的配置文件，扩展名为 `.service`
Target	类似于运行级别（runlevel），如 `multi-user.target` 相当于传统 runlevel 3
Wants / Requires	服务之间的依赖声明方式，`Wants` 是弱依赖，`Requires` 是强依赖
ExecStart	启动服务时执行的命令
Restart	服务崩溃后是否自动重启，如 `always`, `on-failure`

检查当前 Nginx 状态

在配置自启动之前，我们先确认当前 Nginx 的运行状态。

1. 查看 Nginx 是否已安装

which nginx
# 输出示例：/usr/sbin/nginx

nginx -v
# 输出示例：nginx version: nginx/1.24.0

如果未安装，请先安装：

# Ubuntu/Debian
sudo apt update && sudo apt install nginx

# CentOS/RHEL
sudo yum install epel-release -y
sudo yum install nginx -y

# 或使用 dnf（较新版本）
sudo dnf install nginx -y

2. 检查 Nginx 是否正在运行

sudo systemctl status nginx

输出示例：

● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2024-03-18 10:22:33 CST; 2h 15min ago
Main PID: 1234 (nginx)
Tasks: 6 (limit: 4915)
Memory: 5.2M
CGroup: /system.slice/nginx.service
├─1234 nginx: master process /usr/sbin/nginx -g daemon off;
└─1235 nginx: worker process

关键字段解释：

Loaded：服务单元文件是否被加载
Enabled：是否设置为开机自启（enabled 表示是，disabled 表示否）
Active：当前是否运行
Main PID：主进程 ID

3. 查看服务单元文件位置

systemctl show nginx --property=UnitFileState
# 输出：UnitFileState=enabled

systemctl cat nginx

systemctl cat nginx 会显示服务文件的完整内容，通常位于：

/lib/systemd/system/nginx.service

Nginx 默认服务文件解析

运行 systemctl cat nginx，你可能会看到类似如下内容（以 Ubuntu 22.04 为例）：

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s stop
PrivateTmp=true
[Install]
WantedBy=multi-user.target

字段详解

1.[Unit]部分

Description：服务描述，用于 systemctl list-units 显示
After=network.target：表示 Nginx 在网络服务启动后才启动。这是非常关键的一行！如果没有它，Nginx 可能在网络未就绪时尝试绑定端口 80，导致启动失败。

注意：network.target 并不等于“网络完全可用”。它只表示网络接口已激活。对于依赖 DNS 解析的服务，建议使用 network-online.target（需 systemd-networkd-wait-online.service 支持）。

2.[Service]部分

Type=forking：Nginx 启动时会 fork 一个子进程作为 master，父进程退出。这与 Type=simple（直接运行主进程）不同。
PIDFile：指定 PID 文件路径，systemd 通过此文件追踪主进程。
ExecStartPre：启动前执行的命令，常用于配置文件语法检查（nginx -t）。
ExecStart：实际启动命令。
ExecReload：重载配置命令。
ExecStop：停止命令。
PrivateTmp=true：为服务创建独立的临时目录，提高安全性。

3.[Install]部分

WantedBy=multi-user.target：表示当系统进入多用户模式（即正常登录状态）时，启动此服务。

你可能注意到：默认的 Nginx 服务文件已经配置了开机自启！那为什么我们还要写这篇文章？

因为——很多情况下，这个服务文件被误删、被覆盖、或被禁用。尤其是在使用非官方包（如源码编译安装）、Docker 容器、或云平台镜像时，systemd 单元文件可能缺失或未启用。

手动启用 Nginx 开机自启动

如果你发现 systemctl status nginx 显示 Enabled: disabled，或服务文件缺失，你需要手动启用。

步骤 1：确认服务文件存在

ls -l /lib/systemd/system/nginx.service
# 或
ls -l /etc/systemd/system/nginx.service

如果文件不存在，你需要创建它。

步骤 2：创建或修复 nginx.service 文件

使用编辑器创建服务文件：

sudo nano /etc/systemd/system/nginx.service

粘贴以下内容（推荐版本，兼容性强）：

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s stop
Restart=on-failure
RestartSec=5s
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

关键改进点说明

项目	说明
`After=network.target network-online.target`	更严格地等待网络完全可用，避免启动失败
`Wants=network-online.target`	声明弱依赖，提高启动可靠性
`Restart=on-failure`	服务异常退出时自动重启，提升可用性
`RestartSec=5s`	重启前等待 5 秒，避免频繁重启导致系统负载飙升
`LimitNOFILE=100000`	提高文件描述符限制，避免高并发下“Too many open files”错误

重要提醒：如果你是使用源码编译安装的 Nginx（非 apt/yum 安装），请确保 ExecStart、ExecStartPre 中的路径指向你实际安装的 nginx 可执行文件。例如：

ExecStart=/opt/nginx/sbin/nginx -g 'daemon on; master_process on;'

你可以通过 which nginx 确认路径。

步骤 3：重新加载 systemd 配置

sudo systemctl daemon-reload

这是最关键的一步！每次修改 .service 文件后，都必须执行此命令，否则 systemd 不会读取新配置。

步骤 4：启用开机自启动

sudo systemctl enable nginx

输出：

Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /etc/systemd/system/nginx.service.

步骤 5：验证是否启用成功

systemctl is-enabled nginx
# 输出：enabled

步骤 6：启动 Nginx（如果未运行）

sudo systemctl start nginx

步骤 7：设置开机启动日志记录（可选）

为了便于排查启动失败问题，建议开启 systemd 日志持久化：

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

之后你可以用 journalctl 查看 Nginx 启动日志：

journalctl -u nginx --since today

实战：Java 应用 + Nginx 高可用架构设计

现在我们进入实战环节。假设你有一个 Spring Boot Java 应用，部署在一台 CentOS 服务器上，需要通过 Nginx 作为反向代理对外提供服务，并确保服务器重启后，Nginx 和 Java 应用都能自动启动。

架构图示意（Mermaid）

这是一个典型的微服务前端网关架构：Nginx 处理静态资源、负载均衡、SSL 终止，Java 应用专注业务逻辑。

Java 应用部署示例（Spring Boot）

假设你的 Java 应用打包为 myapp.jar，部署在 /opt/myapp/ 目录下。

1. 创建 Java 服务单元文件

sudo nano /etc/systemd/system/myapp.service

内容如下：

[Unit]
Description=My Java Spring Boot Application
After=network.target nginx.service
Wants=nginx.service
[Service]
User=appuser
Group=appgroup
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -jar -Dspring.profiles.active=prod -Xms512m -Xmx1024m -XX:+UseG1GC myapp.jar
Restart=always
RestartSec=10s
StandardOutput=journal
StandardError=journal
Environment=JAVA_OPTS=-Djava.security.egd=file:/dev/./urandom
Environment=SERVER_PORT=8080
[Install]
WantedBy=multi-user.target

2. 创建运行用户（安全最佳实践）

sudo groupadd appgroup
sudo useradd -g appgroup -s /bin/false appuser
sudo chown -R appuser:appgroup /opt/myapp

安全提示：永远不要用 root 用户运行 Java 应用！这是重大安全隐患。

3. 启用并启动 Java 服务

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

4. 检查 Java 应用是否运行

sudo systemctl status myapp
journalctl -u myapp -f  # 实时查看日志

5. Nginx 反向代理配置

编辑 Nginx 配置文件：

sudo nano /etc/nginx/conf.d/myapp.conf

内容如下：

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

    access_log /var/log/nginx/myapp-access.log;
    error_log /var/log/nginx/myapp-error.log;

    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;
        proxy_read_timeout 90s;
        proxy_connect_timeout 90s;
    }

    location /static/ {
        alias /opt/myapp/static;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location /actuator/ {
        proxy_pass http://127.0.0.1:8080/actuator/;
        allow 192.168.1.0/24;
        deny all;
    }
}

这里我们做了几件重要的事：

将 /static/ 路径直接由 Nginx 返回，减轻 Java 应用压力；
设置缓存头，提升前端性能；
限制 /actuator/ 只允许内网访问，保障安全；
使用 proxy_read_timeout 防止长连接超时。

6. 测试 Nginx 配置并重载

sudo nginx -t
sudo systemctl reload nginx

7. 验证服务链路

curl -I http://localhost
# 应该返回 200 OK

curl http://localhost/actuator/health
# 应该返回 {"status":"UP"}

高级技巧：服务依赖顺序与启动延迟

在复杂系统中，服务之间存在依赖关系。例如：

Nginx 依赖网络
Java 应用依赖 Nginx（反向代理）
Java 应用依赖 MySQL（数据库连接）

但Java 应用不应该依赖 Nginx！因为 Nginx 是反向代理，它只是转发请求，Java 应用本身不需要 Nginx 才能运行。正确的依赖关系是：

Java 应用 → MySQL / Redis
Nginx → Java 应用（通过网络访问）

但有时，我们希望“Nginx 启动后，再启动 Java 应用”，比如为了防止用户在 Java 未就绪时访问到 502 错误。

方法一：使用Wants+After（推荐）

[Unit]
Description=My Java Spring Boot Application
After=network.target mysql.service redis.service
Wants=mysql.service redis.service
[Service]
...

这样，系统会确保 MySQL 和 Redis 启动后，再启动 Java 应用。

方法二：使用ExecStartPre延迟启动（模拟等待）

如果你的 Java 应用需要等待 Nginx 完全启动（比如注册到服务发现），可以添加一个等待脚本：

[Service]
...
ExecStartPre=/bin/bash -c 'until curl -s http://127.0.0.1:80/health; do echo "Waiting for Nginx to be ready..."; sleep 5; done'
ExecStart=/usr/bin/java -jar myapp.jar

注意：这种方式会延长启动时间，仅在必要时使用。

方法三：使用 systemd 的socket activation（进阶）

你可以让 systemd 监听 80 端口，当第一个请求到来时才启动 Java 应用。但 Nginx 通常不推荐这样用，因为 Nginx 本身需要常驻监听。

故障排查指南

即使配置了开机自启动，服务仍可能启动失败。以下是常见问题和解决方案。

1. 启动失败：Job for nginx.service failed

sudo systemctl status nginx

常见错误：

错误 1：端口被占用

bind() to 0.0.0.0:80 failed (98: Address already in use)

解决：

sudo ss -tlnp | grep :80
# 查看哪个进程占用了 80 端口
sudo kill -9 <PID>
# 或修改 nginx 监听端口为 8080 测试

错误 2：配置文件语法错误

nginx: [emerg] unknown directive "xxx" in /etc/nginx/nginx.conf:xx

解决：

sudo nginx -t
# 会精确指出错误行

错误 3：权限不足（文件读取失败）

nginx: [emerg] open() "/etc/nginx/conf.d/myapp.conf" failed (13: Permission denied)

解决：

sudo chmod 644 /etc/nginx/conf.d/myapp.conf
sudo chown root:root /etc/nginx/conf.d/myapp.conf

错误 4：Java 应用启动失败（内存不足）

Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

解决：

减少 -Xmx 内存
检查系统内存：free -h
添加 swap：sudo fallocate -l 2G /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile

2. 日志分析技巧

# 查看最近 100 行 Nginx 日志
journalctl -u nginx -n 100

# 实时跟踪日志
journalctl -u nginx -f

# 查看启动时所有事件（包括失败）
journalctl -b -u nginx

# 查看特定时间范围
journalctl -u nginx --since "2024-03-18 08:00:00" --until "2024-03-18 09:00:00"

3. 服务未启动但状态显示“active”

有时服务状态是 active (running)，但你访问 80 端口却返回 502 或超时。

原因：Nginx 启动了，但后端 Java 应用没启动！

解决方案：

systemctl status myapp
# 如果是 inactive，说明 Java 应用没起来

journalctl -u myapp --since "1 hour ago"
# 查看 Java 应用启动日志

最佳实践清单

类别	推荐做法
服务文件位置	优先使用 `/etc/systemd/system/` 而非 `/lib/systemd/system/`，避免被包管理器覆盖
用户权限	Java 应用使用非 root 用户运行
日志管理	使用 `journalctl` 统一收集日志，不要依赖传统 log 文件
重启策略	设置 `Restart=always` 或 `Restart=on-failure`
资源限制	设置 `LimitNOFILE=100000`，避免高并发下文件句柄耗尽
健康检查	Java 应用暴露 `/actuator/health`，Nginx 可配合 `upstream` 做健康探测
配置测试	修改 Nginx 配置后，永远先执行 `nginx -t`
自动化部署	使用 Ansible / Terraform / Shell 脚本统一管理服务配置
备份配置	定期备份 `/etc/nginx/` 和 `/etc/systemd/system/*.service`

Java 代码示例：优雅关闭与健康检查

为了确保 Java 应用能被 systemd 正确管理，我们需要支持优雅关闭和健康端点。

1. Spring Boot 健康端点（pom.xml）

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

2. application-prod.yml 配置

server:
  port: 8080
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics
  endpoint:
    health:
      show-details: always

3. 自定义健康检查（可选）

package com.example.myapp.health;
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
import java.util.concurrent.TimeUnit;
@Component
public class DatabaseHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        try {
            // 模拟数据库连接测试
            Thread.sleep(100); // 避免过快响应
            return Health.up().withDetail("database", "connected").build();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return Health.down().withDetail("error", "interrupted").build();
        }
    }
}

4. 优雅关闭（Spring Boot 2.3+ 默认支持）

在 application.yml 中：

spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

这样，当你执行 systemctl stop myapp，Spring Boot 会等待 30 秒，让正在处理的请求完成后再关闭。

与 Docker 的区别

有人会问：既然有 Docker，为什么还要用 systemd？

场景	systemd	Docker
部署方式	原生进程	容器化
启动速度	快（无虚拟化开销）	较慢（需启动容器）
资源占用	低	高（容器运行时）
日志管理	journalctl 统一	docker logs
配置复杂度	中等	高（需编写 Dockerfile、docker-compose）
适用场景	虚拟机、物理机	微服务、K8s、CI/CD

建议：如果你的服务器是裸机或云主机（非 K8s），优先使用 systemd。它更轻量、更稳定、更易调试。

自动化脚本：一键部署 Nginx + Java 应用

下面是一个 Bash 脚本，可一键完成 Nginx 和 Java 应用的部署与自启动配置：

#!/bin/bash
# deploy-nginx-java.sh

set -e  # 遇错即停

echo "🚀 开始部署 Nginx + Java 应用..."

# 1. 安装 Nginx
if ! command -v nginx &> /dev/null; then
    echo "🔧 安装 Nginx..."
    sudo apt update
    sudo apt install -y nginx
fi

# 2. 创建 Java 应用用户
if ! id "appuser" &>/dev/null; then
    echo "👤 创建运行用户..."
    sudo groupadd appgroup
    sudo useradd -g appgroup -s /bin/false appuser
fi

# 3. 创建应用目录
APP_DIR="/opt/myapp"
mkdir -p $APP_DIR
echo "📁 创建应用目录: $APP_DIR"

# 4. 复制 JAR 文件（请替换为你的实际路径）
cp ./myapp.jar $APP_DIR/
chown appuser:appgroup $APP_DIR/myapp.jar

# 5. 创建 Java 服务文件
cat > /etc/systemd/system/myapp.service <<EOF
[Unit]
Description=My Java Spring Boot Application
After=network.target
Wants=network.target

[Service]
User=appuser
Group=appgroup
WorkingDirectory=$APP_DIR
ExecStart=/usr/bin/java -jar -Dspring.profiles.active=prod -Xms512m -Xmx1024m -XX:+UseG1GC myapp.jar
Restart=always
RestartSec=10s
StandardOutput=journal
StandardError=journal
Environment=JAVA_OPTS=-Djava.security.egd=file:/dev/./urandom

[Install]
WantedBy=multi-user.target
EOF

# 6. 创建 Nginx 配置
cat > /etc/nginx/conf.d/myapp.conf <<EOF
server {
    listen 80;
    server_name localhost;

    access_log /var/log/nginx/myapp-access.log;
    error_log /var/log/nginx/myapp-error.log;

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

    location /actuator/ {
        proxy_pass http://127.0.0.1:8080/actuator/;
        allow 127.0.0.1;
        deny all;
    }
}
EOF

# 7. 重载 systemd 和 Nginx
echo "🔄 重载 systemd 配置..."
sudo systemctl daemon-reload

echo "⚡ 启用服务..."
sudo systemctl enable nginx
sudo systemctl enable myapp

echo "🚀 启动服务..."
sudo systemctl start nginx
sudo systemctl start myapp

# 8. 检查状态
echo "📋 检查服务状态..."
systemctl status nginx --no-pager
systemctl status myapp --no-pager

echo "✅ 部署完成！访问 http://$(curl -s ifconfig.me) 查看应用"

将此脚本保存为 deploy.sh，赋予执行权限 chmod +x deploy.sh，即可一键部署。

安全加固建议

1. 防止 Nginx 被暴力破解

# 在 nginx.conf 的 http 块中添加
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req zone=api burst=20 nodelay;

2. 禁用不必要的模块

nginx -V 2>&1 | grep -i modules

移除不需要的模块（如 autoindex、ssi），减少攻击面。

3. 使用非标准端口（可选）

将 Nginx 监听端口从 80 改为 8080，前端加一层云防火墙，降低被扫描风险。

4. 定期更新

sudo apt update && sudo apt upgrade nginx

总结：你的服务，值得被认真对待

配置 Nginx 开机自启动，不是“多一步操作”，而是对系统稳定性的承诺。

你写的一行 systemctl enable nginx，可能是客户凌晨三点不投诉的关键；
你多加的一句 Restart=always，可能是服务器宕机后自动恢复的救命稻草；
你创建的 myapp.service，是你作为工程师专业性的体现。

真正的 DevOps 不是会写脚本，而是知道为什么写。

记住这句话：“一个没有自启动的服务，不是高可用的服务，只是幸运的服务。”

最后：测试你的配置是否真的生效

终极测试方法：

执行 sudo reboot
等待 2 分钟
用手机或另一台机器访问你的网站
如果页面正常加载，恭喜你！
如果没加载？立刻登录服务器，执行：

journalctl -u nginx --since "1 minute ago"
journalctl -u myapp --since "1 minute ago"

找出问题，修正，再测试。

你已经掌握了 Linux 服务管理的核心技能。从今天起，你不再是“只会敲命令”的运维，而是懂原理、能设计、可交付的系统工程师。

附录：常用命令速查表

命令	作用
`systemctl status nginx`	查看服务状态
`systemctl enable nginx`	开机自启动
`systemctl disable nginx`	取消开机自启动
`systemctl start nginx`	启动服务
`systemctl stop nginx`	停止服务
`systemctl reload nginx`	重载配置（不中断连接）
`systemctl restart nginx`	重启服务（中断连接）
`systemctl daemon-reload`	重载 systemd 配置（修改 .service 后必做）
`journalctl -u nginx -f`	实时查看日志
`nginx -t`	检查配置语法
`ss -tlnp \| grep :80`	查看 80 端口占用
`systemctl is-enabled nginx`	检查是否已启用自启动

以上就是一文带你搞懂如何设置Nginx开机自启动(systemd 方式)的详细内容，更多关于Nginx开机自启动的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

Rhit高效可视化Nginx日志查看工具
一个格式化 Nginx 日志，可快速阅读、查看 Nginx 日志的工具。可以每秒处理百万行日志数据，感兴趣的可以了解一下
2021-10-10
Nginx中防止SQL注入攻击的相关配置介绍
这篇文章主要介绍了Nginx中防止SQL注入攻击的相关配置介绍,文中提到的基本思路为将过滤的情况用rewrite重订向到404页面,需要的朋友可以参考下
2016-01-01
文件上传到服务器文件名中文乱码问题
上传附件到部署服务器,但是上传到服务器出现文件名中文乱码,中文变成（？）问号,而且在本地测试是正常的,通过打印日志发现,下面fileName乱码,本文给大家讲解文件上传到服务器文件名中文乱码问题解决方案,感兴趣的朋友一起看看吧
2024-02-02
NGINX 配置内网访问的实现步骤
本文主要介绍了NGINX 配置内网访问的实现步骤,Nginx的geo模块限制域名访问权限,仅允许内网/办公室IP访问,具有一定的参考价值,感兴趣的可以了解一下
2025-05-05
Nginx如何配置负载均衡
这篇文章主要介绍了Nginx如何配置负载均衡，帮助大家更好的理解和学习使用Nginx，感兴趣的朋友可以了解下
2021-03-03
详解Nginx + Tomcat 反向代理负载均衡集群部署指南
Nginx是一种服务器软件，也是一种高性能的http和反向代理服务器，本篇文章主要介绍了Nginx + Tomcat 反向代理负载均衡集群部署指南，有兴趣的可以了解一下。
2016-12-12
Nginx+SSL+Node.js运行环境配置教程
这篇文章主要介绍了Nginx+SSL+Node.js运行环境配置教程,本文用反向代理的方式代理基于Node.js的Web应用,需要的朋友可以参考下
2014-09-09
nginx缓存页面后串会话问题的解决方法
nginx支持页面缓存，之前我的博客有介绍配置方案，昨天出了一个诡异的问题，别人的机器登录后，我的机器打开应用的首页会出现别人的用户信息，也就是说我的浏览器访问的应用会话其实是别人的会话
2013-06-06
Nginx中轮询机制的实现
Nginx是一款优秀的Web服务器和反向代理服务器,本文主要介绍了Nginx中最基本的轮询机制的原理、配置及其优化方法,具有一定的参考价值,感兴趣的可以了解一下
2024-10-10
HipChat上传文件报未知错误的原因分析及解决方案
HipChat的功能类似于Campfire、Sazneo等在线协同工具，并且和Yammer以及Salesforce的Chatter等企业社交平台有一定相似之处。你可以为单个项目或者小组搭建自有的聊天室，也可以很方便的发起一对一聊天
2016-01-01