这个问题感觉有点魔幻，PCDN 本来就是为了解决商业下行带宽贵的问题，采用稳定性和质量较差但价格便宜的民用上行带宽来充当 CDN ，你现在都有国内 VPS 的商业带宽了，拿来挂 PCDN 是不是有点浪费... 随便自己搞点别的分发都好呀

多吉云，每月 20GB 免费

首先，来源 IP 地址是无法篡改和“模拟”的，不是修改 HTTP 请求头就能修改的，看到来源 IP 有多少那么实际的来源就有那么多。

这种如果不是真有那么多肉鸡，那么就是利用本身就有大流量的黑灰产项目，或者劫持了正常的大流量项目、网站（运营商劫持、入侵挂马劫持等），在大流量项目里面植入了访问你的目标的脚本，每个普通的客户端都成为了攻击的一部分。

3.5

好的，以下是将这些数字从小到大排列的结果：

601 602 603 605 606 607 608 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 628 632 634 639 640 641 642 643 644 646 647 650 651 652 654 657 658 659 660 661 662 665 666 667 668 669 676 677 683

希望对您有帮助！

这个需求直接用 Dash 或者 HLS 呀，搞这么复杂干什么

这个取决于 Content-Disposition 响应头是 inline 还是 attachment
inline 就是在浏览器内直接展示，attachment 就是下载

但除非服务端主动设置，一般响应不会有 Content-Disposition 响应头的，此时浏览器会针对不同的文件类型（即 Content-Type 响应头）来决定

对于浏览器来说：
一般常见的纯文本文件类型（如 text/* 、JS 、CSS 等）浏览器会直接采用 inline 原样展示出来；
一些浏览器原生支持的文件类型（例如支持的图片 image/*、支持的音视频 audio/*、video/*、网页 text/html 、PDF 等）浏览器会直接解析展示出来；
如果不属于上面两类，浏览器会采用 attachment 触发下载。

服务端如何自动设置 Content-Type 响应头：
一般服务器都有一个 MIME 类型表，为不同的文件后缀自动设置 Content-Type 响应头
例如 .mp4 文件 对应 video/mp4 ；.js 文件对应 text/javascript

对于 MIME 类型表里面没有的文件后缀类型，服务器也会设置一个默认值，不同服务器会有不同，例如 application/octet-stream 或者 text/plain 等

OP 这个情况很明显是服务器 MIME 类型表里没有 txt 这个后缀，然后服务器自动设置 Content-Type 响应头为 application/octet-stream ，然后浏览器会默认采用 attachment 触发下载。
所以只需要在服务器 MIME 类型表里补充 txt 这个后缀为 text/plain 即可。

地址栏不变这个倒是好解决，用 postMessage 实现 iframe 内外通信同步 URL 就可以。但你这样就没法用 HTTPS 了哦。

与其这样折腾，还不如直接用你所说的 “香港 CN2 的服务器” 自己写网站逻辑，优化压缩传输体积，尽量节省流量。

好歹自己写一套 UI 和代码吧，全都抄袭真的没必要，也不是多难的东西...

（利益相关：base64.us 作者）

我是说官网没有看到双 11 活动，如果是官网没有上线而其它途径有，那是我的观察疏忽，不好意思~

@UPYUN 谢谢澄清，去年双 11 确实是没有看到，加油！

可以考虑下我们多吉云

又拍云好像没剩几个节点了，去年双 11 今年 618 也没有任何活动，微博也停更一年了。
不知道现在状况怎么样。

世界卫生组织（世卫）属下的国际癌症研究机构（ IARC ）根据证据的力度（并非风险水平），把加工肉类归类为"对人类有确认的致癌性"（第 1 类）； 红肉则"对人类很可能有致癌性"（第 2A 类）。

加工肉类指的是培根、腊肉、熏肉等；
红肉是指猪肉、牛肉这种在烹饪前呈现红色的肉。

而 IARC 将把阿斯巴甜列为“第 2B 类”，即“有可能对人类致癌”。

如果因为这个原因不喝阿斯巴甜，则应该至少也不应该再吃等级更高的猪肉、牛肉或者加工肉制品，否则真的有点双标。

估计评级不高，类似于咖啡那个致癌级别

CDN

它本来就支持搜物品的功能，扫几秒没找到二维码就会以为你在识物搜索，这也正常

隐私协议里找找看有没有说明