)
US.KG 实战指南:为免费域名准备一台 Linux Web 服务器(Nginx 静态站点部署全流程)【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG本文基于 US.KG(DigitalPlat FreeDomain)教程第 3 部分构建并发布网站中的服务器准备章节展开,系统讲解如何在一台 Debian/Ubuntu 服务器上用 Nginx 搭建一个可直接接入免费域名(如example.dpdns.org)的静态站点:从系统更新、安装验证、站点目录、虚拟主机配置,到改 DNS 之前的 Host 头测试与防火墙检查。读完本篇,你将能够独立完成一台可公开访问 Web 服务器的标准初始化,并为后续的 rsync 部署、域名解析与 HTTPS 启用打下基础。一、适用范围:Debian/Ubuntu Nginx,但原则通用本章教程以一个通用的 Debian 或 Ubuntu 系服务器加 Nginx 为例(见 3.4 服务器准备章节)。原文档明确指出:任何提供同等能力的 Web 服务器软件都可以替代,前提是该软件具备以下四项能力:HTTP 服务能力:能按请求路径返回静态文件;TLS 能力:后续第 3.6 章(启用与验证 HTTPS)需要在同一主机上终结 TLS;日志能力:能按站点分离 access log 与 error log;虚拟主机能力:能通过Host请求头区分同一 IP 上的多个域名,这是用一台服务器承载多个 US.KG 子域/域名时的关键。换句话说,Nginx Debian只是示例载体,真正要掌握的是这套HTTP TLS 日志 虚拟主机的工作模型。二、动手前:服务器前置条件清单原文档列出的服务器要求(五项)是整章的验收基线,建议在开机器之前逐条核对:要求说明公网 IPv4、IPv6 或两者域名 A/AAAA 记录必须能解析到真实可达的地址非 root 账号 sudo用普通用户登录,提权走sudo,避免直接以 root 操作入站 TCP 80/443 放行需同时满足网络侧防火墙与主机防火墙两层策略安全更新机制可用自动更新或固定的例行升级流程备份与恢复方案发布前先有恢复路径,而不是出事后补救原文档还有一条容易被忽略的管理要求:在公开暴露服务器之前,先确认谁负责更新、谁负责监控、谁负责事故响应。这条在仓库后续运维章节(5.9 服务器加固与维护)中被扩展为月度维护清单(检查安全更新、监听端口、备份恢复演练、磁盘与日志轮转、账号与 SSH 访问、证书续期、DNS 变更复核等 10 项),免费域名项目如果由个人长期维护,建议把这份清单当作责任到人的落地工具。三、第一步:更新系统sudo apt update sudo apt upgrade两点实操注意(均来自原文档与运维章节):生产服务器上确认升级前,先审阅包变更——sudo apt upgrade会输出将被升级/安装的包列表,留意内核、Web 服务器、Python 等基础组件的大版本变化;大版本变更应在非生产环境先验证,不要因为没有排定维护窗口就无限期拖延关键安全更新(5.9 加固章节对补丁管理有完整的例行要求:OS 更新、Web 服务器更新、运行时更新、依赖更新、内核重启与回滚验证)。四、第二步:安装 Nginx 并验证服务sudo apt install nginx安装后立即做两件事验证:systemctl status nginx --no-pager sudo ss -lntpsystemctl status确认服务单元处于 active (running) 状态;sudo ss -lntp列出实际监听端口与进程。Nginx 应当监听 80 端口(Debian/Ubuntu 发行版默认启用sites-enabled/default时即为如此)。原文档在此处强调了一个安全底线:不要把无关的管理端口暴露到公网。可以结合 5.9 加固章节的监听器盘点方法,对ss -lntup输出中的每个监听进程记录:进程属主、绑定地址、端口协议、业务用途、是否必须公网可见、更新责任人;没有属主或用途的,在确认依赖后禁用或移除。例如如果ss -lntp显示某个端口绑定在0.0.0.0而非127.0.0.1,就应怀疑它是否真的需要对外。五、第三步:创建站点目录以example.dpdns.org(US.KG 教程体系中的示例域名,实际请使用你注册的.dpdns.org/.us.kg等域名)为例:sudo mkdir -p /var/www/example.dpdns.org sudo chown -R $USER:$USER /var/www/example.dpdns.org参数说明:-p:路径中间不存在时一并创建,目录已存在不报错;chown -R $USER:$USER:把目录属主改为当前普通用户。这样部署文件时不需要每次 sudo,而 Nginx worker 进程只需读取权限即可服务静态文件,符合加固章节中Web 服务器通常只需要读访问,而不是拥有所有源文件和配置文件的最小权限原则。站点文件拷贝到该目录时,应使用能保持预期属主与权限的部署方式。教程下一章(3.5 部署并连接域名)给出的标准做法是从本地站点父目录执行:rsync -av --delete ./my-first-site/ user192.0.2.10:/var/www/example.dpdns.org/注意--delete会删除目标端本地不存在的文件,原文档特别提醒:在确认源路径与目标路径无误之前不要加--delete。拷贝完成后在服务器上验证:find /var/www/example.dpdns.org -maxdepth 2 -type f -print sudo nginx -tfind用来确认文件确实落位,nginx -t用来确认配置在文件就位后依然合法。六、核心:配置一个 Nginx 虚拟主机这是全章技术密度最高的部分。原文档给出完整的站点配置文件/etc/nginx/sites-available/example.dpdns.org:server { listen 80; listen [::]:80; server_name example.dpdns.org www.example.dpdns.org; root /var/www/example.dpdns.org; index index.html; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/example.dpdns.org.access.log; error_log /var/log/nginx/example.dpdns.org.error.log; }逐项解释,便于理解每个指令在请求处理中的作用:listen 80;/listen [::]:80;:分别监听 IPv4 与 IPv6 的 80 端口。两行并存时,服务器才能同时响应两种地址族的请求——这也呼应了前置条件中IPv4、IPv6 或两者的要求;如果服务器没有可用的 IPv6,可省略[::]这一行,避免报错。server_name example.dpdns.org www.example.dpdns.org;:定义该虚拟主机应答的Host请求头。把裸域与www都写进来,是为了在后续(3.5 章节 Step 6)选定规范主机名(canonical hostname)并配置 308 重定向之前,两个名字都能直接命中同一个站点;选定后应在配好 HTTPS 的情况下把另一个名字重定向走。root /var/www/example.dpdns.org;index index.html;:静态文件根目录与首页文件,与第五节的mkdir目录一一对应。try_files $uri $uri/ 404;:先按文件路径找,再按目录找(配合index指令解析目录首页),都找不到就返回 404。这是静态站点的标准兜底写法,避免把不存在的请求交给后续处理逻辑。access_log/error_log:为这个站点单独建日志文件,而不是混在全局默认日志里。多站点共存时,按站点切分日志是排障效率的关键——教程 3.7 动态应用章节诊断502时用的就是sudo tail -n 100 /var/log/nginx/example.dpdns.org.error.log这类站点专属日志。同时注意加固章节对日志的要求:轮转防止占满磁盘、限制访问、避免记录敏感内容。启用配置并热加载:sudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org sudo nginx -t sudo systemctl reload nginx这是 Debian/Ubuntu Nginx 包的典型available/enabled 双目录模式:sites-available保存配置原件,sites-enabled通过软链接决定哪些配置被主配置 include。原文档对此有一句硬性要求:nginx -t配置测试必须先成功,再执行 reload;测试失败时 reload 应被跳过,以免带着坏配置热加载。reload是平滑热加载(不中断存量连接),区别于restart。七、改 DNS 之前:用 Host 头直接测试虚拟主机DNS 记录还没指向服务器(或正在等待 TTL 过期)时,可以直接指定目标 IP 并用Host请求头冒充域名,验证虚拟主机是否按预期命中:curl -I -H Host: example.dpdns.org http://192.0.2.10(把192.0.2.10换成你的真实服务器 IP。)预期返回HTTP/1.1 200且Content-Type为 HTML。这一步的价值在于把虚拟主机配置是否正确与DNS 是否生效两个变量解耦:该命令返回 200,而真实域名访问不通 → 问题在 DNS、防火墙或路由;该命令就返回 421/404/403 → 问题在 Nginx 配置本身。这也是原文档的表述:此测试无需等待 DNS 即可验证目标虚拟主机。八、防火墙检查原文档要求:使用服务器上已选定的防火墙体系,只放行必需的入站服务。对一台静态网站服务器,最小放行集是:端口/协议用途TCP 80HTTP 请求,以及后续的证书签发验证流程(3.6 章节中 ACME 域名控制验证依赖该端口)TCP 443HTTPS管理访问(如 SSH)应尽可能收紧,按实际的恢复路径与网络设计限制来源地址;并且IPv4 与 IPv6 的防火墙策略需要分别确认(见 5.9 加固章节的 Firewall Design 一节:默认拒绝未请求的入站流量,再逐项放行)。一个实用的核对方法是结合第四节的监听盘点:sudo ss -lntup中每一个对公网可达的监听端口,都必须能在必需服务清单里找到对应项,否则要么关监听,要么进防火墙豁免并说明理由。九、完成判定与后续衔接按本章流程做完后,服务器应满足以下可验证状态:sudo ss -lntp显示 Nginx 监听 80(及可选 443),且无意外公开端口;sudo nginx -t通过,站点配置已软链进sites-enabled并 reload 生效;站点目录/var/www/你的域名已建好、属主为普通用户,可用 rsync 部署;curl -I -H Host: 域名 http://服务器IP返回 200;防火墙仅放行 TCP 80/443 与受控的管理端口。满足以上条件后,教程的下一步是 3.5 部署并连接域名:用 rsync 推送站点文件,在外部权威 DNS 服务商(而非域名注册界面)创建 A/AAAA 记录与www的 CNAME,用dig A/AAAA/CNAME验证解析,再用curl -I http://example.dpdns.org验证端到端可达;若 DNS 查询成功但 HTTP 超时,原文档给出的判断是通常是服务器、防火墙或路由问题。之后再进入 3.6 启用并验证 HTTPS,用 ACME 客户端自动签发覆盖裸域与www两个主机名的证书,并配置 308 重定向与续期测试。十、常见坑位小结综合本章与教程后续章节,列出高频问题:nginx -t失败仍执行 reload:原配置回滚困难、站点不可用;严格保持先测试、后加载的顺序;rsync --delete路径写错:目标站点被清空;先不加--delete跑通,再启用;只测了localhost就改 DNS:本机测试绕过了防火墙与公网路由,必须用带Host头的公网 IP 测试(第七章)作为最后一道本地关卡;www名字未纳入server_name:裸域能访问但www落到默认站点或 421;IPv6 记录指向不可达地址:3.6 章节在证书申请前检查项中特别点名没有指向不可达服务器的陈旧AAAA记录,否则解析成功但连接超时,且证书验证流程可能被干扰;忘了备份与责任分工:发布前没有可回滚的旧文件/旧 DNS 值,事故时无法按3.5 章节的 Rollback 流程恢复(恢复旧 DNS 值或旧文件、旧服务保持运行直至缓存 DNS 过期、重试前先记录失败证据)。参考(仓库内相关文档)3.4 准备 Linux Web 服务器(本文主体)3.5 部署并连接域名3.6 启用并验证 HTTPS3.7 动态应用与反向代理5.9 服务器加固与维护Part 3 章节总览【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 US.KG 实战指南:为免费域名准备一台 Linux Web 服务器(Nginx 静态站点部署全流程)
US.KG 实战指南:为免费域名准备一台 Linux Web 服务器(Nginx 静态站点部署全流程)【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG本文基于 US.KG(DigitalPlat FreeDomain)教程第 3 部分构建并发布网站中的服务器准备章节展开,系统讲解如何在一台 Debian/Ubuntu 服务器上用 Nginx 搭建一个可直接接入免费域名(如example.dpdns.org)的静态站点:从系统更新、安装验证、站点目录、虚拟主机配置,到改 DNS 之前的 Host 头测试与防火墙检查。读完本篇,你将能够独立完成一台可公开访问 Web 服务器的标准初始化,并为后续的 rsync 部署、域名解析与 HTTPS 启用打下基础。一、适用范围:Debian/Ubuntu Nginx,但原则通用本章教程以一个通用的 Debian 或 Ubuntu 系服务器加 Nginx 为例(见 3.4 服务器准备章节)。原文档明确指出:任何提供同等能力的 Web 服务器软件都可以替代,前提是该软件具备以下四项能力:HTTP 服务能力:能按请求路径返回静态文件;TLS 能力:后续第 3.6 章(启用与验证 HTTPS)需要在同一主机上终结 TLS;日志能力:能按站点分离 access log 与 error log;虚拟主机能力:能通过Host请求头区分同一 IP 上的多个域名,这是用一台服务器承载多个 US.KG 子域/域名时的关键。换句话说,Nginx Debian只是示例载体,真正要掌握的是这套HTTP TLS 日志 虚拟主机的工作模型。二、动手前:服务器前置条件清单原文档列出的服务器要求(五项)是整章的验收基线,建议在开机器之前逐条核对:要求说明公网 IPv4、IPv6 或两者域名 A/AAAA 记录必须能解析到真实可达的地址非 root 账号 sudo用普通用户登录,提权走sudo,避免直接以 root 操作入站 TCP 80/443 放行需同时满足网络侧防火墙与主机防火墙两层策略安全更新机制可用自动更新或固定的例行升级流程备份与恢复方案发布前先有恢复路径,而不是出事后补救原文档还有一条容易被忽略的管理要求:在公开暴露服务器之前,先确认谁负责更新、谁负责监控、谁负责事故响应。这条在仓库后续运维章节(5.9 服务器加固与维护)中被扩展为月度维护清单(检查安全更新、监听端口、备份恢复演练、磁盘与日志轮转、账号与 SSH 访问、证书续期、DNS 变更复核等 10 项),免费域名项目如果由个人长期维护,建议把这份清单当作责任到人的落地工具。三、第一步:更新系统sudo apt update sudo apt upgrade两点实操注意(均来自原文档与运维章节):生产服务器上确认升级前,先审阅包变更——sudo apt upgrade会输出将被升级/安装的包列表,留意内核、Web 服务器、Python 等基础组件的大版本变化;大版本变更应在非生产环境先验证,不要因为没有排定维护窗口就无限期拖延关键安全更新(5.9 加固章节对补丁管理有完整的例行要求:OS 更新、Web 服务器更新、运行时更新、依赖更新、内核重启与回滚验证)。四、第二步:安装 Nginx 并验证服务sudo apt install nginx安装后立即做两件事验证:systemctl status nginx --no-pager sudo ss -lntpsystemctl status确认服务单元处于 active (running) 状态;sudo ss -lntp列出实际监听端口与进程。Nginx 应当监听 80 端口(Debian/Ubuntu 发行版默认启用sites-enabled/default时即为如此)。原文档在此处强调了一个安全底线:不要把无关的管理端口暴露到公网。可以结合 5.9 加固章节的监听器盘点方法,对ss -lntup输出中的每个监听进程记录:进程属主、绑定地址、端口协议、业务用途、是否必须公网可见、更新责任人;没有属主或用途的,在确认依赖后禁用或移除。例如如果ss -lntp显示某个端口绑定在0.0.0.0而非127.0.0.1,就应怀疑它是否真的需要对外。五、第三步:创建站点目录以example.dpdns.org(US.KG 教程体系中的示例域名,实际请使用你注册的.dpdns.org/.us.kg等域名)为例:sudo mkdir -p /var/www/example.dpdns.org sudo chown -R $USER:$USER /var/www/example.dpdns.org参数说明:-p:路径中间不存在时一并创建,目录已存在不报错;chown -R $USER:$USER:把目录属主改为当前普通用户。这样部署文件时不需要每次 sudo,而 Nginx worker 进程只需读取权限即可服务静态文件,符合加固章节中Web 服务器通常只需要读访问,而不是拥有所有源文件和配置文件的最小权限原则。站点文件拷贝到该目录时,应使用能保持预期属主与权限的部署方式。教程下一章(3.5 部署并连接域名)给出的标准做法是从本地站点父目录执行:rsync -av --delete ./my-first-site/ user192.0.2.10:/var/www/example.dpdns.org/注意--delete会删除目标端本地不存在的文件,原文档特别提醒:在确认源路径与目标路径无误之前不要加--delete。拷贝完成后在服务器上验证:find /var/www/example.dpdns.org -maxdepth 2 -type f -print sudo nginx -tfind用来确认文件确实落位,nginx -t用来确认配置在文件就位后依然合法。六、核心:配置一个 Nginx 虚拟主机这是全章技术密度最高的部分。原文档给出完整的站点配置文件/etc/nginx/sites-available/example.dpdns.org:server { listen 80; listen [::]:80; server_name example.dpdns.org www.example.dpdns.org; root /var/www/example.dpdns.org; index index.html; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/example.dpdns.org.access.log; error_log /var/log/nginx/example.dpdns.org.error.log; }逐项解释,便于理解每个指令在请求处理中的作用:listen 80;/listen [::]:80;:分别监听 IPv4 与 IPv6 的 80 端口。两行并存时,服务器才能同时响应两种地址族的请求——这也呼应了前置条件中IPv4、IPv6 或两者的要求;如果服务器没有可用的 IPv6,可省略[::]这一行,避免报错。server_name example.dpdns.org www.example.dpdns.org;:定义该虚拟主机应答的Host请求头。把裸域与www都写进来,是为了在后续(3.5 章节 Step 6)选定规范主机名(canonical hostname)并配置 308 重定向之前,两个名字都能直接命中同一个站点;选定后应在配好 HTTPS 的情况下把另一个名字重定向走。root /var/www/example.dpdns.org;index index.html;:静态文件根目录与首页文件,与第五节的mkdir目录一一对应。try_files $uri $uri/ 404;:先按文件路径找,再按目录找(配合index指令解析目录首页),都找不到就返回 404。这是静态站点的标准兜底写法,避免把不存在的请求交给后续处理逻辑。access_log/error_log:为这个站点单独建日志文件,而不是混在全局默认日志里。多站点共存时,按站点切分日志是排障效率的关键——教程 3.7 动态应用章节诊断502时用的就是sudo tail -n 100 /var/log/nginx/example.dpdns.org.error.log这类站点专属日志。同时注意加固章节对日志的要求:轮转防止占满磁盘、限制访问、避免记录敏感内容。启用配置并热加载:sudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org sudo nginx -t sudo systemctl reload nginx这是 Debian/Ubuntu Nginx 包的典型available/enabled 双目录模式:sites-available保存配置原件,sites-enabled通过软链接决定哪些配置被主配置 include。原文档对此有一句硬性要求:nginx -t配置测试必须先成功,再执行 reload;测试失败时 reload 应被跳过,以免带着坏配置热加载。reload是平滑热加载(不中断存量连接),区别于restart。七、改 DNS 之前:用 Host 头直接测试虚拟主机DNS 记录还没指向服务器(或正在等待 TTL 过期)时,可以直接指定目标 IP 并用Host请求头冒充域名,验证虚拟主机是否按预期命中:curl -I -H Host: example.dpdns.org http://192.0.2.10(把192.0.2.10换成你的真实服务器 IP。)预期返回HTTP/1.1 200且Content-Type为 HTML。这一步的价值在于把虚拟主机配置是否正确与DNS 是否生效两个变量解耦:该命令返回 200,而真实域名访问不通 → 问题在 DNS、防火墙或路由;该命令就返回 421/404/403 → 问题在 Nginx 配置本身。这也是原文档的表述:此测试无需等待 DNS 即可验证目标虚拟主机。八、防火墙检查原文档要求:使用服务器上已选定的防火墙体系,只放行必需的入站服务。对一台静态网站服务器,最小放行集是:端口/协议用途TCP 80HTTP 请求,以及后续的证书签发验证流程(3.6 章节中 ACME 域名控制验证依赖该端口)TCP 443HTTPS管理访问(如 SSH)应尽可能收紧,按实际的恢复路径与网络设计限制来源地址;并且IPv4 与 IPv6 的防火墙策略需要分别确认(见 5.9 加固章节的 Firewall Design 一节:默认拒绝未请求的入站流量,再逐项放行)。一个实用的核对方法是结合第四节的监听盘点:sudo ss -lntup中每一个对公网可达的监听端口,都必须能在必需服务清单里找到对应项,否则要么关监听,要么进防火墙豁免并说明理由。九、完成判定与后续衔接按本章流程做完后,服务器应满足以下可验证状态:sudo ss -lntp显示 Nginx 监听 80(及可选 443),且无意外公开端口;sudo nginx -t通过,站点配置已软链进sites-enabled并 reload 生效;站点目录/var/www/你的域名已建好、属主为普通用户,可用 rsync 部署;curl -I -H Host: 域名 http://服务器IP返回 200;防火墙仅放行 TCP 80/443 与受控的管理端口。满足以上条件后,教程的下一步是 3.5 部署并连接域名:用 rsync 推送站点文件,在外部权威 DNS 服务商(而非域名注册界面)创建 A/AAAA 记录与www的 CNAME,用dig A/AAAA/CNAME验证解析,再用curl -I http://example.dpdns.org验证端到端可达;若 DNS 查询成功但 HTTP 超时,原文档给出的判断是通常是服务器、防火墙或路由问题。之后再进入 3.6 启用并验证 HTTPS,用 ACME 客户端自动签发覆盖裸域与www两个主机名的证书,并配置 308 重定向与续期测试。十、常见坑位小结综合本章与教程后续章节,列出高频问题:nginx -t失败仍执行 reload:原配置回滚困难、站点不可用;严格保持先测试、后加载的顺序;rsync --delete路径写错:目标站点被清空;先不加--delete跑通,再启用;只测了localhost就改 DNS:本机测试绕过了防火墙与公网路由,必须用带Host头的公网 IP 测试(第七章)作为最后一道本地关卡;www名字未纳入server_name:裸域能访问但www落到默认站点或 421;IPv6 记录指向不可达地址:3.6 章节在证书申请前检查项中特别点名没有指向不可达服务器的陈旧AAAA记录,否则解析成功但连接超时,且证书验证流程可能被干扰;忘了备份与责任分工:发布前没有可回滚的旧文件/旧 DNS 值,事故时无法按3.5 章节的 Rollback 流程恢复(恢复旧 DNS 值或旧文件、旧服务保持运行直至缓存 DNS 过期、重试前先记录失败证据)。参考(仓库内相关文档)3.4 准备 Linux Web 服务器(本文主体)3.5 部署并连接域名3.6 启用并验证 HTTPS3.7 动态应用与反向代理5.9 服务器加固与维护Part 3 章节总览【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考