测试内容：
多线程跑满（基本可稳定 9.7~10G ）
晚高峰持续负载情况
移动出口跨网访问情况
下载/上传双向大流量的持续波动情况
连续跑 24h 的带宽曲线
适用场景：
VOD/视频点播
CDN 回源
下载站/游戏分发
大文件下载/分发
链路传输/私有云外放
当前疑问：
单线 vsBGP 对业务的影响
长时间满负载是否会遇到 QoS
是否有人长期跑 10G 独享可以分享经验
如果你正在做大带宽业务或者也在看类似节点，欢迎交流经验。 ]]>
我遇到过的几个典型：
1 回源带宽不够（ CDN 高峰回源更猛）
2 源站 CPU/IO 卡住
3 跨省返程高峰拥堵
4 源站丢包导致回源失败
CDN 的压力通常远比大家想象的大，所以源站链路一定要稳。
有做 CDN 回源的站长可以交流下经验。 ]]>
对比其他边缘加速产品，总给我一种，你表扬我，我给你好处的即视感。
如果产品真的好，直接说“免费送 3 个月，体验后分享真实感受”，自然会有用户夸。非要搞“对比竞品”，真的有点突破我对阿里的印象了
大家觉得呢，欢迎留下你的观点 😆
]]>给大家介绍我们在 2025 年都做了什么，如何一步步打造产品。
在多云架构盛行的今天，越来越多组织希望掌控自己的应用安全和交付，而 自建私有 CDN （ Private CDN ） 正在成为一种新的趋势。
本文将分享 AxisNow 打造企业级自建 CDN 平台的五大关键能力支柱，以及我们如何将这些大型互联网公司才有的技术平民化，并一步步构建出属于自己的私有边缘网络。
一、从边缘代理开始：高性能与高可靠性的基础（ 2025 Q1 ）
CDN 的最基本原理，本质上是一个 反向代理（ Reverse Proxy ）。
过去十年，围绕反向代理诞生了大量不同用途的技术：负载均衡、API 网关、安全防护、加速传输等。
AxisNow 的产品之路，也从这里开始。
我们的首个最小可行产品（ MVP ）是一款 可部署在 Linux 环境中的分布式边缘代理。
在选择底层技术栈时，我们对 性能、可靠性、扩展性、安全性 进行了全面评估。
经过对比 Nginx 、Traefik 、Caddy 、Pingora 等多种方案后，我们最终选择了 Nginx + OpenResty + Lua 堆栈——这是一条成熟、风险低且具备快速迭代能力的路径。
我们将其命名为 Aegis，代表我们的边缘代理内核。
二、可扩展的功能插件：构建灵活的能力框架（ 2025 Q2 ）
CDN 是一个庞大的系统概念，它涵盖了 安全、性能、访问控制、可用性、连通性 等多个层面。
如何在基础代理之上，逐步扩展出这些能力，是我们设计产品时最重要的思考。
AxisNow 的聚焦目标非常明确：我们服务于 网站、应用程序与 API（不包括直播流）。
围绕这些目标，我们构建出 可按需组合的功能插件体系。
在设计架构时，我们探索了两条技术路线：
-
以站点 / 域名为配置中心
- 这是传统 CDN 的典型模式（如 Cloudflare 、Akamai ）。
每个产品线独立开发，虽然单点能力强，但一旦用户需要跨域协同，就会带来部署复杂和数据割裂的问题。 - 即使是 Cloudflare ，也在不断尝试打破这种“单产品孤岛”式架构。
- 这是传统 CDN 的典型模式（如 Cloudflare 、Akamai ）。
-
以策略 / 插件为中心的流量控制
- 我们的思路是，将流量控制抽象为统一的策略层，不论流量来自哪个站点或应用，都可由统一的代理内核处理。
- 这种设计让管理效率与自动化程度大大提高，但也带来新的挑战：如何让少量域名的用户直观地理解这些策略关系。
我们正持续优化这部分的可视化与交互体验。
三、基于 DNS 的全局流量管理：让自建网络具备互联网级调度（ 2025 Q3 ）
当边缘代理部署在多个区域后，一个核心问题便出现了：如何智能地调度全局流量？
对于多数企业来说，自建 BGP 网络成本高昂，因此 DNS 是实现策略路由的关键途径。
在过去，我们不得不自己搭建权威 DNS 服务。而如今，云基础设施的成熟让我们能以更高层次的方式实现这项能力。
AxisNow 采用 “与第三方 DNS 集成编排” 的方案，通过插件化集成，实现：
- 基于地理位置的就近访问
- 基于策略的动态地址选取
- 与监控联动的自动切换
这一设计充分继承了我们在 安全 CDN 与大型分发系统（如 TikTok 级架构） 的实践经验，
让企业即使在自托管场景下，也能构建稳定高效的全球流量管理系统。
四、性能与可用性监控：让系统具备自我洞察力（ 2025 Q3 ）
任何 CDN 系统都离不开监控体系。
AxisNow 的监控体系聚焦在两个层面：
- 可用性监测：对边缘节点、IP 、域名进行拨测，提供实时的服务可达性评估。
- 时延与质量洞察：收集连接时延与请求质量，辅助 DNS 做出更优的流量调度决策。
我们延续 “松耦合设计” 理念，
用户既可自托管拨测节点，也可使用 AxisNow 提供的托管监控服务。
五、可观察性与平台基础：自建体系的运维中枢（ 2025 Q1 ）
自建 CDN 意味着完全掌控，因此必须拥有强大的 可观察性（ Observability ）。
AxisNow 提供了一整套监控与分析工具，帮助技术团队理解系统运行状态、追踪问题、分析流量指标与趋势：
- 实体监控：包括边缘节点、资源、插件等对象的实时状态
- 全局流量分析：从资源或边缘维度查看流量分布
- 事件与操作日志：包括租户操作记录与系统事件记录
- 原始日志采集与外部数据仓库同步：支持将日志导出至客户自有的数据平台进行深度分析
在平台层面，我们还构建了 多租户 + API First 的 SaaS 框架，
支持数据隔离、灵活扩展和自定义自动化，构成了整个 AxisNow 管理面的基础。
AxisNow 的 API 优先设计可以轻松与您的技术栈集成，使您能够以编程方式进行部署和维护。
下一步计划
在完成基础五大支柱建设后，我们的下一阶段目标是：
- Origin Shield （起源之盾）：减少源站压力，优化缓存命中
- Smart Routing （智能路由）：结合实时监控与 AI 策略，实现全局最优路径选择
- 源站隧道：无缝连接到您的家庭网络、云内网，实现零信任网络与内网应用公开
这些能力将进一步强化 AxisNow 的 私有边缘平台（ Private Edge Platform ），
帮助企业以 最小代价、最高控制力 构建安全高效的应用交付网络。
结语
自建 CDN 不再只是大型互联网公司的专属能力。
随着基础设施生态的成熟，中小型企业乃至个人技术爱好者 都可以通过 AxisNow 平台逐步搭建、掌控并优化自己的边缘网络。
AxisNow 将这些大型互联网公司才有的技术平民化，
为 应用安全与交付 提供了另一种全新的选择。
VMRack CDN
自建数据中心 + 智能缓存 + 边缘节点网络，提供 高可靠、高性能、高安全性 的内容分发服务。
按实际使用流量计费，无隐藏费用，月初赠送免费 30G 流量带宽,超出流量仅$0.05/G 。
支持 WAF 、CC 、DDoS 等内置安全防护，缓存策略、刷新、预热等自助配置。
VMRack 定制 CDN （深度可控）
私有化部署 + 节点管控 + 自定义功能支持。
全面支持访问控制（ IP / URL / HTTP 头等）、自定义监听端口、灵活回源策略、缓存策略定制等。
面向业务场景可定制（如大文件下载、音视频、热点缓存、专属安全策略等）。
定制 CDN 技术优势:
节点管控:集中配置管理 CDN 节点，快速响应业务变化，提升管控效率
实时统计:实时监测网站带宽、流量、命中率、回源质量等关键指标
负载均衡:支持配置多个源服务器，支持轮询、权重、最少连接等调度方式，实现稳定高效的负载均衡
安全防护:内置 WAF 、CC 、DDoS 防护，支持多种访问控制策略，防止恶意请求和非法下载
访问控制:支持按 IP 、URL 、HTTP 头等维度配置访问策略，灵活应对多种复杂应用场景
自定义端口:支持非 80 、443 端口的监听和转发，同时支持配置自定义回源端口
刷新与预热:可针对 URL 、文件类型实时刷新缓存内容，并预热核心资源，保障用户访问体验
缓存配置:支持按文件类型、路径、目录设置缓存策略，可配置全局策略或按站点独立设置
我们的技术团队 7×24 小时在线响应，365 天不间断护航，确保您在关键时刻获得即时技术支援与解决方案
有意向的可加个人 tg 号了解定制详情和价格方案
tg 号:https://t.me/hajiminanbeilvdou8888
官网： https://www.vmrack.net?affid=v2ex
tg 群： https://t.me/vmrack_chat ]]>
但是同样的添加域名，配置 dns ，上传证书，部署 cdn 站点，等待 edgeone 下发配置，最终生效状态变成 已启用
为什么配置都一样，国内版 edgeone 正常访问，国际版就会出现 ERR_CERT_COMMON_NAME_INVALID 问题呢，我是给自己的图床部署 cdn 。现在访问会出现 ERR_CERT_COMMON_NAME_INVALID 错误，然后 curl 会返回 no alternative certificate subject name matches target hostname 'image.xxx.com' 的一个提示，经过我的排查，发现访问 image.xxx.com 会默认经过腾讯云的证书，Issues To Common Name(CN): *.cdn.myqcloud.com ，但是在站点配置里不是已经配置了使用我自己上传的证书了么？我的证书是匹配 *.xxx.com 域名的
这个问题应该怎么解呀，还请佬们指教
]]>2025-08-27 ，Top 20 访问 IP: 1. 218.91.12.118 - 2778316 次 (76.48%) 江苏省扬州市 电信 2. 49.86.219.111 - 394376 次 (10.86%) 江苏省扬州市 电信 3. 218.91.12.112 - 281750 次 (7.76%) 江苏省扬州市 电信 4. 221.229.25.79 - 138534 次 (3.81%) 江苏省扬州市 电信 5. 180.119.65.246 - 30097 次 (0.83%) 江苏省扬州市 电信 6. 117.91.108.6 - 3000 次 (0.08%) 江苏省扬州市 电信 7. 180.119.112.6 - 1851 次 (0.05%) 江苏省扬州市 电信 服务器是阿里云的，可以通过 ECS 防火墙把恶意 IP 完全给屏蔽掉，奈何这个 IP 一直在变化。
公司的业务覆盖扬州，不能武断地直接封禁整个扬州电信的 IP 。
尝试写脚本工具，每 5 分钟检查一下访问日志，把恶意 IP 放入 nginx 黑名单中，直接返回 444 状态码，无奈这个方案还是会消耗服务器性能。
逛了逛 V2EX 的帖子，有下面的文章推荐欺人太甚，山西联通 IP 还在继续盗刷 CDN
找到工信部 电信用户申诉 网页去投诉，2 天内就有客服联系我了，然而客服并没有设法查下去，给我推脱了，我回复客服：“扬州电信是有这个能力查下去的”，客服还是消极的态度。
后面有个自称扬州电信的人使用个人手机找我，让我提供证明刷流量证据，我把相关日志发送给他后，当天就没有扬州电信的 IP 刷流量了。
我怀疑扬州电信内部人员或者其利益团伙在做 PCDN 的业务，但无证据。
如果有朋友饱受扬州电信 IP 刷流量问题，可以私聊我： MTM4NTI3OTI5NDU= 或者 cml0YXN3Y0AxNjMuY29t
我帮你联系那个电信内部人员
]]>此处展示 itdog 测速:
有一种开了 eo 优选的美, 确实深绿, 确实解析出来了很多位置, 基本都是香港阿里云的
CDN 支持 http2 http3 , 还有 ws, 好评!
WAF 我没怎么用过, 但是最近看到过相关帖子, 就点进去看了一眼, 感觉也不错
也没看到什么 AFF, 我就不化身 AFF man 了, 未来可能开放一些服务 使用这个 CDN, 不限流量真的很诱人
]]>039m.com
怀疑这个站就是刷流量的人自己建的索引站，被收录就倒大霉了
]]>
我发现很多人会用：
https://cdn.staticfile.org
https://cdn.bootcdn.net
这俩经过我的测试，已经被 uBlock 拦截掉了
我也看了前段时间的投毒事件，大概理解为什么
但是我不理解，为什么这种简单的 CSS 文件需要用第三方 CDN 呢？
全部用自己的服务器存储并加载，难道很消耗流量吗？这又不是图片资源
我技艺不精，可能有些地方不清楚，所以希望大佬赐教，诚心发问：
为什么你们 CSS 文件要用第三方 CDN ？ ]]>
最近开始使用腾讯云 CDN ，看到 v 站许多被刷 CDN 流量造成损失的帖，瑟瑟发抖，于是上了校验功能，这样 CDN 文件的 url 会带上 sign ，然而如果每次访问的 sign 不同，对浏览器来说就是新的 url ，应该就浏览器上的强制缓存和协商缓存机制都用不上了是么？
使用 sign 就应该放弃浏览器缓存么？还是说 sign 也应该后台缓存下来一段时间内重复使用，不用每次访问都算个新 sign ？
v 友们都怎么使用 CDN+sign 的呢？谢谢！
]]>伪代码表示我想实现的意图：
Browser: Access CDN domain (cdn.com) CDN: if user IP is US: Serve from us.com origin else if user IP is Europe: Serve from eu.com origin else if user IP is China: Serve from cn.com origin else: Default action (not specified) staticfile.net 、bootcdn.net 、bootcss.com 、polyfill.io 按照网上的说法，这几个 CDN 都是同一个组织在管理，并且 bootcss 和 polyfill 都有投毒的先例。
我也是之前当时因为 bootcdn 投毒事件后转到 staticfile.net 的，没想到这次还是中招了。
现在我们公司也屏蔽了这些域名，现在国内访问友好的公共 CDN 服务，是不是没有了？有其他选择么？
]]>为什么说全方位呢？相比于常见的其他攻击，这次攻击已经持续将近 30 天了，并且针对我的多个域名（甚至有的域名境内外设置了不同 cdn ，它都分别攻击了，但攻击 ip 都是境外）
查询日志可以发现，恶意攻击的来源 ip 为 cloudflare 的 IP ，依照我的经验，这应该是用了 cloudflare 的 warp 服务做掩护（本质上是个 vpn ，见 https://blog.cloudflare.com/1111-warp-better-vpn ）
尝试联系了 cloudflare ，但他们非说我看到的 ip 是伪造的 
我也尝试抓包攻击的请求，得到的 x-forwarded-for 中的 ip 均为未分配/不存在的假 ip
[13/Jun/2024:02:48:00 +0800] 15.53.177.227 - 1 "https://这里是真实的 refer ，伪造的和正常请求一致" "GET https://b 攻击的地址 ff4ca27c58f56a6-1.png" 499 523 0 -,SEC|NOCHARGE "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13G36" "-"
这个请求中 15.53.177.227 甚至没有分配
按理说攻击前攻击者一般会亲自访问网站来确定接下来要攻击的内容，我也翻了攻击开始前一段时间的日志，发现：
185.99.132.104 - - [08/Jun/2024:03:33:23 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 146.185.214.41 - - [08/Jun/2024:03:33:23 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 38.54.126.18 - - [08/Jun/2024:03:33:23 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 43.131.29.194 - - [08/Jun/2024:03:33:23 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 38.54.59.59 - - [08/Jun/2024:03:33:23 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 38.54.63.220 - - [08/Jun/2024:03:33:24 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 38.54.45.156 - - [08/Jun/2024:03:33:24 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 43.130.200.82 - - [08/Jun/2024:03:33:24 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 43.130.151.11 - - [08/Jun/2024:03:33:24 +0000] "GET /login HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
以上的“googlebot”，ip 来自腾讯云，靠谱云香港（ Kaopu Cloud HK ）等，显然谷歌自己是不会用这些服务商的吧，因此这些就是攻击者扫描网站的服务器 ip 了
题外话：有人可能会疑问为什么不把这些 ip 也隐藏起来呢？其实你只要处理过攻击就明白：我们习惯在被攻击时直接 ban 掉攻击来源的 ip 段，所以攻击者需要用不同的 ip 来确定是被你 ban 了还是你的网站崩溃了
说实话，处理到这里时我有点担心了，开始我以为只是哪个小鬼的攻击，现在的表现看来是被自动化的僵尸网络盯上了（也有放心的一点，攻击基本上确定是国人发起的，这样后续的法律程序也方便一些）
在日志中，也发现了疑似攻击者亲自访问的记录
110.154.96.129 - - [06/Jun/2024:04:08:24 +0000] "GET / HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0"
110.154.96.129 - - [06/Jun/2024:04:08:25 +0000] "GET /login HTTP/1.1" 200 7863 "https://我的网站" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0"
110.154.96.129 - - [06/Jun/2024:04:08:26 +0000] "GET /apps/theming/css/default.css?v=47354877-20 HTTP/1.1" 304 0 "-" "Go-http-client/1.1"
110.154.96.129 - - [06/Jun/2024:04:08:26 +0000] "GET /dist/core-files_fileinfo.js?v=8294bb86-20 HTTP/1.1" 206 928 "-" "Go-http-client/1.1"
110.154.96.129 - - [06/Jun/2024:04:08:26 +0000] "GET /dist/core-files_client.js?v=8294bb86-20 HTTP/1.1" 304 0 "-" "Go-http-client/1.1"
110.154.96.129 - - [06/Jun/2024:04:08:26 +0000] "GET /apps/theming/theme/light-highcontrast.css?plain=1&v=91032ad7 HTTP/1.1" 200 3379 "-" "Go-http-client/1.1"
110.154.96.129 - - [06/Jun/2024:04:08:27 +0000] "GET /apps/theming/theme/dark-highcontrast.css?plain=1&v=91032ad7 HTTP/1.1" 200 3422 "-" "Go-http-client/1.1"
110.154.96.129 - - [06/Jun/2024:04:08:27 +0000] "GET /apps/files_rightclick/css/app.css?v=1bf6e69c-20 HTTP/1.1" 304 0 "-" "Go-http-client/1.1"
....
相比上面“googlebot”明显自动化的访问，这几个的访问更接近用浏览器正常打开网站后的请求，但还是自动的（ go-httpclient ）
根据查询，这个 ip 来自乌鲁木齐电信，同样标识为 Go-http-client 的还有 39.150.128.109 河南移动，访问行为是一致的。
困难来了：
我尝试了联系靠谱云处理，截止目前它们没有回复。
尝试联系 cloudflare ，他们并不认可攻击与他们有任何关联
联系移动，电信，显然也是没有回复。
想问在坐的各位有在以上相关单位工作/有认识的人吗？如果可以希望帮忙联系一下，谢谢！
(就在写这个的同时，攻击也没有停止，即使 ban 了 ip 返回 403 也在坚持攻击) 
大家有没有遇到这种情况，利益相关方是谁呢，这些人做这个的动机实在想不通。
ps: 全部都是国内的 IP ，按照当前的管控，帽子叔叔要查这些应该很简单，但是为什么这些人可以有恃无恐呢？
]]>
但是这个方案有个问题，就是需要两个源站同步，请问各位大佬有没有好的解决方案 [传图程序用的是 PicGo ] ]]>除了变通法，如 LocalCDN 的浏览器插件、走科学外，还要是不是的堤防可能被 GFW 或各地 ISP 墙的问题。
请问除了 LocalCDN 的浏览器插件外，还有更好的方案或方法来把 JS 、CSS 缓存或保存至本地计算机的硬盘中嘛？ ]]>
比如
https://cdn.staticfile.org/font-awesome/6.5.1/webfonts/fa-solid-900.ttf返回头是：
Access-Control-Allow-Origin : https://yywen.top 然而有一部分 CDN 源还是正常的，不知道七牛这是啥意思？
]]>================================= 分割线 =================================
有想法的可以私我 V：bW1tY2F0b28= ]]>
]]>]]>腾讯云遨驰终端 OrcaTerm （原名 WebShell ）是腾讯遨驰云原生操作系统中 CVM 、Lighthouse 、裸金属等产品的统一网页终端，帮助用户随时随地通过浏览器远程登录服务器管理业务，相比本地远程终端更轻量便捷，无需掌握 SSH 和 FTP 也可轻松操作。访问地址 https://orcaterm.cloud.tencent.com/terminal
从表面的链路来看，直接在 cf 里设置 b 域名解释到源站不就可以了，为什么要使用 custom hostnames 这个功能？我看官网介绍以及搜相关资料（网上几乎都是操作说明没有解释原理）也找不到一个所以然，有无大佬可以讲解一下？ ]]>
求助： CDN 该如何设置，解析该如何设置？ 小白被绕的有点懵
]]>有人问如何看待 ipv4 退网 /t/941781
想到目前除了手机流量，在绝大多数场合，IPV6 依旧是不可用的状态
于是只能配置一台国内中转机用于 IPv4 访问，或者配置一台国外中转机享受过墙干扰波动
如果有可以支持 IPv6 回源的 CDN 就可以不再依赖 IPv4 了
各大云厂商 IPv6 回源支持情况（ 2023 年 5 月 22 日，仅普通用户身份体验）：
-
腾讯云：支持 IPv6 回源，但是按访问次数收费，且不支持流量包
-
阿里云：可以通过先添加 IPv4 源站再删除的方法使用纯 IPv6 回源，但是部分节点不支持 IPv6 回源，需要手动挑选
-
华为云：不支持
-
京东云：不支持
-
华为云：不支持
-
又拍云：不支持
-
七牛云：不支持
-
百度云加速：不支持
由 NLB 443 端口通过 TCP 协议 回到真正的源机上的 443 端口
源机上的 443 端口是有另外的 SSL 证书进行加密的
也就是说我整个构架如下
CDN-证书 1-AWSNLB-证书 2-源机
那么我想问的问题是在这种构架下 CDN 供应商 有没有可能在动态数据通讯的过程种窃取敏感信息
比如 www.xxx.com/login?user=111&password=222
在这种构架下有没有可能 111 和 222 被 CDN 供应商利用或者窃取
静态资源倒是无所谓
]]>cdn 限制：带宽限制为 5M ，不支持 websocket ，cdn 不允许商业用途
申请条件：拥有个人博客或开源程序网站，总之就是有非盈利的网站需要接入大陆优化 cdn
测试节点 1(193.221.95.55)：200G 防御，去程回程都走 cera 的上海联通 4837 申请方式之一 ：可以发帖评论你的博客和域名邮箱
其他申请方式可以看我博客： https://blog.tanglu.me/blogcdn/
]]>博客流量很小 月流量不会超过 100GB ，大约在 10GB 。
CDN 需要支持访问速率限制这类的基本防 CC 规则即可，有带宽和费用限制更好
目前看了 gcp tencent huawei 都不支持 CC 规则，阿里那个 CC 规则还收费太贵了
]]>ps:近日在 loc 看到的一个 1.2M 的 go 项目可以绕过,大佬没开源,求相关思路
]]>185.163.3.4 92.223.120.10 92.223.126.29 5.188.121.162
]]>之后提交 sitemap 时， https://blog.lxythan2lxy.cn/sitemap.xml 也显示 404 ，但是我在本机和美国的服务器上试了，应该是可以正常访问到的。
有朋友遇到过相似情况吗？🤝 ]]>