本文以微软公司发行的Microsoft Remote Desktop为例，介绍如何在Android设备上连接Windows系统ECS实例。

如果使用非管理员用户登录Windows实例，该用户必须属于Remote Desktop Users组。

 

阅读全文>>

无法使用Workbench和远程连接软件（例如RDP、rdesktop等）连接Windows实例时，您可以通过控制台的VNC远程连接实例，查看云服务器操作界面的实时状态。

在无法使用Workbench和远程连接软件登录实例的场景中，您可以通过VNC远程连接登录实例，了解实例情况并解决问题。

阅读全文>>

如果您对防爬效果有较高的要求，或者缺乏专业的安全团队来配置相应的安全策略，您可以使用Web应用防火墙Bot管理模块提供的爬虫防护功能。

除了Bot管理模块，您还可以参照下文介绍的爬虫请求的特征，结合Web应用防火墙的自定义防护策略、IP黑名单功能设置针对性的爬虫拦截规则。

阅读全文>>

 本文介绍了使用Web应用防火墙的规则防护引擎功能进行Web应用攻击防护的最佳实践。

包含应用场景、防护策略、防护效果、规则更新四个方面。

阅读全文>>

网站接入Web应用防火墙后，您可以为其一键开启IPv6防护功能。

IPv6防护为网站防御IPv6环境下发起的攻击，帮助源站实现对IPv6协议请求的安全防护。

阅读全文>>

当您需要加速OSS上的静态资源时，可以通过阿里云CDN加速OSS域名，实现静态资源的访问加速。

通过本文您可以详细了解CDN加速OSS的应用场景，以及通过OSS控制台实现CDN加速OSS的操作方法。

阅读全文>>

问题描述

关于CDN某个地域节点访问异常有以下几种场景。

• 场景一：使用ping命令访问CDN加速域名失败。
• 场景二：源站更改文件后，从CDN节点中获取的仍是更改之前的文件。
• 场景三：访问CDN加速域名后获取的为非其站点文件内容。

 

问题原因

关于不同问题场景的问题原因如下。

• 场景一的原因如下。
  • 本地网络异常。
  • 节点网络异常或被攻击。
  • 本地到运营商中间链路某路由节点故障。
• 场景二的原因如下。
  • 刷新未生效。
  • 读取的是本地浏览器缓存。
  • 被本地运营商劫持。
• 场景三的原因如下。
  • 访问的非CDN节点。
  • 被某种原因劫持。

 

解决方案

以下是不同问题场景的解决方案。

 

场景一：使用ping命令访问CDN加速域名失败

1. 排查加速域名是否在沙箱节点中，由于沙箱中的域名无法保证服务稳定性，所以会存在使用ping命令后，网络不通的情况，此时沙箱可能正在受到攻击。
2. 检测访问的IP是否为CDN的节点IP。关于如何检测，请参考诊断工具。如果访问的节点不是CDN节点IP，请核实如下几种情况。
   • 本地是否有开启代理软件，因为有些代理软件会强制更改访问域名的解析。
   • 是否绑定Host文件，将加速域名强制解析到了某个IP。
   • 本地存在DNS劫持，可以在本地开启杀毒安全软件，并且固定本地所使用的IP为223.5.5.5、114.114.114.114的DNS或者其他安全的DNS。如果劫持情况比较严重，并且无法解决，则需要向网络服务提供商投诉要求解决劫持。
3. 在本地使用ping命令，连接该节点IP，以及使用站长工具（例如17ce.com或者听云平台）在全国探测该节点IP是否存在问题，即各个地区访问该节点均延迟均较大或者不通，本地也ping不通该节点，则该节点存在问题的可能性较大，该前提是域名确实不在沙箱中。
4. 在本地的Windows主机使用tracert，或者在Linux主机使用traceroute，用来探测该IP并提供完整探测截图，根据得到的截图定位整个网络链路的问题点。
   

   注：MTR信息判断方法如下。

   • 目的节点丢包率为100%，并且从目的节点往前逐个检查，直到第一个开始丢包的节点（中间不能有丢包率为0%的路由节点），则第一个开始丢包的路由节点是问题路由的可能性较大。详细排查步骤，请参见ping丢包或不通时链路测试说明。

5. 请阿里云技术支持进行排查，在此期间可更改本地DNS为其他DNS（例如223.5.5.5或者114.114.114.114），并刷新本地的DNS缓存，使其调度到其他正常的节点。

 

场景二：从CDN节点中获取的仍是更改之前的文件

1. 检测访问的IP是否为CDN的节点IP。
2. 根据CDN的配置，绑定CDN节点和源站。绑定源站测试时，请注意如下几点。
   • CDN的回源Host配置中，使用curl命令测试源站的命令如下。如果绑定Host文件，那么应该将CDN加速域名绑定Host到源站域名所解析出来的IP地址。
     curl -H "Host:[$Domain_Name]" "[$Source_Station]"

     注：

     • [$Domain_Name]为CDN加速域名。
     • [$Source_Station]为源站域名。

   • 不同的回源端口得到的访问结果也可能不一样，分别测试得到Response Headers相关信息，判断访问的文件是否一致，主要判断以下几个方面。

     注：如果以下三点存在任何一项不一致的情况，那么可认为源站和节点上文件的确不一致。如果都存在的情况下，则第三点最具备判断依据。

     • Content-Length大小是否一致。
     • Last-Modified的修改时间是否一致。
     • ETag和Content-MD5是否一致。
     
3. 如果上述步骤确认后都无问题，最终在节点上获取的文件仍和源站文件不一致，建议刷新URL，等待约10分钟后再进行测试，如果多次刷新之后问题仍未解决，请提交工单。

   注：刷新生效时间约为5~10分钟。

场景三：访问CDN加速域名后获取非其站点文件内容

 

在排查CDN故障时，经常需要查看源站访问是否正常，或对比加速与未加速的访问效果。

本文介绍如何在不修改域名解析的情况下，将域名指向源站。

阅读全文>>