企业官网建设流程全解析

1. 网站上了HTTPS，为什么还要再过一层Cloudflare

1.1 从“网站表名”说起：WordPress部署前容易被忽略的一件事

先说个很多人踩过的坑。用宝塔面板一键部署WordPress时，安装向导会问你数据库用户名、密码，还会让你填一个“网站表名”。很多人顺手就填了默认的wp_，觉得反正也没人看得到，结果网站上线不到一个月就被扫描工具扫到后台路径，紧接着就是一堆垃圾评论、暴力破解登录请求。

这里我建议你在一开始就把数据库表名前缀改掉，比如wp5x9_这种带随机字符的格式。原因很简单：WordPress默认表名在全网几乎一样，攻击者写个脚本就能批量探测/wp-login.php和wp_options表，改掉前缀等于给数据库层加了一把额外的锁。虽然不能说绝对安全，但至少能把绝大多数自动化扫描挡在外面。宝塔面板的WordPress一键部署界面里，这一步经常被当成无关紧要的选项，实际上它是整条安全链路里最省钱的一道防线。

1.2 HTTPS加密的边界：源站直连和CDN代理的本质区别

说回HTTPS。很多人有个误解，觉得“我装个SSL证书、浏览器地址栏出现小锁，网站就安全了”。这话只对了一半。HTTPS解决的是数据传输过程中的加密问题，它保证用户浏览器和服务器之间那段网络通道里的数据不被窃听、不被篡改。但它并不解决服务器本身是否容易被攻破、源站IP是否暴露、CC攻击能否打垮你的问题。

Cloudflare在这里扮演的角色，是把你网站整体“罩”在一层代理后面。用户访问的不是你的源站IP，而是Cloudflare的边缘节点；用户和Cloudflare之间是一段加密链路，Cloudflare回源到你的宝塔服务器又是一段加密链路。也就是说，HTTPS是分段加密的，中间任何一段裸奔，整条链路的安全承诺都等于白给。

我在实际运维中见过不少这样的配置：域名解析已经切到了Cloudflare，但服务器上宝塔面板里的SSL证书是自签的，或者干脆没配。结果就是浏览器到Cloudflare这段走HTTPS没问题，Cloudflare到源站这段却因为证书不受信任，回源要么报错要么降级成明文。所以“宝塔安装WordPress配置Cloudflare的SSL证书”这件事，本质上是把两段加密都补全，而不是只搞定浏览器那一头。

2. 宝塔面板装WordPress时的SSL前置准备

2.1 数据库前缀与WordPress应用中心选型的细节

如果你用的是宝塔面板的“WordPress应用中心”一键部署，安装界面里的数据库设置项一定要认真填。除了刚才说的表名前缀，还有几个细节值得注意：

• 数据库用户名不要用root，单独建一个专用账号，权限只给当前库，避免日后其他站点被拖库时殃及池鱼。
• 数据库密码别用宝塔自动生成的短密码，自己改成一串不低于16位的随机字符串，字母大小写、数字、特殊符号都带上。
• 站点目录建议单独建目录，不要把WordPress直接塞在/www/wwwroot/根目录下面，后面配伪静态、配缓存、配SSL都会方便很多。

选WordPress版本的时候，我建议直接装最新稳定版，别纠结“老版本插件兼容性更好”这种说法。WordPress官方会持续修补安全问题，老版本等于把已知漏洞挂在门上等人来试。宝塔应用中心里提供的版本通常都是官方打包的，装完直接在后台更新到最新即可。

2.2 开启HTTPS之前必须理清的证书链路

在动手配置SSL之前，先把证书链路搞清楚。HTTPS证书链一般分三层：根证书、中间证书、站点证书。浏览器内置了各大CA的根证书，中间证书通常由CA随站点证书一起签发，站点证书就是你在宝塔里上传的那张crt文件。

Cloudflare源站证书有点特殊。它并不是公共CA签发的浏览器通用证书，而是Cloudflare自己作为CA签发、专门用于Cloudflare边缘节点到你源站之间这段回源加密的证书。它的有效期最长15年，这对于站长来说是个好消息——不用像公共CA证书那样每90天或1年就要折腾一次续期。

这里要强调一个关键认知：Cloudflare源站证书不能替代你在Cloudflare后台里给用户端配置的公共SSL证书。用户访问你网站时，Cloudflare边缘节点出示的是Cloudflare自动管理的公共证书；而你的宝塔服务器上部署的是源站证书，只在Cloudflare回源时用到。这两者各管一段，别搞混。

如果你手头有阿里云或其他CA签发的免费证书，也可以用在源站上，但免费证书通常只有3个月或1年有效期，续期麻烦不说，一旦忘了续期，回源加密链路就会因为证书失效而报错。相比之下，Cloudflare的15年源站证书省心太多。

3. 网站接入Cloudflare CDN的正确姿势与常见坑

3.1 域名解析迁移：怎么把NS和DNS记录搬到Cloudflare

接入Cloudflare的第一步不是去宝塔里动SSL配置，而是先把域名的DNS解析权迁移过去。过程不复杂：在Cloudflare添加站点，它会要求你修改域名的NS记录到Cloudflare提供的两个地址。这一步取决于你的域名注册商，常见的有阿里云、腾讯云、GoDaddy等，去域名控制台把NS改掉就行。

改完NS之后有个等待期，通常几分钟到几小时。等Cloudflare显示生效后，你要在它的DNS管理界面里把现有的解析记录补全，包括A记录、CNAME记录、MX邮件记录、TXT验证记录等。这里有个容易翻车的点：有些人急着把所有记录都开成“橙色云朵”，也就是代理模式，结果把邮件服务器的MX记录也代理了，邮件收发直接炸掉。

我的习惯是：网站域名的A/CNAME记录开橙色云朵（代理+CDN加速），邮件MX记录保持灰色DNS Only，其他涉及API、SSH、FTP的解析也先保持灰色，等确认所有服务正常后再按需开代理。这样能最大程度避免“接入CDN之后网站图片加载不出来”“邮件发不出去”这类低级问题。

3.2 SSL/TLS加密模式的三种选择与常见误区

接入Cloudflare后，在它的“SSL/TLS”设置里可以看到加密模式选项，一般有Flexible、Full、Full（Strict）三种。很多新手在这里犯的第一个错误就是选了Flexible，原因很简单——因为浏览器访问网站依然是HTTPS，地址栏也有小锁。

但Flexible的意思是：浏览器到Cloudflare是HTTPS，Cloudflare到你的宝塔服务器却是HTTP明文。这意味着攻击者如果能在机房链路、CDN回源节点之间做中间人劫持，数据照样泄露。更麻烦的是，WordPress后台如果你强制HTTPS，但回源是HTTP，还会引发重定向循环，页面打开就是“重定向次数过多”。

正确做法是把加密模式设为Full（Strict），同时保证源站部署了有效且受信任的证书。Full和Full（Strict）的区别在于：Full只要求源站有证书，不校验证书是否可信；Full（Strict）会严格校验源站证书必须由受信任CA签发、且与域名匹配。既然我们已经在宝塔里部署Cloudflare源站证书，那就直接用Full（Strict），一步到位，避免中间出现证书信任缺失的问题。

4. Cloudflare源站证书的生成与宝塔部署细节

4.1 在Cloudflare侧申请15年源站证书的步骤

登录Cloudflare控制台，进入你的域名，左侧菜单找到“SSL/TLS”——“源服务器”，点击“创建证书”。这里会给你两个选项：一个是Cloudflare生成的密钥和CSR，另一个是你自己上传CSR。日常使用直接选Cloudflare生成的就行，省事。

创建时会让你填需要保护的域名，建议把根域名example.com和通配符*.example.com都勾上。这样以后你在源站上部署子域名站点时，同一张证书也能覆盖，不用每个子域名单独申请。Cloudflare源站证书有效期最长15年，选这个就对了。

生成之后，页面会展示两部分内容：证书（crt文件内容）和私钥（key文件内容）。这两段文本一定要完整复制保存，尤其私钥是唯一的，关掉页面就再也看不到了。我一般会把这个文件放到本地的密码管理工具里存一份，同时在服务器上留一份备份，但要注意私钥的权限必须是600或400，别让其他用户可读。

4.2 宝塔面板上传crt与key文件的正确姿势

回到宝塔面板，找到你要配置的WordPress站点，进入“SSL”管理界面。宝塔的SSL管理分好几种方式：Let's Encrypt自动申请、付费证书、自定义证书。我们要用的是“自定义证书”模式，因为Cloudflare源站证书的CA不是Let's Encrypt，宝塔的自动申请逻辑不适用于它。

操作步骤：

1. 把Cloudflare生成的crt内容完整粘贴到“证书”输入框。
2. 把私钥内容粘贴到“密钥”输入框。
3. 点击保存。
4. 在SSL设置里打开“强制HTTPS”，让所有HTTP请求301跳转到HTTPS。

这里有个顺序问题要注意：先部署证书，再开强制HTTPS。如果你先开强制HTTPS，服务器在还没有可用证书的情况下会反复重定向，浏览器最终报错。我在调试时遇到过好几次这种场景，看起来是“网站打不开了”，实际上是操作顺序搞反了。

还有一个细节：宝塔面板里粘贴证书时，有些人会不小心多复制一个空格或换行，导致证书格式错误。粘贴完之后最好点一下“查看”按钮确认内容格式正常。如果保存时报错“无法解析证书”，大概率是粘贴的crt内容不完整——检查开头有没有-----BEGIN CERTIFICATE-----，结尾有没有-----END CERTIFICATE-----。

部署完成后，别急着关页面。先回到Cloudflare后台上确认“SSL/TLS”的加密模式。如果你在宝塔里配好了证书，但Cloudflare这边还停在Full模式，虽然也能通，但建议直接切到Full（Strict），让回源链路也严格执行证书校验。

4.3 验证回源加密是否真的生效

配完之后怎么验证？一种办法是直接在服务器上执行curl命令测试源站证书：

curl -v https://你的域名 --resolve 你的域名:443:服务器IP

通过--resolve参数强制解析到源站IP，绕过Cloudflare，这样访问的就是你的宝塔服务器本身。如果证书链正常，curl不会报警告；如果证书域名不匹配或证书无效，curl会明确提示SSL certificate problem。

再一种办法是看Cloudflare的“SSL/TLS”概览页面，它会显示当前回源加密状态。如果显示“安全连接”，说明源站证书部署成功且被校验通过。

5. SSL连接错误与TLS版本问题的排查链路

5.1 “SSL连接错误”和“no required SSL certificate was sent”的根因

接入Cloudflare后最常见的报错就是“SSL连接错误”。这个报错在浏览器里通常是白屏加一行英文，但实际原因五花八门。我踩过的坑大概有这么几类：

• 回源策略是Flexible，但源站强制HTTPS：浏览器到Cloudflare是HTTPS，Cloudflare回源走HTTP，结果源站又301跳转到HTTPS，Cloudflare再回来请求，形成无限循环。这类报错的典型特征就是“重定向次数过多”。
• 源站证书域名不匹配：如果你证书里只包含example.com，但用户访问的是www.example.com，Cloudflare在回源时发现证书和域名对不上，就会拒绝连接。所以在创建源站证书时，把主域名和通配符域名都加进去，就是为了避免这个坑。
• 服务器防火墙或安全组没有放行443端口：这个问题很隐蔽。宝塔面板里就算开了SSL，如果云服务商安全组没放行443端口，外部访问一样失败。排查方法很简单，本地用telnet 服务器IP 443测试一下端口通不通。

“no required SSL certificate was sent”这个报错则是服务器端没找到可用的客户端证书，或者是证书链不完整导致的。它更常见于需要双向TLS认证的场景，比如某些企业接口、支付回调等。如果你的WordPress只是普通访问出现这个报错，优先检查宝塔里部署的crt文件是不是漏掉了中间证书，或者证书序列号是否过期。就算你用的是Cloudflare源站证书，也建议让它和公共证书的区别轻一些——别把Cloudflare的证书误部署到需要公开访问的nginx虚拟主机上，因为客户端浏览器不认Cloudflare CA，会直接报不受信任。

5.2 关闭不安全的TLS 1.0并检查SSL证书过期时间

搜索引擎热词里有个“宝塔面板 启用不安全的tls1.0协议怎么关闭”，这其实是个很值得展开的点。TLS是HTTPS的底层加密协议，TLS 1.0和TLS 1.1属于上古版本，存在多个已知漏洞，比如POODLE、BEAST这类攻击，很多安全合规检查（比如等保、PCI DSS）明确要求禁用。

在宝塔的网站设置——SSL——“加密协议”那里，默认可能勾选了TLS 1.0/1.1/1.2/1.3。建议把TLS 1.0和TLS 1.1的勾选去掉，只保留TLS 1.2和TLS 1.3。这个操作做完后，老旧的浏览器（比如Windows 7自带的IE8、部分老安卓WebView）可能无法访问，但正常用户的现代浏览器全部不受影响。如果网站面向的是国内普通用户，这个取舍完全值得做。

证书过期问题同样要警惕。虽然Cloudflare源站证书有效期长达15年，但如果你用的是宝塔的Let's Encrypt自动证书，或者阿里云的免费证书，它们通常只有90天或者1年。证书过期后浏览器会直接显示“您的连接不是私密连接”，用户点击“继续前往”虽然能打开页面，但地址栏会标红并提示不安全，这对站点信任度的影响是致命的。

在Linux服务器上可以用一行命令查看证书过期时间：

echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null | openssl x509 -noout -dates

它会输出证书的开始日期和结束日期。建议把这条命令写进一个定时监控脚本，每月自动检查一次，到期前30天发邮件提醒。别高估自己的记忆力，线上证书过期这种事，我几乎每年都能在技术群里看到有人踩。

5.3 一个真实的排查过程：从报错到定位到修复

有一次我给一个朋友的网站排查SSL连接错误，现象是：手机浏览器访问报错，电脑浏览器偶尔能打开，后台登录页反复跳转。

我第一反应是回源加密模式和源站证书不匹配。登录Cloudflare后查看加密模式，果然挂着Flexible。再看宝塔站点配置，强制HTTPS是开着的。这就形成了死循环：Cloudflare以HTTP回源，源站又要求HTTPS跳转，来回拉扯。

修复过程分三步：第一，把Cloudflare的加密模式从Flexible改成Full（Strict），确保回源走HTTPS；第二，确认宝塔的证书和私钥都存在且匹配，这一步其实在接入Cloudflare之前就应该完成；第三，清掉Cloudflare和浏览器两边的缓存，再重新访问。

这个复盘想说明的是：很多SSL报错不是“证书坏了”，而是“链路配置里有一段逻辑冲突”。排查时别急着怀疑证书，先把数据流向理清楚——用户请求到Cloudflare、Cloudflare回源到宝塔、宝塔返回响应，每一段分别走什么协议、用什么证书，逐一对齐，问题基本都能定位。

6. 多域名场景下的Cloudflare证书适配与日常维护

6.1 免费方案下多域名证书怎么安排

如果你只有一个站，上面讲到的方案已经够用。但很多人用宝塔面板往往不止一个网站，有的还挂了一堆子域名。这时候证书问题就要重新规划。

Cloudflare源站证书支持通配符，所以我刚才建议创建时勾选*.example.com，目的就在这里。你在宝塔里加一个新的子域名站点，比如blog.example.com，直接把同一张源站证书部署上去就行，不需要另外买证书。因为通配符证书对blog.example.com、shop.example.com这类子域名全部有效。

但如果你有多个顶级域名，比如一个企业官网用.com，一个内部工具用.cn，Cloudflare免费版源站证书的覆盖范围是有限制的。免费套餐创建源站证书时，每个证书可以包含一个顶级域名和它的子域名，不同顶级域名要单独创建证书。部署到宝塔时，每个站点各自上传对应的证书，互不影响。

这里顺便提一下宝塔的“多站点证书管理”。宝塔支持在站点设置里为每个站点单独配置证书，所以多域名场景下，你不需要像某些老教程那样手动改nginx配置文件，直接在面板里切换站点、上传证书就行。注意不要搞混，我有一次同时配置了三四个网站的证书，结果一时手滑把A站的证书传到了B站，浏览器立刻报域名不匹配，排查了半小时才发现是这种低级错误。

6.2 证书排期、自动续期与日常巡检清单

证书部署完之后，日常维护的重点是三件事：备份、监控、续期。

备份方面，宝塔的“SSL证书”管理页里通常会保留证书列表，但建议你在本地也存一份crt和key的副本。Cloudflare源站证书虽然不常更新，但万一服务器硬盘坏了要重装宝塔，你得有原始文件能恢复。

监控方面，我推荐用两种方式双保险。第一种是crontab定时任务，每个月跑一次证书过期时间检查，把结果输出到日志文件；第二种是直接在Cloudflare后台开启邮件通知，证书快过期或出现异常时它会给你发邮件。如果不想自己写脚本，也可以用UptimeRobot这类外部监控服务，把HTTPS探测加进去，每5分钟检查一次网站是否正常返回200。

续期方面，Cloudflare源站证书15年有效，基本不用操心；Let's Encrypt证书宝塔可以设置自动续期，这条对阿里云免费证书不适用——阿里云免费证书到期后通常需要手动申请新证书并重新上传。所以如果你用的是阿里云这类公共CA证书，最好在日历上设个提醒，提前两周处理，别等到报错那天才手忙脚乱。

日常巡检我一般按这个清单走：

• 检查网站首页是否正常返回HTTPS，有没有混合内容警告（图片、JS、CSS用的是HTTP）。
• 检查Cloudflare“SSL/TLS”概览页面里的加密模式和证书状态。
• 检查宝塔站点日志里有没有大量TLS握手失败的记录，这通常是异常扫描的特征。
• 检查服务器443端口是否被防火墙规则误挡，特别是阿里云、腾讯云这类安全组配置。
• 顺手看一眼WordPress后台的“站点健康”报告，它会提示HTTPS状态、PHP版本、数据库错误等。

这个清单看起来很基础，但绝大多数线上SSL问题，都是从这些“基础项”里长出来的。

最后再分享一个我在实际使用中的体会：Cloudflare源站证书加Full（Strict）这套方案，最大的优点不只是省了续期的麻烦，而是它强迫你保持源站配置的干净和规范。你一旦把宝塔、WordPress、Cloudflare这三层之间的关系理顺，后面再做性能优化、缓存配置、安全防护都会顺很多。SSL证书本身不复杂，复杂的从来都是链路里的每一环是否各就各位。