Cloudflare SSL Full 和 Full Strict 怎么选？WordPress 跳转循环这样排查
WordPress 接入 Cloudflare 后，最常见的 SSL 问题不是证书“有没有开启”，而是 Cloudflare 到源站这一段到底怎么连。SSL/TLS 模式选错，可能出现 ERR_TOO_MANY_REDIRECTS、后台进不去、首页在 http 和 https 之间来回跳、Elementor 预览失败、WooCommerce 回调异常。处理前先备份网站文件、数据库和服务器配置；如果要改 .htaccess、Nginx 规则或 WordPress 地址，务必保留回滚方案。
Applicable Scenarios
本文适合已经把域名 DNS 接入 Cloudflare，并在 SSL/TLS 面板看到 Flexible、Full、Full (strict) 等选项的网站。典型表现包括：浏览器提示重定向次数过多；开启 Cloudflare 小云朵后报错，暂停 Cloudflare 后正常；WordPress 后台地址一会儿变 http 一会儿变 https；安装 Really Simple SSL 或类似插件后循环加重；源站明明有证书，但 Cloudflare 仍显示 525、526 或跳转错误。
Full 和 Full Strict 的区别
Cloudflare 官方说明，SSL/TLS 加密模式控制两段连接：访客浏览器到 Cloudflare，以及 Cloudflare 到源站服务器。Full 和 Full (strict) 都会让 Cloudflare 使用 HTTPS 连接源站，区别在于校验证书的严格程度。Full 需要源站能提供 HTTPS，但不会严格验证源站证书是否由受信任机构签发、是否过期、域名是否匹配。Full (strict) 则要求源站证书有效、未过期，并且证书覆盖当前主机名，可以是受信任 CA 证书，也可以是 Cloudflare Origin Certificate。
因此，长期生产站建议目标是 Full (strict)。Full 可以作为过渡方案，例如源站 HTTPS 已经可用但证书链暂未整理完成；Flexible 不建议用于 WordPress 正式站，尤其是源站本身会强制 HTTP 跳 HTTPS 时，它非常容易造成循环跳转。
为什么会跳转循环
跳转循环本质是多处规则互相打架。Cloudflare 可能把访客请求转为 HTTPS，源站又根据收到的协议判断为 HTTP，然后再次跳到 HTTPS；或者 WordPress 地址写的是 HTTPS，但服务器规则又把部分路径跳回 HTTP；也可能 Cloudflare 的 Always Use HTTPS、Automatic HTTPS Rewrites、Redirect Rules、Page Rules，与主机面板、.htaccess、Nginx、SSL 插件重复执行。官方关于重定向过多的说明也明确指出，SSL/TLS 模式、边缘证书设置和重定向规则都可能触发循环。
按顺序排查
1. 先确认源站 HTTPS 是否真实可用。在 Cloudflare 暂停代理或将 DNS 记录临时改为灰云测试前，要确保你知道源站 IP 和回滚方式。可以通过主机面板、命令行或临时 hosts 指向源站访问 https://example.com。如果源站 HTTPS 本身打不开、证书过期、证书域名不匹配，就不要直接选 Full (strict)，先修源站证书。
2. 不要用 Flexible 修 WordPress HTTPS。Flexible 的逻辑是浏览器到 Cloudflare 加密，但 Cloudflare 到源站走 HTTP。若 WordPress、主机或插件强制 HTTPS，源站会把 HTTP 请求重定向到 HTTPS，Cloudflare 又按 Flexible 回源 HTTP，循环就形成了。解决思路不是继续叠加跳转插件，而是给源站配置证书，然后切到 Full 或 Full (strict)。
3. 在 Cloudflare 中选择正确模式。如果源站已经安装有效证书，直接选 Full (strict)。如果源站证书临时是自签、过期或域名不匹配，只能短期用 Full 过渡，但应尽快换成有效证书。若使用 Cloudflare Origin Certificate，要确认它安装在源站，并覆盖根域名和 www 等实际访问主机名。
4. 检查 WordPress 地址。进入后台“设置 > 常规”，确认 WordPress 地址和站点地址都使用最终规范域名，例如统一为 https://www.example.com maybe https://example.com。如果后台进不去，可检查 wp-config.php 是否硬编码了 WP_HOME,WP_SITEURL，以及数据库中 home,siteurl 是否一致。不要一边强制 www，一边在 Cloudflare 又强制非 www。
5. 合并跳转规则。只保留一个地方负责 http 到 https，一个地方负责 www 与非 www 规范化。Cloudflare 的 Always Use HTTPS、Redirect Rules、服务器 Nginx/Apache 规则、WordPress SSL 插件都能做跳转，但不应重复。建议先临时关闭 SSL 插件的自动修复和多余 Page Rules，再逐步恢复必要规则。
6. 检查反向代理协议识别。WordPress 在 Cloudflare 后面时，源站看到的可能是代理请求。部分环境需要正确识别 HTTP_X_FORWARDED_PROTO，否则 WordPress 会误以为当前请求是 HTTP，不断生成 HTTPS 跳转。此处不要随意复制网上代码到生产站，先确认主机环境和现有配置，必要时让主机商处理。
Validation Methods
验证不要只看浏览器能不能打开首页。先用无痕窗口访问 http 根域名、https 根域名、www 与非 www 四种组合，最终都应只跳到一个规范地址。再检查 WordPress 后台、媒体库、Elementor 编辑器、WooCommerce 结账和支付回调路径。浏览器开发者工具 Network 面板可以看到 301/302 链路；如果 http 与 https 来回出现，说明循环仍未解决。Cloudflare 侧还要观察是否出现 525、526，Full (strict) 下这些错误通常指向源站证书或握手问题。
Common Misconceptions
误区一：认为 Cloudflare 证书已启用就等于源站证书没问题。Cloudflare 边缘证书只覆盖访客到 Cloudflare，不等于 Cloudflare 到源站也验证通过。误区二：用 Flexible 加 SSL 插件强行变绿锁，这在 WordPress 上很容易循环。误区三：同时在 Cloudflare、宝塔/主机面板、.htaccess、插件里写多套跳转。误区四：Full 比 Full (strict) “更稳定”。Full 只是更宽松，不验证源站证书有效性，安全性不如 Full (strict)。误区五：只修首页，忘记后台、API、支付回调和 sitemap。
FAQ
Cloudflare Full 可以长期用吗？
能运行不代表最佳。Full 会加密到源站，但不严格校验证书。正式站建议修好源站证书后使用 Full (strict)。
Full Strict 一开就 526 怎么办？
优先查源站证书是否过期、域名是否匹配、证书链是否完整。不要用关闭验证掩盖长期问题，可先短期切 Full 保持访问，再修证书。
Really Simple SSL 还需要吗？
不一定。若服务器和 Cloudflare 已正确处理 HTTPS，SSL 插件可能只是重复跳转。保留前要确认它没有制造额外 301/302。
Internal Link Suggestion
- 链接到：WordPress ERR_TOO_MANY_REDIRECTS 常见原因
- 链接到：Cloudflare 缓存规则怎么排除后台和结账页
- 链接到：WordPress 更换 HTTPS 后图片混合内容修复
- 链接到：WooCommerce 支付回调被 Cloudflare 拦截怎么排查
晚间质量补充：按自动化运营标准复核
本段为晚间复盘补充，目的是把文章从单点排查扩展成可执行的运营清单。对 361sale 这类教程站来说，一篇文章不能只回答“哪里坏了”，还要告诉读者如何记录现象、如何分层排查、如何在修复后验证缓存、移动端和权限。这样后续做 WordPress、Elementor、主题设置、OpenClaw 自动化排期时，才能复用同一套方法。
如果团队已经接入 OpenClaw，可以把排查流程拆成三个动作：先让定时任务检查状态码、发布时间和截图素材；再让写作代理补齐标题、H2/H3、内链、外链和配图；最后由复盘代理在晚间抽查字数、分类、特色图和前台显示。OpenClaw 官方文档可参考 docs.openclaw.ai，用于理解后台任务、频道通知和多 Agent 协作。
- 内链至少覆盖一个教程分类、一个问题排查入口和一个相关工具页。
- 外链只放官方文档或权威说明，避免堆砌无关资源站。
- 每次修复后用无痕窗口确认前台图片、目录和缓存是否刷新。
- 如果是 WP-Cron 漏发，应记录 missed schedule 的文章 ID 和原计划时间。
延伸阅读：WordPress Tutorial,Elementor Tutorial,WordPress 报错排查The
Link to this article:https://www.361sale.com/en/88002/The article is copyrighted and must be reproduced with attribution.
简体中文 
English 
0
Now definitely still do SEO, just play changed. Previously rely on heaps of content, heaps of keywords can have traffic, and now pay more attention to the quality of content + brand trust + user experience. In addition to relying solely on SEO is actually more and more difficult, a lot of good basically SEO + social media + content marketing + private domain conversion to do together. SEO is still a long-term customer acquisition channel, but can no longer be taken as the only channel.Hehe is working.
March 11, 10:540
Normal, included only on behalf of Google to see the page, does not mean that the ranking immediately, "has been included but not ranked" usually because: Keyword competition, page weight is low, the content is not strong enough, the page is relatively new. Continue to optimize the long-tail keywords, content quality and internal chain, usually takes a little time, the ranking will slowly come out!Amelia Foster March 6, 16:200
Do you have a screenshot?lit. even a son who is not a fish knows the joy of fish March 6, 09:230
Don't pile on the optimization plugins first, locate the bottlenecks first: Use Query Monitor to see slow SQL, slow hooks. Pause all plugins for comparison, then turn them on one by one. Check autoload is too big (options table). Check database indexes with large table queries. Tackle host/database performance first if server TTFB is high.Hehe is working.
March 3, 16:470
Hi Windjammer, there's really no need to mess with complicated local environments, regular people follow these steps and the update basically won't crash the site 👇 First, backup the whole site, files + database are prepared, this is the bottom line, out of the problem can be a key to go back. Don't change the whole thing in one click, change it in batches, change the unimportant plug-ins first, and then change the core ones. Immediately after the update, clear the cache, go to the foreground to check the home page, article page, buttons, forms, these key positions. It is best to install a plug-in that supports version rollback, in case of a crash, cut back to the old version in a second. To summarize: backup first, change in batches, check after changing, leave a way back, stable ✅😎 Hope this helps!bugbang March 2, 09:550
Usually it's not that the payment didn't work, but that the callback (webhook) didn't write back the order status. Troubleshooting steps: WooCommerce → Status → Logs: see if the payment gateway has webhook error / signature error / timeout Check if the site is blocked by WAF (Cloudflare, Pagoda Firewall, security plugins) Check if "Cache checkout pages/interface paths" is enabled (checkout pages and callback interfaces should not be cached) Look at the server error logs for 500/fatal errors that interrupt the callback execution. Solution: Release wp-json, wc-api, payment gateway callback URLs (configure as per gateway documentation) Disable cache and JS merge compression test on checkout page once If using Cloudflare: set no-challenge, no-block rules for callback URLsUlla Nala Zhenhuan (18嬛嬛嬛) January 31st, 09:360
1) Determine whether it is "Normal Waiting" or "Abnormally Stuck". You can first look at 3 signals: whether the page release time is within 7-14 days, whether there are only a small number of pages with this status, and whether the page has appeared in the XML Sitemap. If all three are satisfied, most likely belong to the normal crawling and evaluation stage, do not need to do it immediately. 2) Under what circumstances is it useless to "wait"? The following cases will not be solved automatically by time: the page has almost no internal links (isolated page), the content is highly similar to the existing pages on the site, canonical points to other URLs, and too many similar articles are published on the same topic for a short period of time. In this case, Google has been crawled, but judged that "it is not worth entering the index". 3) The most effective way of manual intervention (no tossing) Prioritize these 3 things: add internal links, link to the page from related old articles or columns, and enhance the density of information on the first screen. The first 2-3 paragraphs directly answer the user's question, avoid too much padding, confirm canonical as self-referential, avoid being judged as a duplicate page, and then go to GSC to request reindexing after doing so. 4) What "intervention actions" are counterproductive? It is not recommended: frequent deletion and re-posting, clicking "request to index" several times in a row, forcing keywords to be stacked for the sake of indexing, changing URLs or titles arbitrarily. These operations will allow Google to reassess the stability of the page, but slow down the inclusion. 5) a practical judgment standard If an article: has been crawled, there is no noindex / robots problem, there are at least 1-2 related internal links, the content obviously solves an independent problem, then it is included, just a matter of time, not a plug-in problem.Post Porter January 30th 10:000
The new station does not do external links can be completely, the first content and station structure to do a good job more stable. Only rely on the content can generally get included and part of the long-tail word rankings, but the amount of high competition will be slow. It is recommended to wait for the site stable inclusion, 30-50 quality content, keywords began to enter the top 20/30, and then a small amount of external links, priority brand words/naked chain/citation type, do not come up to chase the number. 👍