Linux服务器初始化与Nginx部署实战：从裸机到Web服务

1. 任务拆解：拿到“期中测试1”后，先别急着敲键盘

最近收到一份“期中测试1”的实践任务，标题虽然简简单单四个字，但点开要求才发现内容并不含糊：要求独立完成一台Linux服务器的环境初始化、Web服务搭建、远程访问配置和基础排障，全部操作有日志记录，最终还要写一份复盘文档。

说实话，这种阶段性的动手测试在运维、开发岗位的培训里非常常见，它考的不是死记硬背的指令，而是你面对一台裸机时能不能有条不紊地把事情做对、做稳、做可追溯。很多刚入行的朋友一看到这类题目就容易慌，要么急着装系统，要么乱敲命令，结果日志记了一堆却全是报错。这次我就以这份“期中测试1”为例，把从环境准备到服务上线的完整过程拆开讲一遍，里面包含我自己的操作习惯、踩过的坑和排查思路，希望能给同样在准备阶段性动手考核的朋友一些参考。

适合看这篇文章的人其实很广：刚学Linux基础想找综合练习的初学者、准备运维或DevOps岗位面试需要实战经验的新人，还有带团队想设计内部技能考核的组长——按这个流程走一遍，基本能把一个人对Linux基础的掌握程度摸个七七八八。

回到任务本身，我先把它拆成几个看得见摸得着的模块：

• 基础环境：虚拟机安装Linux发行版，网络要能通，SSH要能连。
• 用户与权限：创建测试账号、设置sudo权限、锁定或禁用不需要的系统账户。
• Web服务：安装并配置Nginx，建一个静态测试页，保证本机curl能通。
• 防火墙与安全：放行必要的端口，剩下的全部拒绝，确保重启后规则依然有效。
• 文档记录：每一步操作、关键输出、遇到的问题都要记录，这是评分重点之一。

拆完之后你会发现，每一块单独拿出来都不算难，但串在一起就需要你有清晰的流程感。这也是这类“期中测试”真正的目的——不是考你会不会敲某一条命令，而是考你有没有一套完整的、可复用的实施思路。

2. 环境准备：虚拟机和最小化安装的取舍逻辑

2.1 虚拟机平台选型

我这次用的是VMware Workstation Pro，因为它对初学者最友好，快照功能在测试阶段特别实用。你在操作前一定要先给初始状态打个快照，命名为“clean-state”。这相当于你写代码前先提交一个初始commit，后面不管把环境搞得多乱，都能一键回到干净状态。这个习惯在真实生产环境里同样重要——任何变更前先备份或快照，是你对自己操作负责的第一步。

如果你用的是VirtualBox，操作同样可行，只是虚拟机网络设置的名字和位置略有差异。我个人建议：平时练习就用VMware或VirtualBox哪个顺手用哪个，但网卡模式一定要搞清楚，这个直接影响后面能不能连通网络。

2.2 网络模式选型：NAT模式是最稳的起点

很多人在虚拟机上栽的第一个跟头就是网络模式。VMware提供三种主要模式：桥接模式、NAT模式、仅主机模式。我用列表简单说明一下它们的区别：

这次“期中测试1”要求Web服务能通过宿主机浏览器访问，但同时不需要被公司局域网其他机器访问，所以我选择了NAT模式。它既能保证虚拟机联网安装软件包，又能让宿主机访问到虚拟机的Web页面，属于最稳妥的起点。如果你在真实机房或云服务器上做类似任务，那就不存在这个选择了——云服务器一般都有公网或内网IP，但安全组规则一样要仔细放行。

2.3 系统安装：最小化安装真的好用吗？

我安装的是CentOS 7.9的minimal版本。为什么选它？因为测试题目要求“环境要干净，服务要明确”，最小化安装意味着系统里只有必要的组件，没有桌面环境、没有多余的开发工具，这样后面排查问题时背景噪音最小，出问题也容易定位。

不过这里要提醒一句，minimal不是越小越好，你要确保安装时勾选了“标准开发工具”这一组。因为后面编译或安装软件时会用到gcc、make这些基础工具，如果没有，你就得先忍受yum下载依赖时出现的一连串“No package xxx available”的报错。我在第一次做类似任务时就吃过这个亏，当时为了装一个Nginx扩展，硬是从ISO挂载里补了快十个依赖包才搞定，非常浪费时间。

分区方面，采用LVM方案，在安装引导里选择“自动创建分区”，但把/home单独分出来并留出足够空间给根目录。因为后续测试日志、打包文件都会放在/root或/var下，根目录空间不够的话处理起来很痛苦。分区逻辑很简单：

• /boot: 500MB，引导文件专用，不需要太大。
• swap: 建议跟物理内存一致，测试机2GB内存就分2GB。
• /: 剩余全部空间，用LVM管理，方便后面扩容。

安装完成后第一件事就是改主机名，我把它设成了midterm-test-01，方便日志和文档里区分。然后关闭SELinux或改为permissive模式——这里多说一句，我知道很多安全专家会强调SELinux的重要性，但作为阶段测试环境，SELinux的严格策略会给Nginx绑端口和文件读写带来额外复杂度。如果你不熟悉SELinux的布尔值调整，就先设置成permissive，把精力集中在服务本身的配置上。生产环境请务必保留SELinux enforcing，并单独学习它的策略配置。

3. 用户与权限：安全边界是从账号开始的

3.1 创建专用测试账号并配置sudo

系统装好了，第一件事不是装Nginx，而是建账号。很多新手一拿到机器就用root干活，这在测试题里会直接扣分，因为真实生产环境中root登录是被严格限制的。你要养成一个条件反射：任何任务都创建一个专用账号，按需赋予sudo权限。

我创建了一个叫tester的账号，密码设置得稍微复杂一些，同时把SSH登录的公钥放进去，这样后面远程操作时就不需要反复输入密码。具体命令很简单：

useradd tester passwd tester

然后给tester添加sudo权限。我在/etc/sudoers.d/下面单独建了一个文件，而不是直接改/etc/sudoers——这样更规范，也避免语法错误导致sudo全部失效：

echo 'tester ALL=(ALL) ALL' > /etc/sudoers.d/tester chmod 440 /etc/sudoers.d/tester

这里的权限模式440是必须的，如果权限不对，sudo会直接拒绝读取这个文件，而且不会给你任何明显的报错提示，只是所有sudo命令都卡在权限检查上。这个坑我踩过，当时花了十分钟才反应过来是文件权限被改错了。

3.2 锁定系统内置账号

系统默认有很多内置账号，比如lp、sync、shutdown、halt、news、uucp等，它们在正常业务中几乎用不到。安全基线要求这些账号不能登录，最直接的做法是锁定它们。但注意，我并不会全部锁死，因为有些是系统服务依赖的系统账户，锁错可能导致服务起不来。

我采用一个更稳妥的方法：查看/etc/passwd，把所有shell是/bin/bash或/bin/sh但业务上完全不需要登录的账号，把shell改为/sbin/nologin。例如：

usermod -s /sbin/nologin lp usermod -s /sbin/nologin sync usermod -s /sbin/nologin shutdown usermod -s /sbin/nologin halt usermod -s /sbin/nologin news

这种处理方式比直接锁定更优雅——锁定后账号状态变成"Locked"会中断某些服务的运行，而改成nologin则只是禁止交互登录，服务自身启动时不受影响。这个细节在面试时讲出来会很加分，因为说明你真的理解账号和工作原理的关系。

做完这一步，用cat /etc/passwd检查一遍，确认tester账号的shell是/bin/bash，其他无关账号都指向/sbin/nologin。记录下输出，截图或复制到文档里，方便后期整理报告。

4. 核心配置：SSH远程管理与网络安全放行

4.1 修改SSH配置，拒绝裸奔

“期中测试1”明确要求远程管理能力，所以SSH是必须重点配置的服务。默认的SSH配置有几个明显的隐患：允许root直接登录、密码验证次数不限、空闲连接时间无限长。测试要求不高，但至少要改掉root登录这个点。

我改了/etc/ssh/sshd_config里的几个关键项：

PermitRootLogin no PasswordAuthentication yes PubkeyAuthentication yes MaxAuthTries 6 ClientAliveInterval 300 ClientAliveCountMax 2

PermitRootLogin设为no，意味着即使是root用户，也只能先用普通账号登录再su或sudo切换到root。这个习惯要从第一天养成。MaxAuthTries限制密码错误次数，防止暴力破解刷你的SSH端口。ClientAliveInterval和ClientAliveCountMax组合起来可以在客户端掉线时自动回收连接资源，避免挂一堆死连接占着进程。

改完配置后记得重启服务：

systemctl restart sshd

restart和reload的区别也要留意：reload只是重新读取配置，不中断现有连接，适合小幅调整；restart会断开所有连接，如果人在远程操作时执行了restart且新配置有误，你可能就永远登不回去了。所以远程改SSH配置时，我建议先执行sshd -t校验语法，再reload，不要轻易restart。

4.2 防火墙规则：放行该放的，关掉不该开的

CentOS 7自带firewalld，它的管理逻辑是“区域”，默认区域是public。我要做的三件事：放行SSH（22端口）、放行HTTP（80端口）、默认拒绝其他所有入站流量。

systemctl enable --now firewalld firewall-cmd --permanent --add-service=ssh firewall-cmd --permanent --add-service=http firewall-cmd --reload

这里用--add-service而非--add-port的好处是直观、语义清晰，而且firewalld内置的service定义里已经包含了端口和协议的完整描述，不容易写错。如果你用了自定义端口，那才需要--add-port=2222/tcp这样的写法。

我特意把--permanent参数写在前面，确保规则关机重启后依然存在。很多人在这个环节会漏掉--permanent，导致当下测试放行成功，但一重启机器规则就全部丢失。而且还会多一个困扰：firewalld有运行时配置和持久化配置两套状态，如果当时没注意，后面复查时看到的可能是“runtime ok”但“permanent empty”，这样给考官看到了很尴尬。

检查最终规则的命令是：

firewall-cmd --list-all

要能看到services里有ssh和http，默认zone是public，就说明配置正确。

4.3 网络连通性验证

SSH和防火墙改完，我不急着往下走，先做一轮网络验证，确认之前所有的改动没有把网络搞坏。验证顺序按照从内到外的路径：网卡状态、本机回环、虚拟网关、外网DNS。

ip addr show ping -c 3 127.0.0.1 ping -c 3 192.168.31.1 ping -c 3 baidu.com

192.168.31.1是我这台虚拟机NAT模式的网关地址，实际情况要根据你虚拟机网络的网段来定，用ip route查看default via那一条就知道网关是哪个IP。

如果外网ping不通，首先排查DNS配置，检查/etc/resolv.conf是不是有可用的nameserver。如果DNS没问题，那就查路由表，看default route是否存在。网络问题80%都出在这两个点上，别急着重启网卡或者重建虚拟机。

5. Web服务实现：Nginx部署与静态测试页

5.1 用yum安装Nginx，别急着编译源码

Nginx的安装方式大致有两种：用EPEL仓库yum安装，或者下载源码手动编译。阶段测试我推荐yum方式，理由很实际——你是在考试，不是在研究编译细节。用yum安装速度快、依赖管理省心、后续systemctl管理方便，足够覆盖题目的全部要求。

首先安装EPEL仓库，因为CentOS 7默认仓库里没有nginx：

yum install -y epel-release yum install -y nginx

安装完成后不急着启动，我先把默认配置检查一遍。nginx.conf里需要确认几个点：

• user nginx; 是运行worker进程的用户，这个用户必须在系统里存在且权限正确。
• server模块至少监听80端口，server_name可以先用下划线_占位，后续再改。
• 默认的root路径是/usr/share/nginx/html，静态页面放这里就行。

5.2 自定义静态测试页

题目要求输出一个可以访问的页面，我用一个简单的index.html，内容包含主机名、IP、当前时间，这样可以快速验证服务是否真的在响应，而不是看到了浏览器缓存的旧页面。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>Midterm Nginx Test</title> </head> <body> <h1>Nginx is running!</h1> <p>Hostname: midterm-test-01</p> <p>IP Address: 192.168.31.100</p> <p>Time: 2025-01-01 10:30:00</p> </body> </html>

把文件保存到/usr/share/nginx/html/index.html后，先用nginx自己的语法检查工具确认配置无误，再启动服务：

nginx -t systemctl start nginx systemctl enable nginx

nginx -t这一步非常关键，它会检查主配置文件和所有include进来的子配置文件，如果有语法错误会明确告诉你哪一行出了问题。在你修改过任何nginx配置之后，都必须先执行这一步再重启或reload。这就像你改完代码要先编译一样，编译过了再运行，而不是直接重启进程。

然后在本机验证：

curl -I http://127.0.0.1

如果看到HTTP/1.1 200 OK就说明Nginx在工作。再检查一下页面内容是否正确返回：

curl http://127.0.0.1

正常情况你会看到完整的HTML内容。到了这一步，虚拟机内部的服务已经通了，剩下的就是从宿主机访问验证。

5.3 宿主机访问验证

打开宿主机浏览器，输入虚拟机的IP地址，理论上应该看到刚才写好的测试页。如果打不开，不要急着怀疑Nginx，先按顺序排查：

1. 在宿主机ping虚拟机IP，不通说明网络层有问题，检查VMware网卡模式。
2. 如果ping通但浏览器打不开，检查防火墙是否放行了80端口，命令是firewall-cmd --list-all。
3. 确认Nginx进程状态，systemctl status nginx，看是否有报错。
4. 最后用ss -tlnp | grep :80确认80端口确实在监听。

这个排查顺序是从底层到上层，每一层验证通过再往下一层走，效率最高。千万别一上来就怀疑是Nginx配置的错，很多时候问题根本不在服务本身，而是端口被防火墙拦了或者网络模式不对。

如果以上都没问题但仍不能从宿主机访问，那就要检查SELinux了。在CentOS 7上，SELinux处于enforcing模式时，即使防火墙放行了80端口，httpd（Nginx）进程也可能被SELinux策略阻止绑定端口或读取文件目录。你可以查看/var/log/audit/audit.log里有没有denied记录，然后用ausearch -m avc -ts recent检索。作为测试环境，最简便的处理方式是暂时设为permissive：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

第一行是临时生效，重启后失效；第二行是永久修改，需要重启机器才会全部生效。刚才我提到安装系统时建议直接设置permissive，如果你没有设置，这里就要记住这个操作。生产环境不要照抄这个做法，生产环境应该去学习如何正确配置SELinux布尔值，而不是粗暴关闭。

6. 常见问题与排查技巧实录

6.1 端口放行了但网页还是打不开

这是“期中测试1”里最容易出现的现象，也是很多人在群里问得最多的问题。明明firewall-cmd --list-all里80端口是放行的，curl本机也通，但宿主机浏览器就是白屏。

我遇到过一次，最后定位到问题是VMware NAT模式下的网络策略没选对。VMware虚拟网络编辑器里有一个“对虚拟机启用NAT”的选项，如果被取消，宿主机虽然能ping通虚拟机，但虚拟机的出站流量会走不通，导致浏览器发起的HTTP请求到了虚拟机却没有响应。这种情况从虚拟机上curl任何外网地址都无法返回，很隐蔽。

解决办法：打开VMware编辑—虚拟网络编辑器—选中NAT模式—勾选“对虚拟机启用NAT”，然后保存。如果你不确定自己是不是这种情况，先做一个简单的测试：在虚拟机上执行curl -I http://www.baidu.com，如果返回响应正常，说明出站没问题，那问题大概率还是出在防火墙规则上；如果出站都不通，先检查NAT开关和网卡。

6.2 Nginx启动失败，syntax is ok但服务起不来

另一类高频问题是nginx -t显示syntax is ok，但systemctl start nginx却报错失败。查看journalctl -u nginx日志，往往是bind() to 0.0.0.0:80 failed (98: Address already in use)。

原因通常有两个：一是系统里已经装了Apache或其他Web服务占用了80端口，二是你自己重复启动过nginx导致老进程没退出。排查命令：

ss -tlnp | grep :80

看到PID后，根据进程名决定是停掉它还是杀掉它。如果是其他服务占用，要么停掉、要么改nginx端口；如果就是nginx自己重复启动，那就执行：

pkill -9 nginx systemctl start nginx

这里有一个小知识点：虽然nginx作为服务用systemctl管理时理论上不会出现重复启动，但如果你在调试过程中直接用nginx命令启动过进程，然后再用systemctl启动时，可能因为master进程已经在运行而导致新进程无法绑定端口。这个状态还好，但容易让初学者误判成配置错误。

而且我要强调一个容易忽略的点：在CentOS 7上如果同时装了httpd和nginx，httpd可能因为监听80端口而在systemctl层面显示"active (running)"，但它其实用的是IPv6的::，不会出现在ss -tln的IPv4输出里。这种情况下curl -I http://127.0.0.1能通，但访问IP的IPv4地址却失败，非常迷惑。转头去查ss -tln6就能发现真相。

6.3 问题排查速查表

最后把这次测试过程中可能遇到的问题和排查方向整理成一个速查表，方便你直接参考：

这类表格在整理测试复盘时非常有用，我建议你在自己的报告里也按这个格式去写，既方便考官查看，也是对自己排查思路的梳理。

7. 复盘心得：一次“期中测试”真正在考什么

这次的“期中测试1”题目本身并不复杂，但做完之后我的体会是：这种阶段测试真正想检验的，不是你会不会用什么工具，而是你有没有一套稳定可靠的做事方法。从环境规划、账号创建、网络配置到服务上线，每一步都环环相扣。如果你只会在图形界面上点鼠标，或者只会背命令但不知道每条命令影响的面，执行过程中一定会出现各种稀奇古怪的连锁问题。

我个人在实际操作中的体会是，把“记录”当作任务的一部分特别重要。每一步操作、每一个输出结果、每一次报错和解决办法，都实时记录下来。这不仅是为了最后交一份漂亮的报告，更是为了在排查问题时能回溯自己到底做了哪些改动。很多时候你在当前环境里纠结半天的bug，往前翻三步就会发现是之前某一条命令留下了隐患。这种习惯在真实生产环境里能救你很多次，比任何“xx天精通Linux”都管用。

另外，快照和备份的重要性再怎么强调也不为过。测试过程中改错了配置、搞坏了系统都不可怕，可怕的是没有退路，只能从头开始。有了快照，每一个节点都可以重来，试错成本大大降低。我甚至建议你在每完成一个阶段后就打一个快照，比如“after-user-config”、“after-nginx-config”，这样一旦后续操作引入问题，你能精确回退到上一个健康状态，而不是全部重做。

最后再分享一个小技巧：这类测试的文档质量在一定程度上会比实操结果更影响评分。实操可能因为各种环境因素出现意外，但一份条理清晰、步骤完整、包含报错和解决办法的文档，能直接向考官证明你是“有思路地操作”，而不是“碰巧做对了”。所以，从第一台虚拟机装好开始，就把每一步记录下来，等你写到复盘文档时，会发现根本不用额外回忆，所有素材都已经整齐地躺在你的日志里了。