1. 为什么选择 1Panel从一个真实迁移案例说起先说背景。我之前的一台服务器跑着两个个人站点加一个内部工具一直用的是别的面板管理图省事嘛。但用了两年多问题越来越多一是内存占用常年高位在 2G 的小机器上动不动就报警二是想调整 Nginx 配置要翻半天菜单改完还容易把整个服务带崩三是做多站点的反代体验很割裂一个站点一套配置方式想统一管理只能靠 SSH 手写。转机是有一次帮朋友迁移一套线上业务对方生产环境用的就是 1Panel。我花了一个下午把整个流程走了一遍从安装、建站、配反代到挂证书全程都在同一个界面里操作比我想象中顺畅太多。回来以后我把自己手头那台服务器也迁了过去用到现在大概有大半年整体感受是1Panel 是我目前用过的最适合当主力运维工具的开源管理面板。它不像某些商业面板那样功能多到冗余也不像纯命令行那样对新手不友好而是在两者之间找到了一个很舒服的平衡点。这个工具适合谁我觉得有三类人最值得试一是像我这样需要管理一台或多台服务器、不想每次都 SSH 敲命令的小团队运维二是用 Docker 部署应用的开发者1Panel 对容器编排的支持很原生比在面板里硬塞 Docker 功能自然得多三是想自己搭站、建博客、跑小型应用的个人站长尤其是需要对多个站点、多个域名做统一管理的场景。这篇文章我会完整复盘从服务器选型、环境准备、安装部署到实际配置多网站、反向代理、绑定域名、申请证书的全过程。重点会放在配置反代实现虚拟主机和多域名绑定这两个大家问得最多的需求上最后再整理我在实操中踩过的坑和排查思路。2. 服务器环境准备与安装落地的完整步骤2.1 服务器选型与系统版本选择的核心思路在开始安装之前先解决一个现实问题服务器怎么选1Panel 官方给出的最低配置是 1 核 1G但我实际测下来的结论是——1 核 1G 能跑但只适合用来试水。如果你打算在上面同时跑面板、Nginx、MySQL、几个容器应用内存一紧张就会出现容器被 OOM Killer 强杀的情况排查起来非常头疼。我个人推荐的最低门槛是 2 核 4G这是面板加几个小应用能稳定跑的分界线。系统版本方面我两台服务器分别用的是 Debian 11 和 Ubuntu 22.04另外在 CentOS 7.9 上也做过验证三者都能正常安装。如果你是全新购机我优先建议 Debian 系Debian 11/12 或 Ubuntu 20.04原因是软件源的 Docker 版本较新系统自身占用也低。CentOS 7 需要注意的是默认防火墙规则比较老派安装后如果发现面板访问不了先查 firewalld。还有一个很多人忽略的点云厂商的安全组和系统自带的防火墙是两套体系。即使你在服务器里放行了端口如果云控制台的安全组没放行外部依然是访问不了的。这个后面会反复提到属于新手中招率最高的环节。2.2 在线安装与离线安装的完整实操记录1Panel 的安装方式分在线和离线两种。绝大多数场景用在线安装就够了流程非常简单官方一条命令搞定curl -sSL https://resource.1panel.cn/quick_start.sh -o quick_start.sh sudo bash quick_start.sh脚本执行过程中会做几件事检查系统版本、检测是否已安装 Docker没装则自动安装、随机生成面板端口和初始密码、启动服务。整个流程大概 3 到 5 分钟取决于服务器带宽和 Docker 镜像拉取速度。执行完成后终端会输出面板访问地址、默认用户名、密码以及端口信息这些信息最好马上存下来。我在迁移时就是没注意保存初始密码结果后面重置花了不少功夫。装完之后登录面板第一件事就是把随机生成的端口改掉建议改成高位端口五位数。默认面板端口是 7937但这个端口太固定了扫一眼就能猜到改成 38261、47610 之类的五位数端口能挡掉不少扫描器的无差别尝试。离线安装比较适合内网服务器或者 Docker 镜像拉取困难的场景操作思路是去官方 Releases 页面下载对应架构的安装包和镜像 tar 文件传输到服务器后执行1pctl相关命令导入安装。过程比在线安装繁琐一些一般用户用不到我这边就不展开知道有这条路径即可。2.3 安装结束后必须做的三项基础配置第一项是修改面板端口。在面板左侧菜单找面板设置→端口设置改成你自己记得住的高位端口改完记得同时放行系统防火墙和安全组的新端口。第二项是绑定域名访问面板。1Panel 支持把面板后台绑定到一个域名上这样就不用记 IP 加端口了。比如你有一个域名admin.example.com先在 DNS 解析里加一条 A 记录指向服务器 IP然后在面板设置里填入这个域名并申请证书即可。这一步我特别建议做体验提升非常明显。第三项是确认容器通信端口 7946 的放行。这个是 1Panel 自动安装 Docker 后用于容器网络通信的端口TCP 和 UDP 都要放行。很多人装完面板发现一些应用无法正常启动排查到最后往往是安全组没放开 7946。这个端口是 1Panel 和裸 Docker 安装方式的一个重要差异点不要漏掉。3. 核心功能实战拆解日志、数据库与容器编排3.1 日志管理把多应用日志聚合到一处查看日常运维最烦的一件事就是查日志。不同应用日志分散在各自目录用tail -f一条条跟踪效率太低。1Panel 的日志管理模块把这些统一收拢到一个入口按应用维度分组展示在同一个界面里就能切换查看 Nginx 访问日志、PHP-FPM 错误日志、MySQL 慢查询日志等。实际用的时候我发现一个细节面板的实时日志用的是容器 stdout也就是你通过docker logs -f看到的内容。如果你用的是原生应用非容器部署日志路径需要手动在配置里指定。对于用 1Panel 自带商店安装的 Nginx、MySQL 这类组件日志路径已经被预先配置好直接用即可。有个小技巧是使用日志筛选时关键词尽量用精准的字符串比如查某个接口的异常直接搜GET /api/user加状态码而不是只搜error。我曾经排查一个偶发 500 的问题就是靠时间范围加路径双重筛选五秒钟定位到问题接口比翻半天日志效率高太多。3.2 数据库管理MySQL 的可视化操作与备份策略1Panel 的数据库管理模块对 MySQL 的支持非常完整支持创建数据库、授权用户、导入导出、定时备份。我习惯的做法是面板创建数据库后应用连接串里使用面板生成的数据库名和用户名密码用强随机密码避免复用。备份功能是我最看重的一块。1Panel 支持自动备份到服务器本地、阿里云 OSS、腾讯云 COS 或 S3 兼容存储还支持自定义备份频率。我在实际生产环境配置的是每天凌晨 3 点全量备份 备份文件保留 7 天的策略同时额外做了一份异地备份到对象存储。这样即使服务器整体挂掉数据也不会丢。还有一个实用场景从旧服务器迁移数据库到新服务器。操作流程是旧面板里做一次备份把备份文件下载到本地再在新面板里通过导入备份恢复。我在迁移时用这个方法恢复了一个 1.2G 的库整个过程大概几分钟比命令行 mysqldump 加 scp 来得直观。3.3 容器编排从应用商店到自定义 Docker Compose1Panel 内置的应用商店覆盖了 Nginx、MySQL、Redis、Node.js、Portainer、Gitea 等常见应用一键部署即可。不过我最常用的其实是容器模块下的Compose 功能——直接在面板里编写 docker-compose.yml即可实现自定义应用编排。举个实际例子我之前在面板里搭建了一套 Nginx PHP 环境compose 文件大致如此version: 3 services: nginx: image: nginx:1.24-alpine ports: - 8080:80 volumes: - ./html:/usr/share/nginx/html - ./nginx:/etc/nginx/conf.d networks: - app_net php: image: php:8.2-fpm-alpine volumes: - ./html:/var/www/html networks: - app_net networks: app_net: driver: bridge在面板里创建 Compose 应用时把这段内容粘贴进编辑器点确认就能启动。相比命令行docker compose up -d面板的优势有两点一是将容器的状态、日志、资源占用都可视化展示二是后续重启、更新、删除操作都不需要记忆命令直接点按钮就行。实际使用中有一个我特别注意的习惯容器之间的通信尽量用 Compose 内部网络而不直接映射端口。比如 Nginx 和 PHP 之间只需要通过php:9000内部通信完全没有必要把 9000 端口暴露到宿主机。这样既减少攻击面也避免端口冲突。4. 多网站与虚拟主机实战反向代理与多域名绑定4.1 用 1Panel 实现虚拟主机功能的核心思路这个功能是大家问得最多的需求。传统的虚拟主机指的是在一台服务器上用 Nginx 等 Web 服务器承载多个独立站点每个站点有自己的域名、目录、配置文件甚至独立的 PHP 进程。1Panel 的网站模块本质上就是帮你完成了这套配置的可视化管理同时扩展了反向代理的能力。你在面板里创建一个网站它会在 Nginx 配置目录下生成一个独立的 conf 文件域名、根目录、证书、伪静态规则都统一在这个文件的管辖范围。底层逻辑不复杂但面板替你省去了手工操作的时间。在动手之前先想清楚一个关键问题你的多个站点是要共用同一端口80/443靠域名区分还是各自占用不同端口绝大多数生产场景是第一种所有站点都走 80/443 端口Nginx 根据请求的 Host 头分发到不同的 server block。1Panel 的网站管理天然支持这种方式这也是多个域名绑定一个服务器 IP的核心原理。4.2 创建站点并配置静态网站的实际操作步骤第一步在面板左侧点击网站→创建网站。创建时选择静态网站类型填写主域名比如www.example.com同时在域名输入框里可以一次性把example.com也加进去。这样后续不管访客用带不带 www 的域名访问都会命中这个站点。第二步设置根目录。面板默认会在/opt/1panel/apps/openresty/www/sites/下为每个域名生成一个目录你把静态文件上传到这个目录即可。当然你也可以自己指定目录只要注意目录权限就行——前端站点目录至少要对运行 Nginx 的用户有读取权限。第三步绑定多个域名。在网站的域名标签页里可以随时增加或删除域名。比如你有一个blog.example.com和一个www.example.com都指向同一个站点就在这里添加。这个操作本质上是修改 Nginx 配置里的server_name指令。4.3 反向代理的配置方法与多端口服务接入反向代理是 1Panel 网站模块里最实用的能力之一。如果你的服务跑在一个特定端口比如 3000 的 Node.js 应用、8080 的 Java 服务、5601 的 Kibana你需要做的是创建一个反向代理类型的网站源站地址填服务的完整地址比如http://127.0.0.1:3000然后主域名填你想对外提供的域名。存之后访问这个域名就会自动把请求转发到 3000 端口。这里有一个关键参数需要注意开启WebSocket支持。如果你的服务用到 WebSocket很多实时应用都会用一定要在反向代理的高级设置里把 WebSocket 打开并启用 HTTP/2。否则前端页面能打开但实时推送功能会一直异常而且排查起来很隐蔽。另外反向代理不仅支持 HTTP 服务还支持其他协议。比如你想把某个 TCP 端口如 MySQL 3306映射到某个域名在网站类型里也可以选择TCP/UDP 端口转发来实现。这一点很适合把数据库安全地暴露给特定域名访问的场景。4.4 多域名绑定的常见配置范例与证书申请聊个实际案例我的服务器上有三个域名分别是主站example.com、博客blog.example.com、和一个临时给客户演示用的demo.example.com。我在 1Panel 里创建了两个静态网站和一个反向代理网站。其中example.com和blog.example.com共用了一个多域名证书——这是 Lets Encrypt 支持的特性一个证书可以绑定多个域名浏览器会视为合法证书。在 1Panel 里申请 SSL 证书非常简单进入网站→证书→申请证书选择 Lets Encrypt填写你要申请的域名列表勾选自动续签保存后它会自动创建并部署证书。整个过程大概 10 秒到 1 分钟取决于 DNS 验证速度。申请完成后站点配置里选择这个证书立即生效。申请证书有一个前置条件必须满足该域名的 DNS 解析必须已经指向这台服务器 IP并且 80 端口要能从外网访问。Lets Encrypt 的 HTTP-01 验证方式会临时往你的服务器上放置一个验证文件外网无法访问就校验失败。我遇到过好几次用户来问证书申请失败最后排查发现都是忘了在云安全组里放行 80 端口。下图是配置多域名时的完整链路用户请求 example.com ↓ DNS 解析 → 服务器 IP ↓ 安全组/防火墙放行 80/443 ↓ 1Panel Nginx 接收请求 ↓ 依据 Host 头匹配站点 server_name ↓ 静态目录 / 反代目标 http://127.0.0.1:端口 ↓ HTTP 跳转 HTTPS启用证书后整个过程最关键的是前半段链路域名解析、安全组放行、站点创建顺序要对。我见过不少人先创建站点再解析域名结果证书申请报错回过头去把解析补齐再申请就成功了。5. 上线后的常见问题与排查技巧实录5.1 面板无法访问、应用容器反复重启的根因这是新装完面板后遇到最多的问题。面板无法访问九成以上是安全组或系统防火墙没有放行对应的端口。排查步骤我建议按下面顺序进行先本机测试在服务器上执行curl http://127.0.0.1:端口看有没有响应。如果没有响应说明面板服务本身没起去检查 1Panel 服务状态如果有响应说明面板正常问题出在外部访问链路上。再看系统防火墙Debian/Ubuntu 检查 ufwCentOS 检查 firewalld确认端口是 allow 状态。最后看安全组登录云厂商控制台检查入方向规则里是否放行了对应端口。很多云厂商默认只放行 22、80、443新端口需要手动添加。容器应用反复重启则是另一个典型问题。比如你部署了一个 MySQL 容器过几小时就挂一次重启后又能跑一阵。这种通常不是配置错误而是容器内存超限被系统杀掉。到 1Panel 左侧容器→运行中里查看该容器的内存占用再对比服务器总内存。如果服务器总内存只有 2GMySQL 容器默认内存限制可能就 512M 甚至更高一有并发查询就 OOM。解决方案是要么在 compose 文件里给容器设置内存限制比如mem_limit: 512m要么直接升级服务器配置。在低配机器上我建议同时做两件事把不常用的 PHP-FPM、Redis 等组件的内存占用调低并且限制日志文件大小避免日志把磁盘写满进而引发连锁故障。5.2 反向代理 502/504 的定位方法与实战解法反向代理配置完成后访问域名出现 502 Bad Gateway这个错误出现时先不要急着怀疑 1Panel 配置按照以下顺序排查502 的本质是 Nginx 无法连接到你填写的上游服务地址。先确认源站服务本身是否正常在服务器上执行curl -v http://127.0.0.1:3000看是否有响应。如果源站正常返回再看你填写源站地址时是否写成了localhost而不是127.0.0.1或者用了容器名称而网络模式不对。一个非常常见的场景是源站服务运行在容器里端口映射的是 127.0.0.1:3000 而不是 0.0.0.0:3000。比如你在 compose 文件里写了127.0.0.1:3000:3000这样只有宿主机回环地址能访问Nginx 作为宿主机进程可以访问但如果 1Panel 里的反向代理理解有点偏差代理请求会失败。建议统一映射为0.0.0.0:3000:3000或3000:3000以免产生歧义。504 则多半是代理上游的响应超时。Nginx 默认的proxy_read_timeout是 60 秒如果上游服务处理很慢比如导出报表、备份大数据量接口可以到网站的高级配置里把超时时间调大比如 120 秒。这里我要提醒一句调大超时时间只是缓解症状真正要做的是优化上游接口速度。我之前遇到一个接口要跑三分钟前端一直报 504后来在代码层面做了异步任务加轮询查询才从根本上解决。5.3 SSL 证书申请失败与 HTTPS 强制跳转问题的排查关于证书申请失败我前面提到了 DNS 解析和 80 端口放行这两个前置条件。除此之外还有一个隐性条件域名解析可能在多个层级生效比如国内服务器用了 CDN 或 DNS 服务商解析到边缘节点而不是源站 IPLets Encrypt 验证请求就会打到错误的地方。解决办法是在 DNS 服务商控制台确认该域名的 A 记录直接指向服务器 IP并且短时间内没有 TTL 缓存问题一般等 10 分钟再申请。我习惯的做法是先在本地ping 域名看解析到的 IP 是否和服务器 IP 一致确认无误再申请证书。HTTPS 强制跳转的问题也很典型。有时候证书已经申请成功了但访问http://example.com时不会自动跳到https://example.com访客会看到不安全警告。在 1Panel 的网站配置里找到HTTPS标签页打开强制 HTTPS选项保存后 Nginx 会自动加 301 跳转规则。如果已开启还是没有跳转效果是因为浏览器对某个域名的 HSTS 或者缓存问题换新浏览器访问或用无痕窗口测试即可。需要注意的是如果网站同时绑定了多个域名点击强制 HTTPS会作用于整个站点即所有域名都会统一跳转。如果部分域名想用 HTTP比如临时测试地址建议把测试域名提到独立站点去管理避免互相干扰。5.4 日常运维中的三条独家经验顺手分享几个日常使用中验证过的小经验都是文档里没有明确写过的第一个是关于磁盘占用。1Panel 在/opt/1panel目录下会存放大量 Docker 镜像层和容器数据时间一长占到好几个 GB 很正常。建议每隔一两周去容器→镜像页面清理悬空镜像在主机→磁盘里看一次分区占用率把不需要的备份文件及时删掉。我遇到过一台机器磁盘被 Docker 日志文件撑满应用集体拒绝写入排查了大半天才定位到从那次以后清理就成了定时任务。第二个是关于升级时机。1Panel 的更新频率不算低但我不会一有新版本就立刻升级。我的习惯是等新版本发布一周左右观察官方社区有没有人反馈严重的 bug确认没问题再升级。升级前一定先备份/opt/1panel目录下的配置文件和数据库升级失败时能快速回滚。第三个是关于浏览器兼容。1Panel 的面板管理界面在 Chrome、Edge 上体验最佳Safari 有时会出现样式错乱或按钮点击不响应的情况。如果你用的是 Safari 且遇到问题换 Chrome 试试往往能解决。这不是面板本身的 bug大概率是前端兼容性适配的问题遇到不要慌。另外说一下用户权限的划分。1Panel 的权限体系区分了管理员和普通用户管理员可以操作所有功能包括用户管理、面板设置、服务器配置普通用户只能在授权范围内管理网站、数据库和容器。如果是团队共用的面板建议给每个人建独立账号避免所有人的操作都混在管理员账号里。操作审计也方便很多——哪个用户什么时候改了什么配置都有记录这在多人运维时太重要了。结尾最后聊点实际的感悟。1Panel 对我来说最大的价值不是多了一个管理界面而是让我从大量重复的 Nginx 配置、证书续期、目录权限调整里解放了出来。以前我要手动搞定一个多站点服务器从安装编译环境到配置 PHP-FPM、写 vhost 文件没有半天时间下不来现在在面板里点选加填参数十分钟就完成了而且配置格式都是标准化的出问题的概率低了很多。我特别推荐那些服务器有很多台、但没有统一配置管理工具的团队尝试用 1Panel 作为日常运维的入口。它不是万能的遇到太复杂的自定义场景还是需要回到命令行但至少 80% 的日常操作能在这个面板里完成。我自己的习惯是能用面板解决的就用面板面板覆盖不到的再用命令行兜底这样不断磨合下来运维效率和稳定性都有很明显的提升。如果你正准备在服务器上搭建多站点环境希望这篇内容能帮你少走点弯路。