广电宽带...... 有点看脸啊......
您能做的就是先看看 Ping 网关的丢包率，如果网关不丢的话就找那个云服务能给您中转一下。
不过一般都是 Ping 网关都不稳定，光纤入户那就没救了。换运营商吧亲。

多 BB 一句，如果是同轴的话还能是怀疑是同轴干扰衰减问题，可以试试从楼道分线箱拉一条专线到您家猫上，甚至直接用高档成品电视线，完了把猫放在分线箱里看看行不行了。

xswl

请提出“点击中英文切换按钮后，系统不会自动切换至对应语言”的 issue 给对面，要求其回应......

@blueboyggh 那个是监控线的，频率不一样。我估计也没有标准可言。

@tenwx 这的确是缺点，尤其是高频的时候。不过设备可以斜率补偿，而且短距离传输也不会下门限的。

@Archeb 太激进了吧...... 先不说装修师傅拉线多虎。还要考虑熔接还是冷接，接头或者熔接点的寿命问题。运营商师傅接光纤还几年返修一次呢。

----------------------

技术是个好技术，不过可能是中国同轴电缆这块不太受重视，国内并没有相应的产品（ JD 无，TB 只有代购）。

但是在 Amazon.com ，可以找到不少有关产品（ https://www.amazon.com/s?k=MOCA ），例如楼主发的这款产品（ https://www.amazon.com/Actiontec-Bonded-Ethernet-Adapter-ECB6200K02/dp/B013J7O3X0 ）

根据技术参数（商品页可下载），MOCA 2.0 采用的频段是 Extended D 频段，1125MHz ~ 1675MHz。
入端口支持频率：5MHz ~ 2150MHz，TV/STB 放通频率：5MHz ~ 1002MHz
这个频率不和有线电视冲突，但和卫星电视冲突，家里用卫星看电视的可能就无法使用了。

----------------------

### 看到商品评价，当地用户用起来效果还是不错的。

Amazon 评论有人提到：

我现在已经运行了大约一个星期了。

它们使用起来非常简单。

您将同轴从墙壁连接到 MoCA 适配器。MoCA 适配器上有一个可用于连接到电视 /有线电视盒等的接口，然后插上电源并按下 ON 按钮，你就可以开始了。

安装位置的互联网速度为 250Mbps。我通过这些适配器得到了。由于没有运行任何更高带宽的基准测试，我无法提高性能。

为了给安装提供最好的工作机会，我提前做了一些事情。

1.在有线电视公司的同轴电缆入口处安装 POE 滤波器，以消除任何外界干扰，防止 MoCA 信号离开家中。我使用了 Antronix GLF-1002 MoCA POE 过滤器。（亚马逊 B01EXRMIIC ）

2。我用 GHS-xPRO-M 系列（蓝色标签）中的 Holland Electronics 5-1675mHz MoCA 分离器替换了 MoCA 适配器路径中的所有同轴分离器。从我在网上找到的，它们是市场上最好的。（ Ex Amazon B00OTOEIGK ）

3。我使用端接器上的 Cimple Co F 75 欧姆螺钉端接任何未使用的同轴连接（在墙壁或分离器上）。（亚马逊 B01K6M2UW2 ）

我检查确保家中没有有源信号增强器 /放大器。如果有的话，我会用 MoCA 类似的 Booster / Amplifier 取而代之。

5.我检查确保没有任何已知的 MoCA 问题原因连接到 Coax。某些 TiVo，有线电视盒和其他已知会导致 MoCA 问题的设备。如果有，我会使用过滤器来隔离它们。

几个同轴电缆运行相当长，大约 150 英尺或更长。总共，在使用的任何 2 个 MoCA 适配器之间最多有 3 个分离器。安装总共有 4 个。

到目前为止，我对他们的表现以及他们上网的难易程度感到非常满意。


### 至于延迟肯定是会高一点，没办法。

Amazon 评论有人提到：

我使用这个产品将我的 DSL Modem 和 Nighthawk 路由器重新定位到我家里的另一个位置，我只有 1 个以太网端口和 1 个 RG6 插孔。安装完全即插即用 - 完全没有配置。放置在适配器中的时间比它们启动和连接所需的时间长。

我通过现有的以太网连接将 DEMARK 的 DSL 信号传递给 DSL 调制解调器（以桥接模式运行）。
然后，从 DSL 调制解调器（在桥接模式下运行）和我的 Nighthawk 的 WAN 端口。
一个 Nighthawks LAN 端口和一个 8 端口交换机。
从交换机的其中一个端口进入 ZyXEL MoCA 2.0 以太网到同轴适配器的以太网端口。
ZyXEL 适配器的同轴端口中的同轴电缆穿过现有的专用同轴电缆运行到结构化接线板。

从结构化接线板中的专用 COAX RUN 到 ZyXEL 适配器的同轴端口。
从 ZyXEL 适配器的以太网端口进入另一个 8 端口交换机的端口。这通过房子的其余部分反馈网络。

工作完美!!! ping 我的 NAS 机箱和服务器<3ms。最重要的是，将大文件（> 2GB ）复制到我的服务器或 NAS 盒中或从中复制大量文件并没有显示任何时间的增加。

### 关于测速的相关问题

Amazon 评论有人提到：

这个产品有效。我没有连接问题。但是，我确信它并没有像它所说的那样“保速率”。我用 iperf3 测试过。我可以获得的最佳吞吐量是 310Mbps，而不是广告宣传的 1Gbps。我尝试了多种设置。我甚至用同轴电缆直接连接两个 MOCA，并且只改进到大约 330Mbps。当我使用以太网线连接计算机两台计算机时，我确实获得了 990+ Mbps。所以这不是我的电脑的问题。
---------------------------------------
我后来发现了有关测试 Moca 的信息。由于延迟要大得多，因此需要更大的缓冲区来获得所需的速度。当我改变缓冲区大小时，我确实获得了 950 + Mbps 的速度。我们需要添加的交换机是“-w 1M ”。

刚才有个小错误：
比如北京市所有的医院对接北京市医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。

另外如果再不行，我觉得需要考虑微软 office 组的某些牛人了。牛到系统里做个大改动，一次改上千个文件完了系统还能 PASS 测试那种。

上百家医院，完了还是您这种情况......

这种问题十家八家的，模块化+模块控制可以解决。
Base 框架所有医院共享一个，完了开发标准的 1-4 模块，互不冲突的功能都在标准模块实现，差别从配置文件解决。
完了分支出来 3-C，1-D，3-D，4-D 解决模块间冲突。

如果这个架构扩展成几十家医院，可以考虑按划分二级分支，差别从配置文件解决。
比如北京市同一个医院对接医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。
比如北京统一挂号平台（网上预约号）在北京所有医院适用。
比如北京京医通系统（挂号、缴费、检验单查询）在北京有接近二十家医院了。

问题是如果是共性不多的上百家医院，如果又不能引导需求的话。
我怕最后会出来几十个模块分支，继续 nightmare......

北京电信这边的话，很难找到能直接跟您讨论小区无法覆盖原因、覆盖进度和开通时间的人，跟客服热线聊套话解决不了任何问题。您这个真的算很幸运的了。
我之前处理联通和移动光改的时候，都是沟通两次就能拿到具体负责人的电话，随后的原因、进度都可以直接跟具体负责的人谈。
以我的处理经验，传话筒是必须的一部分，因为运营商不了解物业，物业不了解运营商，需要一个人来打破这之间的隔阂和不理解。我们小区我做了半个月传声筒，某运营商才发现我家的物业公司和他们沟通的物业公司分别管理不同的小区。

电信的话，我举个栗子，我们小区去年做电信覆盖了，每户都预留了光纤，但是没开通。今年有一户新装修，完了装修师傅就直接把电信光纤拉进了家，没有考虑其他运营商，小区原有的网线暗管已被装修队拆除。
完了找联通装光纤，肯定是装不上。完了我这边了解到情况，打 10000，只说没覆盖，没开通，不给记录工单。去附近电信营业厅问，完了人家说“我们没开通，我们没有负责人电话，开通了会贴公告”，十分无语。

您问我这事如何解决的？最后业主从他们户型还存在的唯一能穿的楼宇电话暗管穿进去，完了墙上刮开一层槽装了联通光纤......

HG220G-U 版本小于 2.03 的（ 1.0 除外）会有桥接掉速 Bug，问题是现在新猫恨不得都 5 了。
TEWA 猫不太了解。

不过考虑到您是 1000M 用户，建议直接让电话局给您找华为 10G 猫吧。

西直门地区，没了。
10010 投诉，反馈结果：我们的 IPv6 仅供企业使用*3。

提 issue 和 PR 一般都是在英文和开发者语言中二选一，大项目偏向英文，小项目偏向开发者语言（要是不会就 fallback 英文）。在非中文项目中用中文提 issue/PR 虽不推崇但也可以理解（ Google 翻译一下辣么难？），问题是水，还是中文水......
没办法，素质低的人就是这样的。建议 GitHub 转正删除 issue 功能和添加发垃圾 issue/comment 后 ban id 的制度。

@aab6090 增加按语种分类只是一个用户体验优化的建议，您也不希望您在阅读排行榜时被一堆自己完全看不懂的语种所占领。

我重新看了一下需求，您希望 ServerA 100%缓存流经的内容的话，就用 proxy_cache 吧，完了 OSS 侧给个巨大的缓存头解决问题。

但是是缓存，不是文件的真实地址？？ 这句没看懂。

1.图省事的做法就是 OSS 配好缓存时间，完了 nginx 的 proxy_cache 或者 squid 解决。
好处就是缓存什么文件 nginx 代劳了，不用考虑什么是热点内容。
缺点就是所有流量经过 A，浪费双份流量，并且 A 断了会引起业务中断。当然如果有逐步下掉 OSS 的计划，这样做最好不过。

2. 要么就是 nginx 的 try_files+302 解决。
好处就是客户端配置一个域名可以搞定，并且不会浪费流量。
缺点就是 A 断了会引起业务中断，并且需要定期分析日志决定什么内容放在 A 上，否则可能不优化。

3. 如果能接受客户端发版，可以考虑改造 HTTP 请求相关代码，第一次请求走 ServerA，如果返回代码!=200 或者请求失败，第二次请求走 OSS。
优点是这样比较强健，ServerA 断了不影响业务，并且不会浪费流量。
缺点就是要改造客户端代码，另外也需要定期分析日志决定什么内容放在 A 上，否则可能不优化。

他这个 RX 和 TX 还真是和一般认知相反，难道是按照虚拟交换机的 TX/RX 算的？

一般来说：
HTTP 请求（一般较小）占用客户机上行，占用服务器下行（入流量，免费）。
HTTP 响应（一般较大）占用客户机下行，占用服务器上行（出流量，计费）。

因 systemd 在系统启动时需要熵信息，且内核在可用熵较少时会阻塞相应的调用，所以系统启动时可能挂起数分钟至数小时，直至随机子系统充分得到初始化（ random: crng init done ）。对于支持 RDRAND 指令的 amd64 系统，Debian 的内核已可以避免这个问题，因为内核默认将尝试使用该指令（ CONFIG_RANDOM_TRUST_CPU ）。

非 amd64 架构的系统和某些虚拟机可能需要从其它来源获取熵以保证快速启动。Debian 安装程序内部选择了 haveged 作为替代方案，在硬件熵不可用时，这可能是个可以使用的解决方案。在虚拟机上，请考虑经由 virtio_rng 将主机的熵转发至虚拟机中。

如果您在阅读本篇文档之前已将远程的系统升级至 buster，请考虑经由网络持续 ping 远程系统，这样做可以向系统的随机池中添加熵，并最终使得系统可以重新通过 ssh 登录。

请参见维基( https://wiki.debian.org/BoottimeEntropyStarvation)以及 DLange 对此问题的简述( https://daniel-lange.com/archives/152-hello-buster.html)以了解其它解决方法。

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.zh-cn.html#entropy-starvation

首先还是要看应用支持不支持。以 php+mysql 应用举例，部分应用使用 ip2long 或者 char(15)存 IP，改造 IPv6 之后会导致 IP 被截断，导致应用对 IP 的记录和处理出现异常。另外如果需要基于 IP 或者 IP 归属地做判断（风控、IP 归属地不同流程不同、支持基于 IP 地址 /IP 段的封禁等）的应用更要注意。
个人建议稍微求新一点的应用、个人站等可以开始尝试部署，而且双栈条件下 v6 不通还有 v4 保底，不过比较严谨的还要再考虑一下，一方面是应用本身的问题，另外一方面是毕竟 mtu 黑洞等问题在线网仍然存在，会出现无法保底的访问失败。
从国内和国外对比的话，国内部分云服务商将 IPv4 和 IPv6 的地址和带宽、流量分别看待，分别计费，尤其是应用的网络资源是基于带宽付费的服务更明显（网络部分费用可能 double ），而且国内 IPv6 处于测试阶段，不是所有云服务商的所有型号的云主机都支持 IPv6，如果需要 IPv6，可能还需要迁移云主机到支持的型号。不过国内 IPv6 互联带宽还是有一定保证的，起码不会影响业务。
境外的话，很多 VPS 供应商和云服务商已经支持 IPv6，而且国外云服务商一般将 IPv4 和 IPv6 共同看待，一般都是共享带宽 /流量，部分服务商还可以免费赠送 IPv6 地址，价格也因为先发优势，相对国内要有优势一些。不过要考虑到目前整体来说 IPv6 的国际互联带宽较小（见 https://www.v2ex.com/t/582589 ），对于网站访问一般会有负面影响，这一点建议做好完整的测试后再推行。

北京联通（ 500Mbps ） 66.4MB/s
北京移动（ 50Mbps ） 1,309 KB/s

网络肯定是要扩容的，除了土豪 CMCC 为 LTE 和宽带氪了一张巨强的骨干网，当然移动的问题在于宽带出国太垃圾。
如果骨干网升级的话，在网络扁平化的驱动下必然可以实现带宽提升，延迟降低。但是 2L 提到了本地出口的问题，在特定情况下可能还真有负面作用。
比如某三线小城访问一线城市网站乃至出国，目前的架构是走类似 CN2 的带宽有保障的线路到省会后，再进入类似 163 的 Internet 网。5G 扁平化后肯定要在当地直接进城域网完了上行这样。当然这种只是个例，运营商也会做扩容保证带宽不会太拥堵的。


北京移动移网、固网的 IPv6 也莫名消失了，供参考。

1. 安全性上几乎不存在问题，而且现在有证书透明度制度让 CA 不敢瞎搞，这种东西本来就是个互信制度，破坏安全体系就等死吧，乱搞一个 update 直接干掉这个 CA 的根。而且现在还有前向加密，即使拿到私钥也无法解开使用支持 FS 加密的算法加密的数据。
2. 差距就是一些体验性的东西。有些企业喜欢标题栏显示自己单位名称的 EV 证书，这个就必须收费而且不便宜。或者基础设施庞大，更新一次证书费死劲，会希望要一年以上的证书，免费的最多一年，最火的了 let's encrypt 只有三个月，要么全局设计一套更新体系，要么就买两年甚至三年的证书吧。或者单位大气，习惯了 oracle、ms 级别的跪式服务，买一个 CA 企业的支持服务也不是不行。
3. 看您做什么，如果就是一般的企业网站，那免费的完全够，let's encrypt 设置上自动更新脚本即可。如果您在一个大企业，考虑到各种因素（ EV、期限、服务）您愿意买一个证书也不是不行。当然如果是土豪单位，建议来个 EV 证书，打开网页绿色小锁后面跟着单位名称，多舒服啊（炒我国股票类的公司就算了，有些浏览器有些版本单位名称是绿色字显示的）。