建立自己的wordpress网站并nginx反向代理绑定域名签发证书

type

status

date

slug

summary

前置铺垫

WordPress 是一个开源的内容管理系统（CMS），广泛用于构建和管理网站。它最初作为一个博客平台出现，但随着功能不断扩展，现在已经成为全球最流行的网站建设工具之一。

首先假定你已经有了一台云服务器（以ubuntu22.04系统为例），安装了docker，1panel，并且拥有属于自己的域名（假设为blog.wp.top），并且已经将该域名进行了域名解析(比如托管到cloudflare平台上)，且域名已经绑定了自己服务器所在的ip地址；相关内容搜索网站“域名”，”1panel”关键词

安装wordpress

首先安装数据库，1panel面板—应用程序—选择mysql直接安装

再在1panel面板—应用程序—选择wordpress直接构建，任选一个端口号，比如8081

现在wordpress已经安装好了，按理来说应该直接通过 服务器ip地址：端口号 访问了，但是不着急，先不要访问，也不需要在服务器的控制台的安全组中打开8081端口;

正常人访问网页的理想状态肯定是直接通过域名访问，比如说直接在网址输入blog.wp.top 就可以直接入wordpress服务了，也就是说我们希望仅仅输入域名就可以达到输入 服务器ip地址:端口号 的效果，也就等效于服务器内部来说 127.0.0.1:端口号 的效果；

这里有一个前提那就是浏览器在解析域名的时候会默认使用 80(http)和443(https)端口，因此我们才可以简洁的只输入域名就可以访问各种服务，直接输入域名的本质就是在访问服务器的80和443端口；

但是wordpress服务是在服务器的8081端口，而不是80端口，该怎么办？我们希望的效果是我们输入域名，然后服务器80或443端口收到信息，转而访问服务器本地的 127.0.0.1:8081端口；这里就需要反向代理了，要将服务器的8081端口反向代理到80端口，这个时候就需要web服务器了，这里使用nginx；

nginx安装

依次执行下面的命令

现在nginx安装好了；做事要做全，这个时候想到，如果是http登陆的话，数据不加密，不安全，很多网站也会弹出安全提醒很闹心，这个时候我们要先给域名签一个证书；

给域名签名发证书

这里直接使用github的一个开源项目来对网站进行签名，这个项目可以做到一键安装证书，自动更新；

记得把下面出现的所有 blog.wp.top 都替换为自己的域名

安装.sh文件

生成证书

/var/www/html 这个路径知识为了生成临时文件用的，是啥都行，但是关键得有；

复制证书，将证书和私钥复制(用代码复制而非手动复制)到一个指定路径(自己创建路径，自己要记得)

记住这证书和私钥的路径，一会儿要用

自动更新acme.sh

现在域名已经签名成功了，浏览器通过域名访问我们的域名来访问我们浏览器，发现存在证书，就可以进行https加密连接了

接下来就要开始将服务器wordpress反向代理给80/443端口了，而80/443端口可以直接凭借域名访问

nginx反向代理(到此步安装已经全部结束)

这个步骤很简单，只需要修改nginx的配置文件即可

编辑配置文件：

在配置文件的空白处增加一个server块，内容如下：

重启nginx

上面配置文件做的事情就是监听80和443端口(443是https，有ssl加密)，浏览器通过域名访问到服务器的时候有请求头，当80或443端口发现域名是blog.wp.top的时候，就会根据对应server块执行动作，即location配置中的转发，如国端口发现的域名头部信息是blog.wp.top那么就会将服务转为本地的8081端口，因为是内部端口，因此并不需要打开8081端口，服务器对外仅仅展示80和443端口即可，更加安全；

至此一切完成，可以直接通过访问wordpress了！

之后再wordpress的仪表盘—设置里的图示例位置都改成自己的域名链接即可

💡

到此结束，网站已经搭建完成，后面的内容可以不看

总结

整体流程大致就是签名，这一块独立；然后就是:

直接输入域名—>浏览器直接定位到“https://服务器公网ip:443”—>nginx监听到找到域名信息在找到所对应的不同server块的设置—>将流量代理到设置好的内部端口

通过上面的内容也可以知道，不同的域名完全可以都绑定同一个ip地址，又因为默认在浏览器输入域名会统一导向443端口(输入http会默认导向80端口，但是浏览器默认是https因此是443端口)，因此完全可以说多个域名都可以访问同一个服务器的同一个端口；不用担心端口有负载，端口只是相当于一个不同的分类器本身并不承载流量，真正承载流量的是服务器本身的网关；而不同域名都导向同一个端口，nginx就是靠域名将他们分类，不同的域名对应一个不同的server块，而server块里则会执行不同的代理代理到本地的其他端口其他服务

名词等附加解释(扩展内容)

web服务器

web服务器和部署web服务的软件可以近似的理解为游戏引擎和游戏的关系(实际上不能，但方便理解)

web服务器也可以是个软件或者硬件系统；它的主要功能是存储、处理和提供 Web 页面（如 HTML 文件、图像、视频等内容）给用户。Web 服务器使用 HTTP（超文本传输协议）与客户端（通常是浏览器）进行通信。

虽然一些应用程序或软件可以直接处理 Web 请求，但 Web 服务器专门为处理 HTTP 请求和响应进行了优化，具备高效的性能、可靠性和安全性。它们有许多专门的功能，比如高效处理并发请求，优化的网络协议支持，安全性和访问控制，与应用程序解耦，与应用程序解耦与应用程序解耦，方便开发人员专注于应用本身，可以说web服务器是基础设施

常见web服务器软件有：

Apache HTTP Server：最常用的 Web 服务器软件之一，支持多种操作系统。

Nginx：高性能的 Web 服务器和反向代理服务器，适合大流量网站。

Microsoft IIS：由 Microsoft 提供的 Web 服务器，通常用于 Windows 服务器。

LiteSpeed：一个商业化的 Web 服务器，提供高性能和安全性。

代理和反向代理

代理（Proxy） 和 反向代理（Reverse Proxy） 都是网络中用来中介转发请求的技术，但它们的工作方向和用途有所不同。

1. 代理（Proxy）

代理是指 客户端 和 服务器 之间的中间人。代理服务器代表客户端向目标服务器发送请求，然后将服务器的响应返回给客户端。其主要功能是隐藏客户端的真实信息或缓存常见请求以提高性能。

工作流程：

客户端发送请求到代理服务器。

代理服务器将客户端请求转发到目标服务器。

目标服务器响应代理服务器，代理服务器将响应转发回客户端。

常见用途：

隐藏用户身份：代理服务器可以隐藏客户端的 IP 地址，替代客户端访问目标服务器。

内容过滤：代理服务器可以控制客户端可以访问哪些内容，通常用于企业或学校的网络环境。

缓存：代理可以缓存目标服务器的响应内容，当相同请求再次发送时，直接从缓存中返回响应，从而提高访问速度和减轻目标服务器负担。

访问控制：代理服务器可以限制或审查访问特定网站或服务的请求。

2. 反向代理（Reverse Proxy）

反向代理是代理服务器的一种形式，但它的工作方向是面向服务器而非客户端。也就是说，反向代理服务器代表 服务器 向客户端接收请求，然后将请求转发给后端服务器。客户端并不直接与目标服务器通信，而是与反向代理服务器交互。

工作流程：

客户端发送请求到反向代理服务器。

反向代理服务器将请求转发到适当的后端服务器。

后端服务器处理请求并返回响应给反向代理服务器。

反向代理服务器将响应发送给客户端。

在本次网站部署中可以将在docker部署的wordpress当作服务器来提供后端服务，我们的云服务器则是作为反向代理服务器

常见用途：

负载均衡：反向代理服务器可以根据负载均衡算法（如轮询、加权等）将请求分发到多台后端服务器，以提高性能和可靠性。

安全性：反向代理可以隐藏后端服务器的具体细节（如 IP 地址），保护内网服务器免受直接攻击。

SSL 终止：反向代理可以处理 SSL/TLS 加密解密工作，从而减轻后端服务器的负担，统一管理证书和加密。

缓存：反向代理可以缓存从后端服务器返回的静态内容，减少后端的请求压力，提高响应速度。

关于server块

在 Nginx 配置文件中，server 块是用于定义和管理一个虚拟主机的配置。每个 server 块代表了 Nginx 处理请求的一个独立配置，可以用来处理来自不同域名或 IP 地址的请求，并为其提供特定的响应

实际域名访问要么是https://要么是http://,都有’/’,niginx 的 location / 匹配到‘/’这个模式，后，那之后的行为就交给location / {} 大括号里的内容执行了

proxy_set_header Host $host;

作用：将客户端请求的 Host 头信息（即域名，例如 blog.wp.top）转发给后端服务器。
必要性：如果不设置，默认会使用反向代理服务器的 Host 值（例如 127.0.0.1），导致后端应用无法正确识别请求的域名，从而生成错误的链接。wordpress会跟进请求的头信息来构建新链接不如/login,那么127.0.0.1/login只能被服务器识别而无法被客户端识别，因此需要传递host信息，构建出blog.wp.top/login,客户端就能正常访问了

proxy_set_header X-Real-IP $remote_addr;

作用：将客户端的真实 IP 地址通过 X-Real-IP 头传递给后端服务器。后端应用或日志系统可以通过这个头获取客户端的真实 IP，而不是反向代理服务器的 IP。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

作用：将客户端 IP 和代理链通过 X-Forwarded-For 头传递给后端服务器。在多级代理的情况下，后端可以了解完整的代理链和客户端的真实 IP。

proxy_set_header X-Forwarded-Proto $scheme;

作用：将客户端使用的协议（http 或 https）通过 X-Forwarded-Proto 头传递给后端服务器。
必要性：后端应用需要知道请求是通过 http 还是 https 协议发起的，以便生成正确的资源链接（如图片、CSS、JavaScript 等）。至少再wordpress中，如果没有这段代码，网站会显示不全，没有图片，没有结构

proxy_redirect;

proxy_redirect default;或者不写；效果是打开代理转发，Nginx 会自动调整重定向 URL，确保它指向正确的外部地址，通常是最常用的配置。具体表现为加入后端服务返回url链接127.0.0.1:8081/login ，nigin会自动转换为blog.wp.top/login 以让客户可以正常访问
proxy_redirect off; ：禁止修改后端返回的 Location 和 Refresh 头部。如果后端返回的重定向指向内网地址（如 127.0.0.1:8081），客户端可能会尝试访问该内网地址，而不是外部代理地址（如 blog.wp.top），127.0.0.1:8081 在客户端自然是访问不了的
proxy_redirect <old-url> <new-url>; 明确指定当后端返回某个 URL（如 127.0.0.1:8081）时，Nginx 将其替换为外部 URL（如 blog.wp.top）。
因为wordpress会自动重整链接(通过proxy_set_header Host $host;)，因此如果设置了proxy_set_header Host $host; ，那么wordpress一定会返回blog.wp.top/login 这样的链接无序nginx调整重定向，因此这个参数在这里不管是启动还是不启动都没影响；

关于nginx配置

前面为了方便起见，直接在available里的default文件里增加了server块来配置反向代理，实际情况下应该是:

这样以后有新配置直接添加新文件即可，清晰明了

nginx的一些配置文件

/etc/nginx/nginx.conf：

这是 Nginx 的主配置文件，包含全局设置和服务器级别的设置。

在 nginx.conf 中，通常会使用 include 指令来加载其他配置文件，包括 sites-enabled/ 目录中的所有文件。

示例：

这样，sites-enabled/ 目录中的配置文件（符号链接指向 sites-available/ 中的实际配置文件）会被 Nginx 加载并生效。

/etc/nginx/sites-available/：

该目录存放所有可用的虚拟主机配置文件（server 块配置）。

这些文件可以包含每个网站或服务的配置，但 Nginx 不会自动加载这个目录中的文件。

配置文件本身并不生效，只有通过符号链接到 sites-enabled/ 目录中，才会被 Nginx 加载。

/etc/nginx/sites-enabled/：

该目录存放指向 sites-available/ 中配置文件的符号链接。

只有在 sites-enabled/ 中的符号链接文件，Nginx 才会加载并应用。通过这种方式，可以灵活地启用或禁用虚拟主机配置，而不需要修改 sites-available/ 中的配置文件。

关系总结：

nginx.conf 是主配置文件，它通过 include 指令将 sites-enabled/ 目录中的文件引入，从而启用其中的虚拟主机配置。

sites-available/ 存储所有可用的虚拟主机配置文件，它们没有直接生效，只有通过符号链接将其放入 sites-enabled/，Nginx 才会加载这些配置文件。

sites-enabled/ 存储启用的配置文件的符号链接，Nginx 只会加载和生效这个目录中的文件。

注意到sites-available 和sites-enabled 文件夹下默认就有default文件，他们是源文件和符号链接的关系

通过这种结构，Nginx 配置变得更加灵活和易于管理，可以方便地启用和禁用虚拟主机配置。

硬链接和软(符号)链接

符号链接（symlink）和硬链接（hard link）是文件系统中的两种不同的链接方式，它们之间的区别如下：

1. 符号链接（Symbolic Link, symlink）：

本质：符号链接是一个指向文件路径的特殊文件，它类似于快捷方式。它包含指向原始文件的路径信息。

特点：

可以跨文件系统（即链接的文件和目标文件可以位于不同的文件系统或分区）。
如果原文件被删除，符号链接将变成“悬空链接”（broken link），无法访问原文件。
符号链接可以指向目录。

创建命令：

2. 硬链接（Hard Link）：

本质：硬链接是原始文件的一个别名，它直接指向文件的 inode（文件的物理存储位置），而不涉及文件路径。

特点：

硬链接和原文件是完全平等的，删除硬链接和删除原文件都不会影响文件的数据，文件数据会一直存在，直到所有指向该 inode 的链接都被删除。
不能跨文件系统创建硬链接，即硬链接和原文件必须在同一个文件系统中。
硬链接不能指向目录（除非是超级用户权限）。

创建命令：

总结：

软链接（符号链接）和硬链接都可以使用与源文件不同的名字；软链接存储的是源文件的路径，硬链接指向文件的 inode，而不是文件的路径。inode 是存储文件元数据的结构

符号链接：是一个独立的文件，包含指向目标文件路径的内容，可以跨文件系统，但如果目标文件删除，符号链接会失效。

硬链接：是文件的另一个名称，不能跨文件系统，删除硬链接不会删除文件内容，除非所有链接都被删除。

什么叫同一和不同文件系统

同一个文件系统：

定义：同一个文件系统是指存储在同一磁盘或分区上的文件数据，它们共享同一文件系统格式（如 ext4、NTFS、FAT32 等）。

特点：

在同一文件系统内创建的硬链接是可以相互指向的，因为它们都使用相同的 inode 编号和存储方式。
不同的目录之间的硬链接也能有效工作，因为它们属于同一个文件系统。

不同文件系统：

定义：不同文件系统指的是存储在不同物理设备或分区上的文件系统，这些文件系统有不同的格式（例如，一个是 ext4 文件系统，另一个是 NTFS 文件系统）。

特点：

硬链接无法跨文件系统创建。由于每个文件系统都有自己的 inode 表，硬链接是基于 inode 编号的，而不同的文件系统有不同的 inode 编号，因此不能跨文件系统链接。
如果试图在不同文件系统之间创建硬链接，操作系统会返回错误。
符号链接（软链接）可以跨文件系统创建，因为它只包含文件路径，而不依赖于文件的 inode 编号。

需要注意的是，在 Windows 操作系统中，即使 C 盘和 D 盘都使用 NTFS 文件系统，它们通常被视为不同的文件系统，因为每个盘符对应的存储空间通常是一个独立的分区或物理磁盘，而硬链接是限制在同一文件系统（即同一分区）内的。

不同文件系统的 inode 编号（inode number） 是不一样的

inode 的文件系统特性：

inode 是文件系统的核心结构，用于存储文件的元数据（如权限、所有者、文件大小、文件数据块的指针等）。

每个文件系统都有自己独立的 inode 表，因此即使两个文件系统使用相同的文件系统类型（如都为 EXT4 或 NTFS），它们的 inode 编号也不会重复，因为它们是相互独立的。

inode 编号的生成方式：

inode 编号通常是文件系统内部分配的一个唯一标识，指向文件系统中具体的 inode 结构。

不同的文件系统可能有不同的编号规则和范围。例如：

EXT 系列文件系统（如 EXT4）：inode 编号通常是从 1 开始按顺序分配。
NTFS 文件系统：严格来说，NTFS 使用的是文件记录编号（File Reference Number），而不是传统 inode，但它起到类似的作用。
exFAT 文件系统：没有直接的 inode 概念，其文件元数据存储在文件分配表中。

跨文件系统差异：

不同文件系统的 inode 结构和编号机制是完全独立的，因此无法比较或通用。

例如，一个文件的 inode 编号在 EXT4 中可能是 1024，但在 NTFS 文件系统中可能没有对应的概念。

不同文件系统的 inode 编号是独立的，且编号规则与文件系统的设计相关，因此通常不具有可比性。如果需要跨文件系统标识文件，应使用操作系统级的路径或其他唯一标识符，而非依赖 inode 编号。

总结：

硬链接：只能在同一个文件系统内创建，因为它们基于 inode 编号，且不同文件系统的 inode 编号不同。

符号链接：可以跨文件系统创建，因为它们存储的是文件路径，而不是 inode 编号。

这样配置的优势

将新的配置文件添加到 sites-available 目录并通过符号链接到 sites-enabled 目录，相比于直接修改 sites-available 中的 default 配置文件，主要有以下几个优势：

1. 配置的可管理性和可维护性

更好的组织结构：将每个站点或服务的配置文件单独存放在 sites-available 中，能够更清晰地管理不同站点的配置。每个配置文件都有独立的命名和管理，使得每个站点的配置与其他站点分离，便于区分和管理。

清晰的版本控制：当你需要添加、修改或删除站点配置时，可以直接在 sites-available 中进行操作，避免对 default 文件进行多次修改，保持 default 文件的简洁性。你可以轻松查看历史配置，或者通过版本控制系统管理这些配置文件。

2. 灵活性

启用或禁用站点配置：通过符号链接到 sites-enabled，可以非常方便地启用或禁用站点配置。要禁用某个站点，只需要删除符号链接，而无需编辑原始配置文件。修改 default 文件会影响所有站点，因此不如通过符号链接的方式灵活。

避免修改默认配置：修改 default 文件意味着可能会修改全局配置，影响到其他站点或服务。通过使用 sites-available 和 sites-enabled，你可以确保每个站点的配置相对独立，避免对默认配置进行不必要的干预。

3. 便于测试和排错

启用/禁用站点配置时无需修改文件内容：如果你想暂时禁用某个站点配置，只需删除符号链接，而不必进入 sites-available 进行修改。这对于快速排查问题或者进行实验性配置更为高效。

保持原始配置不变：通过符号链接管理站点配置文件，可以确保原始的 sites-available 配置文件保持不变，这样在需要恢复配置时，不会对配置文件造成不可逆的更改。

4. 避免混乱

多个配置文件管理：如果你有多个站点或服务需要配置，修改 default 文件可能会造成配置的混乱。使用 sites-available 和 sites-enabled 的目录结构可以让每个站点的配置保持独立，避免多个站点共用一个 default 配置文件带来的冲突。

通过将配置文件放在 sites-available 中并通过符号链接到 sites-enabled，你可以更好地管理不同的站点配置，增加灵活性，避免修改全局配置，并且简化站点的启用和禁用操作。这种做法更加模块化、灵活且易于维护。

HTTP 3xx 状态码概述

HTTP 3xx 状态码用于表示请求需要进行重定向。通常，3xx 状态码用于指示客户端应该进一步操作（通常是重定向）才能完成请求。3xx 状态码可以分为几种类型，主要有 301、302、303、304、305、307 和 308，每个状态码都有不同的语义和用途。

常见的 3xx 状态码：

301 Moved Permanently（永久移动）

描述：此状态码表示请求的资源已经被永久移动到新的 URL。以后所有对该资源的请求应该使用新的 URL。

使用场景：通常用于网站结构调整、页面永久迁移等情况。

示例：客户端请求 /old-page 时，服务器返回 301 状态码，并重定向到 /new-page。

302 Found（临时移动）

描述：此状态码表示请求的资源临时被移到另一个位置。不同于 301，302 指示客户端后续请求仍应使用原 URL。

使用场景：当服务器需要临时将用户重定向到另一个位置（例如，进行某些测试、临时维护等），而不改变原始 URL。

示例：客户端请求 /maintenance 时，服务器返回 302，并将请求临时重定向到 /maintenance-page。

303 See Other（查看其他）

描述：此状态码表示客户端应该使用 GET 请求访问另一个 URL，即使原始请求使用的是 POST、PUT 等方法。303 是 302 的扩展，通常在处理表单提交后使用。

使用场景：通常用于 POST 请求后重定向到一个新的页面（例如，提交表单后展示结果页面）。

示例：客户端请求 /submit-form 时，服务器返回 303，并将请求重定向到 /thank-you，并强制使用 GET 方法访问。

304 Not Modified（未修改）

描述：此状态码表示自上次请求以来，请求的资源没有被修改。客户端可以使用缓存的版本，而无需重新下载资源。

使用场景：用于缓存机制，减少带宽消耗，提高性能。例如，浏览器检查文件是否更改，若没有更改，则不会重新加载该文件。

示例：浏览器发送一个带 If-Modified-Since 头的请求，服务器如果检测到资源没有改变，会返回 304。

305 Use Proxy（使用代理）

描述：此状态码表示请求的资源应该通过指定的代理访问。通常，代理服务器的 URL 会出现在 Location 头中。

使用场景：该状态码早期用于要求客户端通过特定代理访问资源，但它在 HTTP/1.1 中被废弃，因为它存在安全问题。

示例：

307 Temporary Redirect（临时重定向）

描述：与 302 类似，表示请求的资源临时移至其他 URL，但与 302 不同的是，307 要求客户端使用原始的 HTTP 方法（POST 仍然是 POST，GET 仍然是 GET）。

使用场景：在临时重定向场景中使用，而不会改变请求的 HTTP 方法。

示例：客户端请求 /temporary-redirect 时，服务器返回 307，并保持请求方法不变，重定向到 /new-location。

308 Permanent Redirect（永久重定向）

描述：与 301 类似，表示请求的资源已经永久移动到新的 URL，且与 307 不同的是，308 要求客户端使用原始 HTTP 方法。

使用场景：适用于需要永久移动资源的场景，并且与 307 不同，要求保留原始 HTTP 方法。

示例：客户端请求 /old-page 时，服务器返回 308，并保留 HTTP 方法不变，重定向到 /new-page。

状态码的细节和区别：

301 和 308：这两个状态码都表示永久重定向，客户端应该将请求 URL 更新为新的地址。不过，308 保证了客户端会继续使用原始 HTTP 方法，而 301 并不做强制要求。

302 和 307：这两个状态码都表示临时重定向，但 307 明确要求客户端保留原始的 HTTP 方法，而 302 可能会改变 HTTP 方法（例如将 POST 请求变为 GET 请求）。

304：并不真正进行重定向，而是告诉客户端它可以继续使用缓存的资源。这是 HTTP 缓存机制的一部分。

305：虽然这个状态码在规范中定义过，但由于安全问题，现代浏览器和 HTTP/1.1 已不再支持它。

3xx 状态码的实际使用场景：

301 Moved Permanently：用于网站结构调整、URL 永久迁移。

302 Found：用于临时资源移动、临时重定向。

303 See Other：用于 POST 请求后的重定向，通常用于表单提交后的重定向。

304 Not Modified：用于缓存验证，减少带宽消耗。

307 Temporary Redirect：用于临时重定向，保留原请求方法。

308 Permanent Redirect：与 301 相似，适用于永久重定向，且保留原请求方法。