每次我在Cloudflare后面运行代码时都会出现520错误

时间:2019-07-10 13:59:18

标签: amazon-web-services amazon-s3 cloudflare

尝试通过我的代码加载s3文件时,我始终收到520错误。在本地一切正常,但是当我将更改上传到cloudflare背后的生产服务器时,出现520错误。我使用的是IIS 7.5和ASP经典代码,这是我每次要从s3下载文件时都会调用的测试页。

https://www.gbca.org.au/aws_test.asp?fileID=9450&hash=688254C6503507FDDF8CF5D5CD113212&type=pam

这没有意义,cloudflare也没有提供任何错误消息。

'####################################### 函数downloadFile()

Server.ScriptTimeout = 30000

set http = Server.CreateObject("Chilkat_9_5_0.Http")
http.UnlockComponent("BLUESIHttp_MHoP0vyTTL3e")
http.AwsAccessKey = AWS_ACCESS_KEY
http.AwsSecretKey = AWS_SECRET

if bucketType = "not-secure" then
    http.AwsEndpoint = "s3.ap-southeast-1.amazonaws.com"
    http.AwsRegion = "ap-southeast-1"
    bucketLocale = AWS_BUCKET_ASIA
else
    http.AwsEndpoint = "s3.ap-southeast-2.amazonaws.com"
    http.AwsRegion = "ap-southeast-2"
    bucketLocale = AWS_BUCKET_SECURE
end if

s3FileBytes = http.S3_DownloadBytes(bucketLocale, objectName)

If (http.LastMethodSuccess <> 1) Then
    Response.Write "<pre>" & Server.HTMLEncode(http.LastErrorText) & "</pre>"
    Response.End
End If

'response.write("AWS_BUCKET_ASIA: " & AWS_BUCKET_ASIA & "<br />")
'response.write("objectName: " & objectName& "<br />")
'response.write("s3FileBytes: " & ubound(s3FileBytes) & "<br />")
''response.write("s3FileBytes: " & filetype & "<br />")
''response.end()

Response.Clear
Response.AddHeader "Pragma", "no-cache"
Response.AddHeader "Content-Disposition", "attachment; filename=""" & filename & """"
Response.AddHeader "Content-Length", ubound(s3FileBytes)
Response.AddHeader "Connect", "close"
Response.ContentType = filetype
Response.BinaryWrite s3FileBytes

set AWS = nothing

'-- log the file access
'SQLLine = "INSERT INTO download_history (fileID, who, etc) VALUES (" & fileID & ")"
'DBCC.execute(SQLLine)

结束功能

https://www.gbca.org.au/aws_test.asp?fileID=9450&hash=688254C6503507FDDF8CF5D5CD113212&type=pam

1 个答案:

答案 0 :(得分:0)

Error 520本质上是一个万能的响应,当发生意外情况或原始服务器由于违反协议或响应为空而错误地解释或不接受请求时。

除了查看服务器日志外,我建议与Cloudflare支持人员联系以在其末端查看日志。除非您采用企业计划并明确要求启用100%日志,否则请记住,它们在有限的时间内仅保留1%的匿名采样日志,因此,如果您联系得太晚,则这些日志可能不可用。

我已经看到了观察到nginx错误upstream prematurely closed connection while reading response header from upstream的情况,在这种情况下,上游表示原始服务器。这表明在此期间,源服务器或其运行路径存在问题,导致Cloudflare生成了520个错误。将时间戳记与服务器的日志相关联,可以更好地了解根本原因。