实训周第一天老师布置任务，要在两台虚拟机分别部署Nginx与Apache，保证服务正常运行，并且支持域名访问。看着任务描述感觉不难，动手实操才发现到处都是问题。
我负责搭建Nginx环境，虚拟机安装Ubuntu Server 22.04系统，没有图形界面，全程依靠命令行操作。使用apt install nginx命令安装软件的过程很顺利，浏览器输入IP地址，也成功加载默认页面。到绑定域名这一步就卡住了，我修改本地hosts文件添加解析记录，访问域名时浏览器提示连接被拒绝。排查半小时才找到问题，Nginx默认监听80端口，修改配置文件的时候，server_name只填写带www的域名，hosts里面只添加不带www的域名，两边信息不匹配，页面自然无法打开。
这件事让我记住，配置文件里每一处字符都有对应的作用，不能凭主观想法随意填写。
之后搭建虚拟主机，需要在同一台服务器部署两个独立站点。我在/etc/nginx/sites-available目录新建两份配置文件，分别编写server配置块，再用ln -s命令创建软链接到sites-enabled目录。重载配置之后，第一个站点访问正常，第二个站点始终展示Nginx默认页面。反复排查后发现，默认站点配置带有default_server标记，优先级高于新建的站点配置。删掉默认配置里的default_server参数，再次重载配置，两个域名就能分别指向各自网站目录。
这时才理解，Nginx配置加载存在先后顺序，配置文件被读取的先后决定优先级，新增配置不会自动覆盖原有配置。
Apache遇到的故障类型和Nginx不一样，它的配置文件分布更为零散，主配置文件路径是/etc/apache2/apache2.conf，站点配置放在sites-available目录，模块启用关闭依靠a2enmod、a2dismod命令。一开始没有开启rewrite模块，WordPress固定链接访问全部返回404。执行a2enmod rewrite开启模块之后，还需要在站点配置中将AllowOverride参数从None修改为All，否则.htaccess文件无法生效。两个步骤缺一不可，很多教程只会单独提到其中一项，只有亲身踩坑才能记牢。
权限相关问题也耗费大量调试时间。网站目录放置在/var/www/，文件归属root用户，Apache运行身份是www-data，没有读取文件的权限。给目录设置755权限，文件设置644权限，再通过chown命令将文件所属用户组改为www-data，网站才能正常访问。这里有个细节，目录需要执行权限才能进入，文件仅需要读取权限。不少新手直接把目录权限设置为644，Apache访问直接报403错误，就是缺少目录执行权限。课本上虽然讲解过相关知识点，但实操的时候，理论知识和命令操作很难快速对应。
防火墙也是绕不开的关卡。ufw默认处于关闭状态，开启之后仅放行22端口，80、443端口全部拦截。浏览器无法访问站点，一开始误以为是Nginx配置出错，反复核对配置文件，最后使用curl localhost测试，本地访问正常、外部访问失败，才意识到防火墙没有放行网页端口。执行ufw allow 80、ufw allow 443两条命令解决问题。云服务器额外存在安全组策略，需要在控制台单独放行端口，安全组和系统防火墙相互独立，任意一方没配置好都会导致访问失败。
实训最后一天配置SSL证书，借助certbot工具自动申请Let's Encrypt证书，执行命令之后工具自动修改Nginx配置，添加443端口监听地址与证书路径。自动生成的配置包含不少冗余内容，原本80端口跳转HTTPS的逻辑也被覆盖。我手动调整配置，80端口的server块添加return 301跳转至HTTPS，443端口保留certbot生成的核心配置，清理多余注释和重复代码。重载配置之后，浏览器地址栏出现安全锁标志，整套环境才算全部调通。
整套实训结束最大体会，单纯阅读教程感觉全部掌握，上手部署才会遇到各种问题。教程一笔带过的操作步骤，实际环境会因为系统版本、软件版本，或是之前执行过的无关操作产生异常。排查故障的能力远比死记命令重要。遇到报错优先查看日志，Nginx错误日志存放路径是/var/log/nginx/，Apache日志在/var/log/apache2/，绝大多数报错信息都会记录在日志当中，新手容易慌乱，直接上网搜索，忽略日志里最直接的提示。
还有一个实用习惯，修改配置前做好备份。每次修改配置文件，我都会复制一份带日期标记的备份文件，配置出错可以直接恢复，比逐行回滚修改效率更高。另外systemctl reload相比restart更加温和，生产环境尽量选择平滑重载，避免中断服务，这个习惯要在实训阶段养成。
虚拟机操作失误能够直接重装系统，生产环境一旦操作失误，没有这么简单的补救办法。