1Panel实战：Node+MongoDB+Nginx部署与安全加固指南-代码聚汇网

1Panel实战：Node+MongoDB+Nginx部署与安全加固指南

要上进的柯同学·2026-09-17·阅读 23 GEO检测（免费）

1PanelNode.jsMongoDB

|难度：普通|阅读约 40 分钟

1. 为什么用 1Panel 来做这套部署

先说结论：这套 Node+MongoDB+Nginx 的组合，放在 1Panel 里跑，比纯命令行手撸省心得多，也比某些老牌面板更清爽，关键是它把 Docker、数据库、网站管理揉在一起，日常维护成本能压到很低。

我在正式切换到 1Panel 之前，一直是 SSH 上去手动装 Node、配 Nginx、再搞 MongoDB，偶尔还得处理系统升级把服务搞挂的糟心事。后来项目多了，一台机器上要同时跑前端静态资源、后端 API、数据库，还要管理 SSL 证书和反向代理，手动维护的复杂度就上来了。1Panel 的出现正好补上这块：它有应用商店，Node、MongoDB、Nginx（实际是 OpenResty）都可以一键安装；有网站管理，反向代理、SSL 证书、静态站点都能在网页上完成；有数据库管理，MongoDB 可以创建库、创建用户、查看日志，基本不需要频繁登容器。

适合谁来参考？如果你手头有个 Node 项目要上线，数据库选的是 MongoDB，Web 层想用 Nginx 扛静态资源和反向代理，而且你不想在一堆命令行里反复折腾，这篇流程可以直接照着抄。已经熟悉 1Panel 的老手，也可以重点看后面的避坑章节，里面好几点是文档里不会写清楚的。

有两个点我先提前说明白：第一，1Panel 并不是把服务直接装在宿主机上，而是通过 Docker 容器跑，所以理解容器和端口映射是基础前提；第二，面板本身提供了入口，但很多细节优化还是得靠手动改配置，这篇会把这些手动部分全部标注出来。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署前准备：1Panel 安装与面板设置

2.1 服务器环境要求与安装

1Panel 对配置要求不算高，常规云服务器 1 核 2G 就能带起来，但如果你要跑 MongoDB 并且数据量不小，建议至少 2 核 4G。系统方面支持 CentOS、Ubuntu、Debian 等主流 Linux 发行版，我用的是 Ubuntu 22.04，整体兼容性很好。

安装方式很简单，官方提供了快捷安装脚本，SSH 登录服务器后执行：

bash复制curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh
sudo bash quick_start.sh

脚本运行过程中会让你选安装目录、面板端口、安全入口等，这些建议按默认走，但安装目录如果打算长期使用，最好放在数据盘，比如 /opt 或 /data，避免系统盘写满影响服务。安装完成后，命令行会输出面板访问地址、用户名、密码，记得先保存好。

安装完成后第一件事是登录面板，改掉默认密码，开启两步验证。这个环节不要跳过，面板一旦暴露在公网，弱密码很容易被扫描器盯上。

2.2 面板服务器地址必须设置

这个点很多人会忽略，也是热词里反复出现的问题：部署完成后，如果你直接在应用商店里安装应用，可能会看到类似“当前未设置服务器地址，请先在面板设置中设置”的提示。

原因很简单：面板需要知道你的服务器对外地址，才能正确生成访问链接和配置一些自动化的域名解析。有些环境会自动识别公网 IP，但如果服务器在 NAT 后面，或者你用的是内网 IP 登录的面板，它识别不到正确地址，就会报这个提示。

解决办法：进入面板的“面板设置”，找到“服务器地址”一栏，填写服务器的公网 IP 或你准备绑定的域名。如果暂时没有域名，可以先填 IP，之后绑定域名时再改。这一步不做，应用商店里某些依赖域名解析的组件就可能出问题。

2.3 防火墙端口规划

1Panel 安装后默认要放行面板端口（默认 19810 左右，按实际安装时选择的来）、80 和 443（后面 Nginx 要用）。MongoDB 默认端口 27017 如果要被本机服务访问，一般不需要对公网开放，建议只开放给内网或特定 IP。

端口规划上我踩过一次坑：早期直接把 27017 公网暴露，结果被扫描工具爆破，数据库差点被删。后来我统一原则是：数据库端口一律不映射公网，面板端口只对管理员 IP 开放，80/443 才让公网访问。安全组和云服务商防火墙两边都要配，单改一边经常导致端口不通。

3. Node 环境安装与 npm 全局配置

3.1 在 1Panel 里装 Node：版本选择和安装路径

1Panel 应用商店里可以直接安装 Node 运行环境。需要说明的是，它提供的是 Node 版本管理能力，不是单纯装一个固定版本，所以我们可以在不同项目之间切换 Node 版本，很方便。

安装过程：打开应用商店，搜索“Node”，点击安装。安装前确认好版本号，建议直接选 20 以上的 LTS 版本，比如 20.x 或 22.x。我在生产环境用的是 22.19，稳定性和兼容性都没问题，一些新语法特性也支持得更完整。Node 安装完成后，面板会展示环境变量、路径等信息，也可以在服务器上通过 node -v 确认版本。

这里补充一个常识：1Panel 里的 Node 运行环境通常也是通过容器或版本管理工具安装的，目录结构可能和你平时直接 apt 安装的不一样。遇到路径相关的问题时，用 which node 和 npm config get prefix 查清楚，别凭感觉找目录。

3.2 nvm 管理多版本 Node

如果你一台机器要跑多个项目，而且每个项目要求的 Node 版本不一样，就用 nvm 来切。1Panel 的 Node 环境模块里也集成了类似能力，但我个人习惯直接装 nvm，灵活性更高。

bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 22.19
nvm use 22.19
nvm alias default 22.19

把默认版本固定到 22.19 后，新开的终端会话自动用这个版本，不会出现项目启动时报错说找不到 Node。如果团队协作，还可以在项目根目录加一个 .nvmrc 文件，里面写 22.19.0，其他人进来执行 nvm use 就能自动切换。

3.3 Node 国内镜像源配置

国内服务器直接用 npm 官方源，速度相当折磨人。这个必须换成国内镜像源，常见的有两个：

npmmirror（原淘宝镜像）：https://registry.npmmirror.com
腾讯云镜像：https://mirrors.cloud.tencent.com/npm/

设置方式：

bash复制npm config set registry https://registry.npmmirror.com

除了 npm，建议把 pnpm 和 yarn 的镜像也一并配置。我用 pnpm 比较多，配置命令是：

bash复制pnpm config set registry https://registry.npmmirror.com

实测下来，统一走镜像源之后，npm install 的速度能提升好几倍，尤其是一些依赖数量多的项目，感受非常明显。

3.4 常见 Node 安装报错排查

这里把几个热词里反复出现的 Node 相关报错集中说下。

npm : 无法加载文件 d:\node\npm.ps1,因为在此系统上禁止运行脚本：这个报错主要出现在 Windows 机器上，原因是 PowerShell 执行策略默认禁止运行脚本。解决办法是管理员身份打开 PowerShell，执行：

powershell复制Set-ExecutionPolicy RemoteSigned

但如果你部署在 Linux 服务器上，一般不会遇到这个问题。真正的问题是权限：用 sudo npm install -g 装上全局包之后，普通用户可能找不到命令，这时候要把 npm 的全局 bin 目录加到 PATH 里。

SyntaxError: The requested module 'node:util' does not provide an export named ...：这个是 Node 版本太老导致的。node: 前缀的模块是 Node 16 以后才稳定支持，如果你还停在 14 或者更早的版本，要么升级 Node，要么用 nvm 切换到新版本。建议直接升到 22.x 一劳永逸。

Error: Cannot find module 'node:path'：同理，也是版本兼容问题。出现这类报错，优先检查当前 node -v，确认项目要求的环境版本，再用 nvm 切换。

3.5 全局安装核心工具

装完 Node 之后，我通常会顺手装几个全局工具：

bash复制npm install -g pm2 nodemon rimraf cross-env

pm2 用来守护 Node 进程，这个在生产环境几乎是标配；nodemon 是开发环境热重载用的；rimraf 解决跨平台删除目录的问题。pm2 后面会专门讲到，它是 Node 服务能稳定运行的关键一环。

4. MongoDB 安装、认证与基础操作

4.1 1Panel 安装 MongoDB：失败原因逐个拆

1Panel 应用商店里可以直接安装 MongoDB，支持选择版本。我选的是 4.4.30，这是 4.4 系列的最终版本，稳定而且兼容性极好，配合 MongoDB Compass 图形化工具使用也很顺。

但在安装过程中，很多人会遇到“安装失败”的情况。根据我自己的观察，主要有这几个原因：

第一，内存不足。MongoDB 在 Docker 容器里启动时会预分配存储引擎的空间，如果宿主机的内存小于 2G，很可能启动失败。解决方案是临时加 swap 或者换一台配置更高的机器。加 swap 的方式：

bash复制fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

第二，镜像拉取失败。Docker Hub 在国内拉取速度慢或者超时，会导致安装超时。这种情况建议给 Docker 配置国内镜像加速器，具体在 1Panel 的“设置 -> Docker 配置”里可以配置 registry-mirrors。注意不要随便填没有正规来源的加速地址，尽量选择云厂商提供的镜像服务。

第三，端口映射冲突。如果 27017 端口已经被占用，容器会创建失败。检查方式是 netstat -tlnp | grep 27017，有输出就说明被占了。改端口映射或者停掉旧的容器就行。

4.2 MongoDB 基础配置：创建用户和开启认证

安装完成后，MongoDB 默认是不需要用户名密码就能访问的，这个状态非常危险，尤其是容器端口如果映射到了公网。所以第一步就是创建管理员用户并开启认证。

进入 MongoDB 容器：

bash复制docker exec -it <mongodb-container-name> bash

进入 mongo shell：

bash复制mongosh

创建 root 用户：

javascript复制use admin
db.createUser({
  user: "admin",
  pwd: "your_strong_password",
  roles: [{ role: "root", db: "admin" }]
})

创建业务库用户：

javascript复制use your_database
db.createUser({
  user: "app_user",
  pwd: "your_app_password",
  roles: [{ role: "readWrite", db: "your_database" }]
})

然后编辑 MongoDB 配置文件，开启认证。在 1Panel 中可以查看容器的挂载目录，通常在宿主机上有对应的 conf 文件，找到 mongod.conf 或类似配置，把：

yaml复制security:
  authorization: enabled

加进去，保存后重启 MongoDB 容器。注意加的时候缩进要对，YAML 写错会导致 MongoDB 直接起不来。

4.3 MongoDB Compass 连接：连接串格式要正确

MongoDB Compass 是官方出的图形化管理工具，适合日常看数据、写查询、管理索引。连接串的格式要写对，不然会提示认证失败。

标准格式：

code复制mongodb://app_user:your_app_password@服务器IP:27017/your_database?authSource=admin

这里有个关键点：如果业务用户是在 your_database 下创建的，但认证库是 admin，那 authSource 就得填 admin。我见过不少人连接不上，就是因为这个参数没写对。

如果通过公网连接，还要确认安全组和防火墙放行了 27017 端口。但我个人还是建议用 SSH 隧道或者内网连接，不要直接把 MongoDB 暴露公网。

4.4 MongoDB 数据库基本操作

MongoDB 的基本操作，我简单罗列几个最常用的：

javascript复制// 切换/创建数据库
use your_database

// 插入数据
db.users.insertOne({ name: "张三", age: 30, city: "上海" })

// 查询数据
db.users.find({ city: "上海" })

// 带条件的更新
db.users.updateOne({ name: "张三" }, { $set: { age: 31 } })

// 删除数据
db.users.deleteOne({ name: "张三" })

// 查看所有集合
show collections

这些操作频率极高，建议任何一个用 MongoDB 的同学都背下来。比 SQL 直观多了，几乎是自然语言。

4.5 索引优化：生产环境必须懂的底牌

热词里出现“滴滴、摩拜都在用的索引”，说的就是 MongoDB 索引设计。索引不是数据库自己替你做的，是你在建表之后必须主动设计的，否则数据量一上来，查询直接就卡死。

简单理解：索引就是 MongoDB 里为了加速查询而建立的数据结构，类似于书的目录。没有索引，查询相当于把整本书从头翻到尾；有了索引，就像按目录翻到对应页。

创建索引的方式：

javascript复制// 单字段索引
db.users.createIndex({ city: 1 })

// 复合索引
db.users.createIndex({ city: 1, age: -1 })

// 唯一索引
db.users.createIndex({ email: 1 }, { unique: true })

设计索引的原则是：先看业务查询最常用的字段作为查询条件，再考虑排序字段和范围查询字段。别上来就建一堆索引，索引多了一样影响写入性能，还占存储空间。

判断一个查询是否走了索引，用 explain：

javascript复制db.users.find({ city: "上海", age: 30 }).explain("executionStats")

输出中的 winningPlan 如果包含 IXSCAN，说明走了索引；如果是 COLLSCAN，就是全表扫描，需要加索引了。这一步是性能排查的必备技能。

4.6 未授权访问漏洞防护

MongoDB 未授权访问漏洞在安全圈非常知名，核心原因就是前面说的：未开启认证、端口暴露公网、使用默认配置。修复思路不复杂，但我还是单独拎出来强调：

必须在 mongod.conf 里开启 authorization: enabled
绝不把 27017 端口映射到 0.0.0.0 供公网访问
用防火墙限制仅内网或特定 IP 可访问
定期检查数据库中的用户列表和连接日志

如果发现已经被人写入勒索数据，第一时间断开外网访问，用备份恢复数据，同时检查有没有其他服务被横向渗透。这个危害比想象中大，早期很多开发者的 MongoDB 就是被“删库勒索”教育了一波。

5. Nginx 网站管理与反向代理配置

5.1 1Panel 中的 Nginx 应用

1Panel 应用商店里提供的是 OpenResty，它是带 Lua 扩展的 Nginx，完全兼容 Nginx 配置，并且支持面板的图形化站点管理。安装好后，你可以在“网站”中直接创建站点，也可以把它当成纯 Nginx 使用。

Node 项目部署时的访问路径通常分两块：静态资源（前端构建物，比如 Vue/React 的 dist 目录）和动态接口（Node 服务监听某个端口，比如 3000）。

最通用的方案是：Nginx 负责 80/443 端口，收到请求后，/ 路径返回前端静态文件，/api 路径反向代理到 Node 服务。这样前端代码不用暴露 Node 端口，用户只需要访问 80/443，既安全又统一。

5.2 反向代理配置模板

在 1Panel 里配置反向代理，有两种路径：

一种是在网站管理界面，选定网站后，在“反向代理”配置里加入代理规则；另一种是直接修改 Nginx 配置文件。我这边给一份实际可用的配置模板，你在 1Panel 的文件管理里找到对应站点的 conf 文件，直接改：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    # 前端静态文件目录
    root /opt/your-project/frontend/dist;
    index index.html;

    # 静态资源缓存
    location /assets/ {
        expires 7d;
        add_header Cache-Control "public";
    }

    # 后端 API 反向代理
    location /api/ {
        proxy_pass http://127.0.0.1:3000;
        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 / {
        try_files $uri $uri/ /index.html;
    }
}

注意几个点：

第一，proxy_pass 后面如果带路径，比如 http://127.0.0.1:3000/api，和只写 http://127.0.0.1:3000 的效果不一样，前者会把原来的 URL 路径替换掉，容易踩坑。一般建议 proxy_pass 不写路径，由 Node 端自己处理前缀。

第二，try_files $uri $uri/ /index.html 这一行是给 Vue/React 这种单页应用用的，否则刷新页面就会出现 404。

第三，proxy_set_header 必须保留，尤其是 Host 和 X-Real-IP，不然 Node 服务拿不到真实请求信息。

改完配置后，在 1Panel 网站管理里点“重载”或者去命令行执行 nginx -t 验证配置，再 nginx -s reload 让配置生效。

5.3 一台服务器部署多个 Web 项目

一台服务器部署多个项目，通常有两种方式：一个域名多个路径，或者多个子域名。

如果多个项目共用一个域名，可以用路径区分。例如 /project-a 和 /project-b 分别指向不同的静态目录或不同端口的 Node 服务：

nginx复制location /project-a/ {
    proxy_pass http://127.0.0.1:3001;
}

location /project-b/ {
    proxy_pass http://127.0.0.1:3002;
}

但这种方式对单页应用来说路由处理会比较绕，因为前端路由的 base path 也要对应修改。我更推荐用子域名隔开：a.your-domain.com、b.your-domain.com，每个子域名对应一个站点，配置清晰、互不干扰。1Panel 的网站管理中可以直接创建多个站点，SSL 证书也能单独签发和续期。

亲测下来，一台 2 核 4G 的服务器，跑两个 Node 服务加一个 MongoDB，再加 Nginx 处理静态资源，压力并不大。

5.4 Nginx 负载均衡配置

如果 Node 服务流量大了，单实例跑不动，就需要横向扩展。一种方式是同一台机器上起多个 Node 实例，监听不同端口，用 Nginx 做负载均衡。

nginx复制upstream node_cluster {
    server 127.0.0.1:3000 weight=5;
    server 127.0.0.1:3001 weight=5;
}

server {
    listen 80;
    server_name your-domain.com;

    location /api/ {
        proxy_pass http://node_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

weight 是权重，如果两台风服务器性能不一样，可以通过权重调整流量分配。默认是轮询，也就是每个请求依次分给不同实例。注意如果你的 Node 服务内部有状态，比如用户 Session 存在内存里，负载均衡会导致请求落到不同实例时 Session 丢失。解决办法是让 Node 服务无状态化，或者把 Session 存到 MongoDB/Redis 里统一管理，这个在设计系统时就要考虑进去。

5.5 Nginx 配置常见问题

Nginx 403：通常是静态目录没有挂载好，或者目录权限不足。检查运行 Nginx 的用户（一般是 nginx 或 nobody）对静态文件目录有没有读取权限，chmod -R o+r 或调整 owner 可以解决。

Nginx 404：静态文件路径不对，或者单页应用没有配置 try_files 兜底。

Nginx 502 Bad Gateway：这是反向代理最常见的问题，构成原因也最简单：后端 Node 服务挂了，或者监听端口没有正确启动。排查顺序是：curl 127.0.0.1:3000 看后端是否响应，再 ps aux | grep node 看进程是否存活，再 pm2 的 pm2 status 看守护状态。Node 服务没挂但端口没监听，那就是服务绑定到了别的端口。

SSL 证书配置：1Panel 提供免费证书申请和自动续期，直接在网站管理里配置即可，非常省事。如果你之前的站点是 HTTP，切 HTTPS 后注意检查页面里的资源引用是否还是 http:// 开头，否则会出现混合内容被浏览器拦截。

6. 项目上线全过程与避坑经验

6.1 从代码到上线的标准流程

部署流程我整理成一套可复用的步骤，按照这个顺序操作能省掉很多来回排查的时间：

在 1Panel 中安装好 Node 运行环境、MongoDB、OpenResty/Nginx
配置 MongoDB 认证用户和数据库
设置面板服务器地址、防火墙和安全组端口
将项目代码上传到服务器（git clone 或面板的文件管理上传压缩包）

进入项目目录，安装依赖：

bash复制npm install
# 或 pnpm install

构建前端项目（如果有）：
```
bash复制npm run build
```

用 pm2 启动后端服务：

bash复制pm2 start app.js --name your-project
pm2 save
pm2 startup

在 1Panel 中创建网站，配置静态目录和反向代理
申请 SSL 证书并启用 HTTPS
访问域名验证

6.2 使用 pm2 守护 Node 进程

Node 服务不像 Nginx 那样有系统的 init 脚本管理，一旦进程崩溃退出就是真的挂了。pm2 的作用就是守护进程、自动重启、收集日志。

常用命令：

bash复制# 启动
pm2 start app.js --name your-project

# 查看状态
pm2 status

# 查看日志
pm2 logs your-project

# 重启
pm2 restart your-project

# 设置开机自启
pm2 startup
pm2 save

pm2 startup 会生成一个系统服务，这样服务器重启后 Node 服务也会自动拉起。pm2 save 是把当前进程列表保存下来，这是很多人容易漏掉的一步，不 save 的话重启后 pm2 里是空的。

6.3 环境变量管理

项目的数据库密码、JWT 密钥、第三方接口 key 这些敏感信息，不要写死在代码里，更不要提交到 git 仓库。在 1Panel 中你可以给每个应用配置环境变量，也可以直接在 pm2 的 ecosystem 文件里管理。

一个最小化的 ecosystem.config.js 长这样：

javascript复制module.exports = {
  apps: [
    {
      name: "your-project",
      script: "app.js",
      env: {
        NODE_ENV: "production",
        PORT: 3000,
        MONGODB_URI: "mongodb://app_user:password@127.0.0.1:27017/your_database?authSource=admin"
      }
    }
  ]
};

然后启动命令变成：

bash复制pm2 start ecosystem.config.js

用 pm2 管理环境变量的好处是，改配置后只需要 pm2 restart 就能生效，不用改系统级的环境变量文件，对多项目部署来说干净很多。数据库的密码建议用强随机字符串，不要在多个环境复用同一个密码。

6.4 MongoDB 连接与 Node 服务对接

Node 服务连接 MongoDB，最常见的坑有两个。

一个是连接超时或 Authentication failed。如果你是按照上面的步骤创建了用户并开启了认证，那么连接串里的 authSource 一定不能写错。业务库用户创建在哪个库，authSource 不一定就填那个库，关键看用户是不是在 admin 下创建的。根用户填 authSource=admin，业务用户如果是直接在业务库下创建的，就要填业务库名。

另一个是 IP 限制。MongoDB 默认监听 127.0.0.1，容器部署时如果映射端口到宿主机，Node 服务在宿主机上通过 127.0.0.1 访问没问题；如果 Node 服务也在容器里，就要通过 Docker 网络访问，这时候连接地址就不是 127.0.0.1 了，而是 MongoDB 容器的服务名或对应 IP。1Panel 创建应用时可以配置网络，建议把 Node 服务容器和 MongoDB 容器放到同一个 Docker 网络中，连接串用服务名代替 IP。

6.5 常见问题速查表

整理一张速查表，平时排查问题可以直接对号入座：

现象	可能原因	解决方式
1Panel 提示未设置服务器地址	面板未填写公网 IP 或域名	面板设置中填写服务器地址
Node 安装失败	内存不足、镜像源问题	增加 swap、配置 Docker 镜像加速
npm install 速度极慢	npm 官方源	配置 npmmirror 镜像
npm 命令报 PowerShell 禁止运行脚本	Windows 执行策略	PowerShell 执行 Set-ExecutionPolicy RemoteSigned
node:util / node:path 模块找不到	Node 版本过老	nvm 切换到 Node 22.x
MongoDB 安装失败	内存不足、端口被占、镜像拉取失败	查看容器日志，逐个排查
MongoDB 认证失败	authSource 错误、未开启认证	检查连接串和 mongod.conf
MongoDB 被删库勒索	未授权访问漏洞	开启认证、端口仅内网访问、恢复备份
Nginx 502 Bad Gateway	Node 服务未启动或端口错误	curl 本地端口确认服务状态
Nginx 403	静态目录权限不足	调整目录权限
刷新页面 404	缺少 try_files 配置	添加 `try_files $uri $uri/ /index.html`

6.6 上线前最后检查清单

除了功能测试，上线前我还会过一遍这几个检查项：

Node 服务是否在 pm2 中设置了开机自启，pm2 status 是否正常守护
MongoDB 是否开启认证，是否创建了专用业务用户而不是用 root 跑业务
是否改了 MongoDB 的默认端口或者限制了来源 IP
Nginx 配置是否通过 nginx -t 校验，HTTPS 证书是否已生效
防火墙和安全组是否只放行了 80、443 和面板端口，数据库端口不对公网开放
MySQL 之外顺手给 MongoDB 也做一下自动备份，可以写脚本定时执行 mongodump，再把备份文件传到对象存储

7. 实际操作里的体会

整个流程走下来，说几点真实感受。

1Panel 最大的价值是把分散的运维操作整合进了一个界面，但不要指望所有事情都在界面上点完。一些高级配置仍然需要手动改文件，比如自定义 Nginx 配置、MongoDB 的认证配置、pm2 的环境变量，这些手动操作才是确保生产稳定性和安全性的关键。

MongoDB 的部分我尤其想多说一句：刚开始用的时候，我也觉得“本地开发不都是直接连吗”，等到真上线，发现未授权访问的问题有多严重之后，才把认证和权限规则当成第一优先。如果你现在还在用无认证的 MongoDB，趁着数据量不大赶紧补上，别等出了事再后悔。

最后分享一个小技巧：在 1Panel 里做完环境安装之后，先去应用商店把 MongoDB、OpenResty 这些基础组件的自动更新策略看清楚，有些组件不建议随手点升级，尤其是 MongoDB 大版本更新很可能导致连接协议变化，升级前先看官方变更说明和你的项目兼容性。生产环境，稳比新更重要。