服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

不规则的互联网中断:某些图像和JS没有加载

第一次在ServerFault上,我有一个很好的小难题。 自从几个月以来,我们一直在与我们的互联网连接问题。 环境: Servers: 2 Terminal Servers as an RDSFarm running Windows Server 2008 R2 Browser: Internet Explorer 9 Test/debug browser: Chrome AntiVirus: Avast 7.0.1455 问题: 在不规则的时间间隔,网站拒绝加载,给出一个错误说网页是不可访问的,或一些图像不加载完全。 另外,检查后,serveral .js文件无法加载。 调查结果&我们尝试了什么: 第一印象: 当我在该间隔期间使用Chrome时,网站在刷新后返回net :: Error 101或Error 103。 在其他时候,如果没有给出错误,则几个图像不可见并显示X图像。 IE只是说这个页面不能显示。 使用Chrome开发者工具: 它在控制台中显示几个资源不可用,但是当我右键单击丢失的图像并select“显示图片”时,它们显示。 当我通过直接URL打开图片时,他们也会显示。 通过Chrome开发者工具审核: 当它处于错误状态时,我在页面上运行了审计,发现一些.js文件没有与一些.png,.jpg和.gif文件一起加载。 Chrome和IE不同的图像加载。 混淆的JS文件和Avast: 检查出来后,我发现这些.js文件中的大部分都是混淆的JS文件,而且由于我们运行的是Avast 7.0.1455,所以我想知道Web Shield是不是搞砸了。 然后再次,只发生在第一个TS上,而不是第二个。 所以我closures了WebShield一天,看看有什么改进。 它没有。 回到原点。 文件没有caching过期: 其中几个没有被加载的文件被指示没有caching过期。 caching: […]

从我们的服务器电子邮件标记为垃圾由Hotmail Smartscreen无法通知Hotmail,这是合法的

自1个多月前以来,我们的电子邮件系统被Hotmail Smartscreenfilter标记为垃圾邮件。 我们采取了以下措施而没有成功: 反向DNS匹配发件人IP。 SPF,DomainKeys和DKIM激活并通过(由[email protected]和Hotmail电子邮件头本身确认)。 在mxtoolbox.com,spamhaus,梭子鱼和趋势科技中清除DNSBL。 我们每小时和每天的电子邮件发送限制(90个电子邮件/ destinataries每小时和邮箱)。 当我们的数据中心检测到特殊的垃圾邮件或病毒发送时,也会阻止它的目标端口。 我们尝试了不同的IP,甚至获得了以前的DNSBL检查和反向DNS的新的故障转移。 我们尝试了不同的电子邮件地址,甚至创build了新的和不同的域名。 我们使用的IP已经join了MS JMRP,并且我们收到了很less的用户FBL投诉(每月一个)。 通过Hotmail发件人信息表单和随后与他们的运营商的电子邮件互动联系人没有取得任何进展。 他们总是回答说:“我们今天没有看到你的IP有任何问题”。 SMTP服务器(后缀)日志显示正常的电子邮件接受(即时250响应)的Hotmail服务器。 我们是一家分享托pipe公司,通过服务器和IP地址向多个客户提供networking和电子邮件服务。 确实,我们有一些来自我们客户的垃圾邮件和病毒感染(数百个合法发件人每周最多1次),但无论如何,我们的限制和我们的数据中心限制都是存在的。 我们想知道是否有一个特定的正面报告链接,如Gmail中的这一个,直接通知Hotmail我们的电子邮件发送是合法的。 否则,我们依靠我们的客户的destinataries积极对Hotmail垃圾邮件状态(如果他们知道,并且照顾这样做)。

如何判断由于LAN唤醒(WoL)还是电源button引起的系统启动?

在Windows 10中,我想知道如何在脚本中告诉系统是否通过接收局域网唤醒(WOL)数据包打开系统,或者因为按下电源button而打开系统。 我find了Win32_ComputerSystem类的WakeUpType属性。 这被logging为返回“导致系统启动的事件”。 有9个可能的返回值,其中之一是“5”(意思是“LAN Remote”)。 不幸的是,在我的系统上似乎总是返回“6”(意思是“电源开关”): PS C:\WINDOWS\system32> echo $(Get-WmiObject -class win32_computersystem).wakeuptype 6 我注意到,在系统进入睡眠状态并使用WoL唤醒之后,Windows在系统事件日志中发布事件,其源代码为“Power-Troubleshooter”,事件ID为1,包含以下文本: 唤醒来源:设备-Intel(R)82579V千兆networking连接 而且, powercfg /lastwake报告NIC是唤醒的原因。 所以,至less当从睡梦中醒来时,即使WakeUpType属性在这种情况下仍然返回“6”(电源开关),由于WoL数据包的缘故,它能够确定它被唤醒。 不幸的是,当系统收到一个处于S5状态的WoL数据包时,它将正常启动和启动,但是我不能说因为WoL而启动它。 powercfg /lastwake显示与由于按下电源button而从S5开启系统时完全相同的输出: C:\WINDOWS\system32>powercfg /lastwake Wake History Count – 0 如何从任何电源状态(至S5)可靠地判断出因为WoL而导致系统上电/唤醒?