461 ошибка http

Page semi-protected

From Wikipedia, the free encyclopedia

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

  • 1xx informational response – the request was received, continuing process
  • 2xx successful – the request was successfully received, understood, and accepted
  • 3xx redirection – further action needs to be taken in order to complete the request
  • 4xx client error – the request contains bad syntax or cannot be fulfilled
  • 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not[note 1] send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

100 Continue
The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).[2]
101 Switching Protocols
The requester has asked the server to switch protocols and the server has agreed to do so.
102 Processing (WebDAV; RFC 2518)
A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. [3] This prevents the client from timing out and assuming the request was lost. The status code is deprecated.[4]
103 Early Hints (RFC 8297)
Used to return some response headers before final HTTP message.[5]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.[1]

200 OK
Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
201 Created
The request has been fulfilled, resulting in the creation of a new resource.[6]
202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
203 Non-Authoritative Information (since HTTP/1.1)
The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.[7][8]
204 No Content
The server successfully processed the request, and is not returning any content.
205 Reset Content
The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.
206 Partial Content
The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
207 Multi-Status (WebDAV; RFC 4918)
The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.[9]
208 Already Reported (WebDAV; RFC 5842)
The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.
226 IM Used (RFC 3229)
The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.[10]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.[11]

300 Multiple Choices
Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.
301 Moved Permanently
This and all future requests should be directed to the given URI.
302 Found (Previously «Moved temporarily»)
Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),[12] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[11]
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.
304 Not Modified
Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
305 Use Proxy (since HTTP/1.1)
The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.
306 Switch Proxy
No longer used. Originally meant «Subsequent requests should use the specified proxy.»
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.
308 Permanent Redirect
This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

A The Wikimedia 404 message

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request
The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.
Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.[citation needed]
402 Payment Required
Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,[14] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.[15] Sipgate uses this code if an account does not have sufficient funds to start a call.[16] Shopify uses this code when the store has not paid their fees and is temporarily disabled.[17] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.[18]
403 Forbidden
The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.
404 Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
405 Method Not Allowed
A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.
406 Not Acceptable
The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.
407 Proxy Authentication Required
The client must first authenticate itself with the proxy.
408 Request Timeout
The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»
409 Conflict
Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.
410 Gone
Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.
411 Length Required
The request did not specify the length of its content, which is required by the requested resource.
412 Precondition Failed
The server does not meet one of the preconditions that the requester put on the request header fields.
413 Payload Too Large
The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.[19]
414 URI Too Long
The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.[20]
415 Unsupported Media Type
The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Range Not Satisfiable
The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.[21]
417 Expectation Failed
The server cannot meet the requirements of the Expect request-header field.[22]
418 I’m a teapot (RFC 2324, RFC 7168)
This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.[23] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.[24][25][26] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.[27][28]
421 Misdirected Request
The request was directed at a server that is not able to produce a response (for example because of connection reuse).
422 Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.[9]
423 Locked (WebDAV; RFC 4918)
The resource that is being accessed is locked.[9]
424 Failed Dependency (WebDAV; RFC 4918)
The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).[9]
425 Too Early (RFC 8470)
Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required
The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.
428 Precondition Required (RFC 6585)
The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.[29]
429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.[29]
431 Request Header Fields Too Large (RFC 6585)
The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.[29]
451 Unavailable For Legal Reasons (RFC 7725)
A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.[30] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error
A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501 Not Implemented
The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable
The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.[31]
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505 HTTP Version Not Supported
The server does not support the HTTP version used in the request.
506 Variant Also Negotiates (RFC 2295)
Transparent content negotiation for the request results in a circular reference.[32]
507 Insufficient Storage (WebDAV; RFC 4918)
The server is unable to store the representation needed to complete the request.[9]
508 Loop Detected (WebDAV; RFC 5842)
The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).
510 Not Extended (RFC 2774)
Further extensions to the request are required for the server to fulfil it.[33]
511 Network Authentication Required (RFC 6585)
The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).[29]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)
Used by the Laravel Framework when a CSRF Token is missing or expired.
420 Method Failure (Spring Framework)
A deprecated response used by the Spring Framework when a method has failed.[34]
420 Enhance Your Calm (Twitter)
Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.[35] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.[citation needed]
430 Request Header Fields Too Large (Shopify)
Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.[36]
450 Blocked by Windows Parental Controls (Microsoft)
The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.[37]
498 Invalid Token (Esri)
Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.[38]
499 Token Required (Esri)
Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.[38]
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.[39]
529 Site is overloaded
Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.[40]
530 Site is frozen
Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.[41]
598 (Informal convention) Network read timeout error
Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.[42]
599 Network Connect Timeout Error
An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out
The client’s session has expired and must log in again.[43]
449 Retry With
The server cannot honour the request because the user has not provided the required information.[44]
451 Redirect
Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.[45] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.[46]

IIS sometimes uses additional decimal sub-codes for more specific information,[47] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.[48][49]

444 No Response
Used internally[50] to instruct the server to return no information to the client and close the connection immediately.
494 Request header too large
Client sent too large request or too long header line.
495 SSL Certificate Error
An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.
496 SSL Certificate Required
An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.
497 HTTP Request Sent to HTTPS Port
An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.
499 Client Closed Request
Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.[51]

520 Web Server Returned an Unknown Error
The origin server returned an empty, unknown, or unexpected response to Cloudflare.[52]
521 Web Server Is Down
The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.
522 Connection Timed Out
Cloudflare timed out contacting the origin server.
523 Origin Is Unreachable
Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.
524 A Timeout Occurred
Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.
525 SSL Handshake Failed
Cloudflare could not negotiate a SSL/TLS handshake with the origin server.
526 Invalid SSL Certificate
Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.
527 Railgun Error
Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.[53]
530
Error 530 is returned along with a 1xxx error.[54]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460
Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.[55]
463
The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.[55]
464
Incompatible protocol versions between Client and Origin server.[55]
561 Unauthorized
An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.[58]

110 Response is Stale
The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).
111 Revalidation Failed
The cache was unable to validate the response, due to an inability to reach the origin server.
112 Disconnected Operation
The cache is intentionally disconnected from the rest of the network.
113 Heuristic Expiration
The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.
199 Miscellaneous Warning
Arbitrary, non-specific warning. The warning text may be logged or presented to the user.
214 Transformation Applied
Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.
299 Miscellaneous Persistent Warning
Same as 199, but indicating a persistent warning.

See also

  • Custom error pages
  • List of FTP server return codes
  • List of HTTP header fields
  • List of SMTP server return codes
  • Common Log Format

Explanatory notes

  1. ^ Emphasised words and phrases such as must and should represent interpretation guidelines as given by RFC 2119

References

  1. ^ a b c «Hypertext Transfer Protocol (HTTP) Status Code Registry». Iana.org. Archived from the original on December 11, 2011. Retrieved January 8, 2015.
  2. ^ Fielding, Roy T. «RFC 9110: HTTP Semantics and Content, Section 10.1.1 «Expect»«.
  3. ^ Goland, Yaronn; Whitehead, Jim; Faizi, Asad; Carter, Steve R.; Jensen, Del (February 1999). HTTP Extensions for Distributed Authoring – WEBDAV. IETF. doi:10.17487/RFC2518. RFC 2518. Retrieved October 24, 2009.
  4. ^ «102 Processing — HTTP MDN». 102 status code is deprecated
  5. ^ Oku, Kazuho (December 2017). An HTTP Status Code for Indicating Hints. IETF. doi:10.17487/RFC8297. RFC 8297. Retrieved December 20, 2017.
  6. ^ Stewart, Mark; djna. «Create request with POST, which response codes 200 or 201 and content». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
  7. ^ «RFC 9110: HTTP Semantics and Content, Section 15.3.4».
  8. ^ «RFC 9110: HTTP Semantics and Content, Section 7.7».
  9. ^ a b c d e Dusseault, Lisa, ed. (June 2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF. doi:10.17487/RFC4918. RFC 4918. Retrieved October 24, 2009.
  10. ^ Delta encoding in HTTP. IETF. January 2002. doi:10.17487/RFC3229. RFC 3229. Retrieved February 25, 2011.
  11. ^ a b «RFC 9110: HTTP Semantics and Content, Section 15.4 «Redirection 3xx»«.
  12. ^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk (May 1996). Hypertext Transfer Protocol – HTTP/1.0. IETF. doi:10.17487/RFC1945. RFC 1945. Retrieved October 24, 2009.
  13. ^ «The GNU Taler tutorial for PHP Web shop developers 0.4.0». docs.taler.net. Archived from the original on November 8, 2017. Retrieved October 29, 2017.
  14. ^ «Google API Standard Error Responses». 2016. Archived from the original on May 25, 2017. Retrieved June 21, 2017.
  15. ^ «Sipgate API Documentation». Archived from the original on July 10, 2018. Retrieved July 10, 2018.
  16. ^ «Shopify Documentation». Archived from the original on July 25, 2018. Retrieved July 25, 2018.
  17. ^ «Stripe API Reference – Errors». stripe.com. Retrieved October 28, 2019.
  18. ^ «RFC2616 on status 413». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
  19. ^ «RFC2616 on status 414». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
  20. ^ «RFC2616 on status 416». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
  21. ^ TheDeadLike. «HTTP/1.1 Status Codes 400 and 417, cannot choose which». serverFault. Archived from the original on October 10, 2015. Retrieved October 16, 2015.
  22. ^ Larry Masinter (April 1, 1998). Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). doi:10.17487/RFC2324. RFC 2324. Any attempt to brew coffee with a teapot should result in the error code «418 I’m a teapot». The resulting entity body MAY be short and stout.
  23. ^ I’m a teapot
  24. ^ Barry Schwartz (August 26, 2014). «New Google Easter Egg For SEO Geeks: Server Status 418, I’m A Teapot». Search Engine Land. Archived from the original on November 15, 2015. Retrieved November 4, 2015.
  25. ^ «Google’s Teapot». Retrieved October 23, 2017.[dead link]
  26. ^ «Enable extra web security on a website». DreamHost. Retrieved December 18, 2022.
  27. ^ «I Went to a Russian Website and All I Got Was This Lousy Teapot». PCMag. Retrieved December 18, 2022.
  28. ^ a b c d Nottingham, M.; Fielding, R. (April 2012). «RFC 6585 – Additional HTTP Status Codes». Request for Comments. Internet Engineering Task Force. Archived from the original on May 4, 2012. Retrieved May 1, 2012.
  29. ^ Bray, T. (February 2016). «An HTTP Status Code to Report Legal Obstacles». ietf.org. Archived from the original on March 4, 2016. Retrieved March 7, 2015.
  30. ^ alex. «What is the correct HTTP status code to send when a site is down for maintenance?». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
  31. ^ Holtman, Koen; Mutz, Andrew H. (March 1998). Transparent Content Negotiation in HTTP. IETF. doi:10.17487/RFC2295. RFC 2295. Retrieved October 24, 2009.
  32. ^ Nielsen, Henrik Frystyk; Leach, Paul; Lawrence, Scott (February 2000). An HTTP Extension Framework. IETF. doi:10.17487/RFC2774. RFC 2774. Retrieved October 24, 2009.
  33. ^ «Enum HttpStatus». Spring Framework. org.springframework.http. Archived from the original on October 25, 2015. Retrieved October 16, 2015.
  34. ^ «Twitter Error Codes & Responses». Twitter. 2014. Archived from the original on September 27, 2017. Retrieved January 20, 2014.
  35. ^ «HTTP Status Codes and SEO: what you need to know». ContentKing. Retrieved August 9, 2019.
  36. ^ «Screenshot of error page». Archived from the original (bmp) on May 11, 2013. Retrieved October 11, 2009.
  37. ^ a b «Using token-based authentication». ArcGIS Server SOAP SDK. Archived from the original on September 26, 2014. Retrieved September 8, 2014.
  38. ^ «HTTP Error Codes and Quick Fixes». Docs.cpanel.net. Archived from the original on November 23, 2015. Retrieved October 15, 2015.
  39. ^ «SSL Labs API v3 Documentation». github.com.
  40. ^ «Platform Considerations | Pantheon Docs». pantheon.io. Archived from the original on January 6, 2017. Retrieved January 5, 2017.
  41. ^ «HTTP status codes — ascii-code.com». www.ascii-code.com. Archived from the original on January 7, 2017. Retrieved December 23, 2016.
  42. ^
    «Error message when you try to log on to Exchange 2007 by using Outlook Web Access: «440 Login Time-out»«. Microsoft. 2010. Retrieved November 13, 2013.
  43. ^ «2.2.6 449 Retry With Status Code». Microsoft. 2009. Archived from the original on October 5, 2009. Retrieved October 26, 2009.
  44. ^ «MS-ASCMD, Section 3.1.5.2.2». Msdn.microsoft.com. Archived from the original on March 26, 2015. Retrieved January 8, 2015.
  45. ^ «Ms-oxdisco». Msdn.microsoft.com. Archived from the original on July 31, 2014. Retrieved January 8, 2015.
  46. ^ «The HTTP status codes in IIS 7.0». Microsoft. July 14, 2009. Archived from the original on April 9, 2009. Retrieved April 1, 2009.
  47. ^ «ngx_http_request.h». nginx 1.9.5 source code. nginx inc. Archived from the original on September 19, 2017. Retrieved January 9, 2016.
  48. ^ «ngx_http_special_response.c». nginx 1.9.5 source code. nginx inc. Archived from the original on May 8, 2018. Retrieved January 9, 2016.
  49. ^ «return» directive Archived March 1, 2018, at the Wayback Machine (http_rewrite module) documentation.
  50. ^ «Troubleshooting: Error Pages». Cloudflare. Archived from the original on March 4, 2016. Retrieved January 9, 2016.
  51. ^ «Error 520: web server returns an unknown error». Cloudflare.
  52. ^ «527 Error: Railgun Listener to origin error». Cloudflare. Archived from the original on October 13, 2016. Retrieved October 12, 2016.
  53. ^ «Error 530». Cloudflare. Retrieved November 1, 2019.
  54. ^ a b c d «Troubleshoot Your Application Load Balancers – Elastic Load Balancing». docs.aws.amazon.com. Retrieved May 17, 2023.
  55. ^ «Hypertext Transfer Protocol (HTTP/1.1): Caching». datatracker.ietf.org. Retrieved September 25, 2021.
  56. ^ «Warning — HTTP | MDN». developer.mozilla.org. Retrieved August 15, 2021. CC BY-SA icon.svg Some text was copied from this source, which is available under a Creative Commons Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5) license.
  57. ^ «RFC 9111: HTTP Caching, Section 5.5 «Warning»«. June 2022.

External links

  • «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
  • Hypertext Transfer Protocol (HTTP) Status Code Registry at the Internet Assigned Numbers Authority
  • MDN status code reference at mozilla.org
Источник

Hi, I’m running RClone version 1.3 and I’m trying to migrate Dropbox files to Google Drive for a friend, however, it seems to be erroring out on one of her files with HTTP error code 461. From what I can tell from Google (Can’t find official documentation), it seems to be related with a DMCA strike:-

https://forum.choiceofgames.com/t/dropbox-461-restricted-content/7636
https://forum.synology.com/enu/viewtopic.php?t=109199#p423968

Etc…

2016/06/29 07:50:32 ${FILE}: Failed to copy: failed to open source object: unexpected HTTP status code 461

Currently rclone attempts to copy it --retries times before erroring out. I think if you encounter a 461 error, there’s no point retrying it (DMCA strike won’t be removed between attempts) and the process should continue ignoring that file, outputting an error to stderr/at the end of the programs run.

Источник

Содержание

  • Что такое код ответа HTTP
  • Как проверить код состояния страницы
  • В браузере
  • В Яндекс.Вебмастере
  • В Google Search Console
  • 1* класс кодов (информационные сообщения)
  • 100 Continue
  • 101 Switching Protocols
  • 102 Processing
  • 103 Checkpoint
  • 105 Name Not Resolved
  • 2* класс кодов (успешно обработанные запросы)
  • 200 ОК
  • 201 Created
  • 202 Accepted
  • 203 Non‑Authoritative Information
  • 204 No Content
  • 205 Reset Content
  • 206 Partial Content
  • 207 Multi‑Status
  • 226 IM Used
  • 3* класс кодов (перенаправление на другой адрес)
  • 300 Multiple Choices
  • 301 Moved Permanently
  • 302 Found/Moved 
  • 303 See Other
  • 304 Not Modified
  • 305 Use Proxy
  • 306 Unused
  • 307 Temporary Redirect
  • 308 Resume Incomplete
  • 4* класс кодов (ошибки на стороне клиента)
  • 400 Bad Request
  • 401 Unauthorized
  • 402 Payment Required
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 407 Proxy Authentication Required
  • 408 Request Timeout
  • 409 Conflict
  • 410 Gone
  • 411 Length Required
  • 412 Precondition Failed
  • 413 Request Entity Too Large
  • 414 Request‑URI Too Long
  • 415 Unsupported Media Type
  • 416 Requested Range Not Satisfiable
  • 417 Expectation Failed
  • 418 I’m a teapot
  • 422 Unprocessable Entity
  • 423 Locked
  • 424 Failed Dependency
  • 425 Unordered Collection
  • 426 Upgrade Required
  • 428 Precondition Required
  • 429 Too Many Requests
  • 431 Request Header Fields Too Large
  • 434 Requested Host Unavailable
  • 444 No Response
  • 449 Retry With
  • 450 Blocked by Windows Parental Controls
  • 451 Unavailable For Legal Reasons
  • 456 Unrecoverable Error
  • 499 Client Closed Request
  • 5* класс кодов (ошибки на стороне сервера)
  • 500 Internal Server Error
  • 501 Not Implemented
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
  • 505 HTTP Version Not Supported
  • 506 Variant Also Negotiates
  • 507 Insufficient Storage
  • 508 Loop Detected
  • 509 Bandwidth Limit Exceeded
  • 510 Not Extended
  • 511 Network Authentication Required

    • Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

    Что такое код ответа HTTP

    Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

    Первая цифра в ответе обозначает класс состояния, другие две — причину, по которой мог появиться такой ответ.

    Как проверить код состояния страницы

    Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

    В браузере

    Для примера возьмём Google Chrome.

    1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

    2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

    Как посмотреть код ответа сервера в инструментах разработчика в браузере

    Как посмотреть код ответа сервера в инструментах разработчика в браузере

    В Яндекс.Вебмастере

    Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

    Как посмотреть код состояния в Вебмастере

    Как посмотреть код состояния в Вебмастере

    Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

    В Google Search Console

    Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

    Проверка URL в инструменте GSC

    Проверка URL в инструменте GSC

    Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

    Изучить просканированную страницу в GSC

    Изучить просканированную страницу в GSC

    А затем в открывшемся окне перейдите на вкладку «Подробнее»:

    HTTP код страницы в GSC

    HTTP код страницы в GSC

    Теперь расскажем подробнее про все классы кодов состояния HTTP.

    1* класс кодов (информационные сообщения)

    Это системный класс кодов, который только информирует о процессе передачи запроса. Такие ответы не являются ошибкой, хотя и могут отображаться в браузере как Error Code.

    100 Continue

    Этот ответ сообщает, что полученные сведения о запросе устраивают сервер и клиент может продолжать отправлять данные. Такой ответ может требоваться клиенту, если на сервер отправляется большой объём данных.

    101 Switching Protocols

    Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.

    102 Processing

    Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

    103 Checkpoint

    Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

    POST отправляет данные на сервер, PUT создает новый ресурс или заменяет существующий данными, представленными в теле запроса. 

    Разница между ними в том, что PUT работает без изменений: повторное его применение даёт такой же результат, что и в первый раз, а вот повторный вызов одного и того же метода POST часто меняет данные. 

    Пример — оформленный несколько раз интернет‑заказ. Такое часто происходит как раз по причине неоднократного использования запроса PUT.

    105 Name Not Resolved

    Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

    2* класс кодов (успешно обработанные запросы)

    Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений. 

    200 ОК

    Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

    201 Created

    Создано — транзакция успешна, сформирован новый ресурс или документ.

    202 Accepted

    Принято — запрос принят, но ещё не обработан.

    203 Non‑Authoritative Information

    Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).

    204 No Content

    Нет содержимого — запрос успешно обработан, однако в ответе только заголовки без контента сообщения. Не нужно обновлять содержимое документа, но можно применить к нему полученные метаданные.

    205 Reset Content

    Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

    206 Partial Content

    Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

    GET — метод для чтения данных с сайта. Он говорит серверу, что клиент хочет прочитать какой‑то документ. 

    Представим интернет‑магазин и страницы каталога. Фильтры, которые выбирает пользователь, передаются благодаря методу GET. GET‑запрос работает с  получением данных, а POST‑запрос нужен для отправки данных.

    При работе с подобными ответами следует уделить внимание кэшированию.

    207 Multi‑Status

    Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

    226 IM Used

    Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).

    3* класс кодов (перенаправление на другой адрес)

    Эти коды информируют, что для достижения успешной операции нужно будет сделать другой запрос, возможно, по другому URL.

    300 Multiple Choices

    Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

    301 Moved Permanently

    Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

    302 Found/Moved 

    Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

    303 See Other

    Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

    304 Not Modified

    Модификаций не было — с момента последнего визита клиента изменений не было.

    305 Use Proxy

    Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

    306 Unused

    Зарезервировано. Код в настоящий момент не используется.

    307 Temporary Redirect

    Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

    Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

    308 Resume Incomplete

    Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

    4* класс кодов (ошибки на стороне клиента)

    Эти коды указывают на ошибки со стороны клиентов. 

    Скриншот страницы с ошибкой 404 с сайта modcloth.com

    Скриншот страницы с ошибкой 404 с сайта modcloth.com

    400 Bad Request

    Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).

    401 Unauthorized

    Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

    Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.

    402 Payment Required

    Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

    403 Forbidden

    Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

    404 Not Found

    Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

    405 Method Not Allowed

    Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

    406 Not Acceptable

    Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

    407 Proxy Authentication Required

    Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

    408 Request Timeout

    Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

    409 Conflict

    Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

    410 Gone

    Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

    411 Length Required

    Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

    Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.

    412 Precondition Failed

    Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

    413 Request Entity Too Large

    Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

    414 Request‑URI Too Long

    Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

    415 Unsupported Media Type

    Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

    416 Requested Range Not Satisfiable

    Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

    Корректного диапазона в необходимом документе может просто не быть, или есть опечатка в синтаксисе.

    417 Expectation Failed

    Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

    418 I’m a teapot

    Первоапрельская шутка разработчиков в 1998 году. В расшифровке звучит как «я не приготовлю вам кофе, потому что я чайник». Не используется в работе.

    422 Unprocessable Entity

    Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

    423 Locked

    Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

    424 Failed Dependency

    Неуспешная зависимость — сервер не может обработать запрос, так как  один из зависимых ресурсов заблокирован.

    Выполнение запроса напрямую зависит от успешности выполнения другой операции, и если она не будет успешно завершена, то вся обработка запроса будет прервана.

    425 Unordered Collection

    Неверный порядок в коллекции — ошибка возникает, если клиент указал номер элемента в неупорядоченном списке или запросил несколько элементов в порядке, отличном от серверного.

    426 Upgrade Required

    Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

    Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

    428 Precondition Required

    Нужно предварительное условие — сервер просит внести в запрос информацию о предварительных условиях обработки данных, чтобы выдавать корректную информацию по итогу.

    429 Too Many Requests

    Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.

    431 Request Header Fields Too Large

    Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.

    Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

    434 Requested Host Unavailable

    Адрес запрашиваемой страницы недоступен.

    444 No Response

    Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

    Nginx — программное обеспечение с открытым исходным кодом. Его используют для создания веб‑серверов, а также  в качестве почтового или обратного прокси‑сервера. Nginx решает проблему падения производительности из‑за роста трафика. 

    449 Retry With

    Повторите попытку — ошибка говорит о необходимости скорректировать запрос и повторить его снова. Причиной становятся неверно указанные параметры (возможно, недостаточно данных).

    450 Blocked by Windows Parental Controls

    Заблокировано родительским контролем — говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров системы родительского контроля.

    451 Unavailable For Legal Reasons

    Недоступно по юридическим причинам — доступ к ресурсу закрыт, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. 

    456 Unrecoverable Error

    Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

    499 Client Closed Request

    Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

    5* класс кодов (ошибки на стороне сервера)

    Эти коды указывают на ошибки со стороны серверов. 

    При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.

    Изображение страницы с ошибкой сайта REG.RU

    Изображение страницы с ошибкой сайта REG.RU

    500 Internal Server Error

    Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос. 

    Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

    501 Not Implemented

    Не выполнено —  код отдается, когда сам сервер не может идентифицировать метод запроса. 

    Сами вы эту ошибку не исправите. Устранить её может только сервер.

    502 Bad Gateway

    Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

    Актуально исключительно для прокси и шлюзовых конфигураций.

    503 Service Unavailable

    Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). 

    В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

    504 Gateway Timeout

    Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

    Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

    Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

    505 HTTP Version Not Supported

    Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

    506 Variant Also Negotiates

    Неуспешные переговоры — с такой ошибкой сталкиваются, если сервер изначально настроен неправильно. По причине ошибочной конфигурации выбранный вариант указывает сам на себя, из‑за чего процесс и прерывается.

    507 Insufficient Storage

    Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

    508 Loop Detected

    Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

    509 Bandwidth Limit Exceeded

    Превышена пропускная способность —  используется при чрезмерном потреблении трафика. Владельцу площадки следует обратиться к своему хостинг‑провайдеру. 

    510 Not Extended

    Не продлён — ошибка говорит, что на сервере отсутствует нужное для клиента расширение. Чтобы исправить проблему, надо убрать часть неподдерживаемого расширения из запроса или добавить поддержку на сервер.

    511 Network Authentication Required

    Требуется аутентификация — ошибка генерируется сервером‑посредником, к примеру, сервером интернет‑провайдера, если нужно ввести пароль для получения доступа к сети через платную точку доступа.

    Источник

    Every time a task is run on a monitored device, the target server returns HTTP status codes to indicate the status of the response from the server.

    These HTTP status codes, or network error codes, will appear in the results of a monitoring session as well as in alert notifications.  These status codes are maintained by the Internet Assigned Numbers Authority (IANA) and the most current list of codes can be found here.

    Using Filters you can remove results with specific status codes from your tasks, alerts, and reports.  Click on the RFC reference documents in the list below for full details of the status codes.

    What is the HTTP Protocol? 

    Every time a user visits a website, they are making a request from their browser/client to a server that responds with the resources they requested. These requests all follow the HTTP (Hypertext Transfer Protocol) standard. The HTTP protocol, which is technically part of the application layer within the Internet Protocol suite, is just one many protocols under the IP suite. The HTTP protocol is the backbone of the Internet used for communication and sending data between clients and servers. Some of the other more common Internet protocols you many have come across include the following: 

    Application Layer Protocols 

    The application later specifies the protocols and interface methods used by clients and servers. It is the layer where the interaction between person and computer occurs and information can be sent back and forth from a server via a client/browser and interpreted and displayed for users. 

    • DNS: The DNS (Domain Name System) protocol converts domain names to human-readable IP addresses for browser so resources can be loaded.  
    • FTP: The FTP (File Transfer Protocol) protocol is used to transfer files between a browser and a server within a computer network. 
    • SMTP: The SMTP (Simple Mail Transfer Protocol) protocol is used to send and receive emails between senders and receivers on a network. 
    • TLS/SSL: The SSL (Secure Sockets Layer) protocol was officially deprecated in 2015. TLS (Transport Layer Security) was introduced in its place to provide a secure way to communicate over a network. 
    • IMAP: The IMAP (Internet Message Access Protocol) protocol is used to manage and receive messages from an email server. Unlike SMTP, you cannot use the IMAP protocol to send email messages.  
    • POP: The POP (Post Office Protocol) protocol is like IMAP, but the difference is that the POP protocol allows the user to receive messages from an email server, but the message is then deleted from the email server. The IMAP protocol can sync messages across multiple devices. It really depends on how you want users to access their emails. 
    • SIP: The SIP (Session Initiation Protocol) protocol is a signaling protocol that is used in real-time voice, video, and messaging applications. SIP is the protocol that is used to enable and deploy VoIP (Voice Over Internet Protocol) services. SIP is also used in conjunction with other protocols, such as SDP (Session Description Protocol), UDP, TCP, and TLS to carry session data and media. 

    Transport Layer Protocols 

    The transport layer handles the transmission of data, which also includes the TCP and UDP protocols, and ensuring data is sent and received correctly and promptly. 

    • TCP: The TCP (Transport Control Protocol) protocol is used to ensure transmissions between a client and server are secure and that the entire communication was processed. For example, when a server sends back a file due to a client request, the HTTP layer will communicate with the transport layer to set up and send the file requested. The TCP protocol manages the process of assembling and sending (and sometimes re-sending, if necessary) the data packets and ensures that all packets have been send and delivered. 
    • UDP: The UDP (User Datagram Protocol) protocol allows applications to send messages, called datagrams, to other hosts on a network.  

    Internet Layer Protocols 

    The internet layer, also called the network layer, is tasked with sending and reassembling network packets in the most efficient way using network addresses/IP address to send packets to their destination. 

    • IP: The IP (Internet Protocol) protocol, along with the TCP protocol, is a set of requirements that define how data is sent over the Internet.  
    • ICMP: ICMP (Internet Control Message Protocol) protocol is a network protocol that allows network devices, like routers, to help diagnose communication issues. The ICMP protocol is not concerned with exchanging data, rather its purpose is to ensure whether the data is reaching the intended destination. 

    Link Layer Protocols 

    The link layer is the group of communication methods that manages the transmission of data between physical devices and a network.

    • ARP: The ARP (Address Resolution Protocol) protocol/procedure for mapping IP network addresses to an address of a physical hardware device, otherwise known as a MAC address.  
    • MAC: The MAC (Medium Access Control) protocol gives hardware devices their unique identification number. It provides a way for the networks to connect and communicate with devices. 
    • Wi-Fi: The Wi-Fi (Wireless Fidelity) protocol, which is one of the protocols that all of us rely on for everyday life, is a group of wireless network protocols that is used for connecting to the Internet access and LANs (Local Area Networks). 

    What are Status Codes and Why are They Important? 

    There are even extensions of the HTTP protocol, which includes HTTPS (Hypertext Transfer Protocol Secure) and WebDAV (Web-based Distributed Authoring and Versioning), which we will discuss more within the HTTP status codes below. When a client makes a request to the server, status codes let you know if the request was successful, failed, or something different. Status codes are maintained by the Internet Assigned Numbers Authority, or IANA, and includes status codes from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC). As defined by the IANA organization, there are five classifications of HTTP status codes:

    1xx: Informational – Request received, continuing process
    2xx: Success – The action was successfully received, understood, and accepted
    3xx: Redirection – Further action must be taken in order to complete the request
    4xx: Client Error – The request contains bad syntax or cannot be fulfilled
    5xx: Server Error – The server failed to fulfill an apparently valid request

    Individuals and engineers regularly propose new status codes through Requests for Comments (RFC), and the IETF will review, adopt, and retire status codes as necessary.

    HTTP Status Codes Explained 

    The information below provides an overview of all the most common HTTP status codes, as well as the HTTP status codes that most folks rarely never see or even know exist. Like we mentioned, a lot of response codes are never seen by users, as they are viewable only within the network. 

    The first digit of the status code identifies the class; however, the second two digits do not play any role in further defining the status code to a specific type of message/response. Within these classification groups, there can be multiple status codes, and some groups have more status codes than others. And while there are officially over 60 unique status codes, most people will regularly only encounter a handful or two over time.  

    Most of these status codes are interpreted and processed behind the scenes. You will also see that there are groups of codes that are labeled as “Unassigned.” While most of the status codes that we see today have been standardized and have not changed over time, these unassigned numbers leave room for creating additional status codes as necessary. Additionally, even though some of the unassigned user codes are not formerly part of the HTTP (Hypertext Transfer Protocol) standard, there are companies that use them as customized server response for users, allowing companies to better troubleshoot issues users may be experiencing. Click on the RFC reference document links in the list below for full details of the specific HTTP status code. 

    A Complete List and Overview of HTTP Status Codes

    1xx Status Codes:  Informational 

    The 1xx-level HTTP status codes tell users that the request that they have made has been received but is still processing. The 1xx status codes do not necessarily mean there is an issue, it is just there to let you something is still in the process of completing. Included in this group are just a handful of 1xx codes that users may come across and need to be aware of. 

    100: Continue

    Status code 100 Continue tells you that a part of the request has been received without any problems. At this point everything is OK but is still in process. If the remaining part of the request is not rejected, the server will send a final response once the request has been completed. If the HTTP headers had been rejected, this ensures that the client does not send a request for the body. However, if the request did not contain a header field, then the browser will simply ignore the response. See RFC7231, Section 6.2.1 for more information. 

    101: Switching Protocols

    There have been many HTTP protocols created since the Internet’s humble beginnings. The first documented version of the HTTP protocol was HTTP 0.9. The current iteration is HTTP 2.0 or HTTP/2. Status code 101 Switching Protocols indicates that the server accepts the request from the client to switch to a different HTTP protocol through the Upgrade header field. When a browser makes a request for a page, it might receive the HTTP status code 101 and then the Upgrade header, which indicates the sever is switching to a different HTTP version. Finally, the assumption is that the server will agree to switch protocols only when it is beneficial, like upgrading/switching to a newer protocol versus an older one. See RFC7231, Section 6.2.2 for more information.  

    102: Processing

    A status code 102 Processing is only used with WebDAV (Web Distributed Authoring and Versioning). Most pages are read-only. WebDAV is an extension of the HTTP protocol that gives clients the ability to edit content remotely and transfer files. The WebDAV protocol was created to give users the ability to collaborate on files with others, like Dropbox or Google Drive. Status code 102 is an interim response code, telling the client that the server has accepted the full request, but has not completed the request. This HTTP status code is only sent by the server if a request is taking longer than 20 seconds. See RFC2518, Section 10.2 for more information.  

    103: Early Hints

    Status codes 103 Early Hints is currently in the evaluation/experimental phase. This status code would be used when preloading external content/resources. The HTTP/2 protocol allows content to be pushed to accelerate delivery, so web developers could push specific content while waiting for other external resources to load. This is beneficial from the end user’s perspective as it minimizes the perceived load time. This HTTP response code would indicate to a browser that the server is going to send a final response, along with the header fields included in the response. See RFC8297, Section 2 for more information

    104-199: Unassigned

    Status codes 104 through 199 are currently unassigned.

    2xx Status Code: Success 

    The 2xx-level HTTP status codes indicate that the client’s request from the server was successfully received and processed. Unlike 4xx status codes, 2xx status codes are what you want to get. Like 1xx status codes, the 2xx status codes are processed behind the scenes and rarely seen by users, unless they are using developer or SEO tools to see all the HTTP responses of a page. 

    200: OK

    One of the mostly widely used HTTP status codes, status code 200 OK is used to indicate that a request was received, processed, and was successful. However, depending on the request method used (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). For example, if the request is a GET request, the response will include the resource. If it is any of the other requests, the response will include the result of the actions. The 200 status code is one of more than 10 other response codes that is also cacheable, meaning that it can be saved and retrieved via the client, so as not to have to make another request to the server in the future. See RFC7231, Section 6.3.1 for more information. 

    201: Created

    A 201 Created status code is like a 200 OK status code, however, a 201 status code means that a request was successfully processed, and it returned, or created, a resource or resources in the process. A 201 status code is typically used for PUT requests. For example, when a PUT request is used, a new resource is created on the URL specified in the request. If there is a 201 status code in a POST request, it means a resource was created at a different API endpoint/location. See RFC7231, Section 6.3.2  for more information. 

    202: Accepted

    The 202 Accepted status code means that the server has received a request for processing, and it is been accepted, but the request has not been completed. It also does not mean the request will eventually be accepted, as it will depend on when the actual processing takes place. This type of request is typically seen in APIs where a batch process is run once a day. Since there is no way for HTTP to communicate after a request has succeeded or user’s connection has been closed, an API might send off an email to a user notifying them that the process has succeeded. See RFC7231, Section 6.3.3 for more information. 

    203: Non-Authoritative Information

    The 203 Non-Authoritative Information status code is typically used by an HTTP proxy or third party. The proxy, sitting between the client and server may change the responses before reaching the client. To indicate that something was changed during the process, a status code 203 is used. However, the drawback of this method is that it is not possible to know what the original status code was if a proxy changed something in the response. A suggested workaround is to use a warning header along with a 214 status code, which is used to indicate that there was a change or modification in the response. Using the warning header allows the original status code to passed through. See RFC7231, Section 6.3.4 for more information. 

    204: No Content

    A status code of 204 No Content indicates that the response has been successfully delivered by the server and fulfilled and no further content is to be sent in the body of the response. As an example, if the request is sent in the form on a page, once the response is sent, the client/browser is not supposed to change the view, meaning the form should not be refreshed or direct users to a new page. No additional content should be replaced or appear in terms of the user’s perspective. See RFC7231, Section 6.3.5 for more information.  

    205: Reset Content 

    Like the 204 No Content status code, a status code 205 Reset Content indicates that the server has sent the request successfully and requires the user agent to refresh/reset the view to its original state. If we use the example of a form on a page, once the user completes and submits the form, the client/browser should clear the form back to its original state so a user can take further action. A 205 status code assumes no further content will be provided. See RFC7231, Section 6.3.6 for more information. 

    206: Partial Content

    A 206 Partial Content status code can be used for a variety of requests and typically indicates that the server has fulfilled a partial request for a resource. For example, if a client is only looking for a specific portion, or range, of a specific resource or page. Another example of where a 206 status code is used is in video. A client may only load video in pieces as to not have to wait for the video to buffer or load, helping to avoid a negative user experience where a user would have to wait longer before the video plays. This is normal best practice among HTTP video players to avoid bandwidth and perceived latency issues. See RFC7233, Section 4.1 for more information.  

    207: Multi-Status

    The 207 Multi-Status status code provides status for multiple independent processes and used by WebDAV servers. The default message/response is a text/XML message. It indicates that multiple operations have taken place and that the status for each operation can be viewed in the body of the response. Status codes could vary between any one of the five categories. Response codes will vary depending on the number of sub-requests. Unlike other 200 status codes, a 207 status code does not confirm that the process was successful. The client needs to view the body of each request to determine if it was successful or not. See RFC4918, Section 11.1 for more information. 

    208: Already Reported 

    The 208 Already Reported status code is another status code used within the WebDAV extension. Like the 207 status code, it allows a client/browser to indicate to the server that a resource was already processed. When a client asks for resources, it can be possible that a response includes duplicate resources, which would mean the same resources would be sent multiple times, which is redundant. The 208 status response avoids the possibility of processing and repeating the same response. 208 status code responses will only appear in the body of response and never as an actual HTTP response. See RFC5842, Section 7.1 for more information. 

    209-225: Unassigned 

    Status codes 209 through 225 are currently unassigned. 

    226: IM Used

    A 226 IM (Instance Manipulations) Used status code is used to indicate that a server has completed a GET request for a resource, but the response is representation of one or several instance manipulations that have been applied to the current instance. Within the HTTP protocol there is an extension called Delta encoding in HTTP that is supported on the server-side. If this is implemented, the client can request changes to the cached version, and the server will send the changes instead of re-sending the entire resource again. To be able to implement this feature, the client/browser request needs to specify what IM type supported. If the server supports this feature as well, it will respond with the 226 status code and the changes. If a 200 status code is sent back, that indicates the feature is not supported. See RFC3229, Section 10.4.1 for more information.  

    227-299: Unassigned

    Status codes 227 through 299 are currently unassigned. 

    3xx: Redirection 

    The 3xx status codes are used in cases of URL redirection. Websites are always changing and evolving, so there may be times where marketers need to direct users to an updated, or different page. Redirects help alleviate users from having to search for what they are looking for and maintain your ranking in search engines. The redirect actions may be carried out by the browser automatically or may require additional interaction from users. The 3xx HTTP status codes are vital for SEO (Search Engine Optimization) and user experience, as well as tell search engines what content you want them to crawl and index. If not properly implemented, users may be directed to an unintended location, which could result in a 4xx status code and could affect SEO quality scores.

    300: Multiple Choices

    The 300 Multiple Choices status code indicates that a resource has moved and can redirect to multiple locations. In this case the user must decide which resource to use. The server may indicate a preferred choice and that should be indicated in the header field where the user agent could redirect to the preferred choice automatically. In practical use, this status code is rarely used as there is no standardized way to choose from multiple responses. See RFC7231, Section 6.4.1 for more information. 

    301: Moved Permanently

    A 301 Moved Permanently status code is utilized to indicate that a target resource has been moved to a permanent location. The 301 status code tells the browser/client to use this new location or URL going forward in the header. Along with the 301 status code, the new URL will be given in the response as well as update any URLs in the previous location(s), along with updating to the new URL. See RFC7231, Section 6.4.2 for more information. 

    302: Found

    A 302 Found status code indicates to a client/browser that a resource that they are accessing is temporarily located under a different location. Unlike the 301 status code, a 302 status code indicates a temporary move, so the client should not automatically update its links to the new location, as again, it is meant to be temporary. An example of where the 302 status code should be used if there are multiple URLs, but they could be served in different languages. A user may arrive at specific URL, but the client may redirect them automatically to the proper page based on their browser settings and use this on subsequent visits. It is noted that in some cases, browsers may change a request from POST to GET. In the case that this action is not favorable, a 307 status code should be used. See RFC7231, Section 6.4.3 for more information.  

    303: See Other

    A status code 303 See Other indicates that a server will be redirecting the client/browser to another resource. The resource will be indicated as a URL the header field. Unlike the 301 and 302 status codes, it does not mean a resource has temporarily or permanently move, its intent is to specify the URL to where the response to the specific request can be found via a GET request. 303 status codes should not be cached, however, the response to the subsequent request may be cached. A typical use of the 303 status code would be to ensure users do not accidentally resubmit form data via a POST request. They should be directed to a new page. If not, they may unknowingly click the back button in their browser, which may ask them to resubmit again, which leads to unnecessary duplicate submissions. See RFC7231, Section 6.4.4 for more information.  

    304: Not Modified

    A status code of 304 Not Modified is sent in response to a conditional GET or HEAD request. Clients/browsers can send a conditional request, such as If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, or If-Range, asking if a specific resource has been modified since a specific date/time. This is done only if the client has previously accessed, downloaded, and saved the resource. If it has been modified since that specific date/time last accessed, the server will return a 200 OK status code. If it has not been changed since that date/time, the 304 status code is sent as the response, indicating that the saved resource should be served since it has not been modified since the last time it was accessed. See RFC7232, Section 4.1 for more information. 

    305: Use Proxy

    The 305 Use Proxy status code is a deprecated status code that is no longer used due to security consideration. It was used to indicate to a client that the resource they were accessing must be accessed via a proxy. For more information on the 305 Use Proxy status code, see RFC7231, Section 6.4.5 

    306: Unused

    Like the 305 status code, the 306 Unused status was originally known as Switch Proxy. The 306 status code was used in a previous specification. Its intention was to be used as in indication to the client that subsequent requests to a resource should use the proxy that was specified. This was deemed as a security issue, so it is no longer used. For more information on the 306 Unused status code, see RFC7231, Section 6.4.6  

    307: Temporary Redirect 

    Like the 302 Found redirect status code, the 307 Temporary Redirect status code indicates to the client/browser that a resource or document is available at a different, temporary URL and returns that URL. Since the redirection is temporary and could change, the browser/client should continue to access the current URL for subsequent requests. The main difference between the 302 status code and the 307 status code is that the 307 status code does not allow changing requests from a POST request to a GET request, so if the client requested POST request, it be redirected and initiate the POST request again. See RFC7231, Section 6.4.7  

    308: Permanent Redirect 

    A 308 Permanent Redirect status code is a cacheable status code (unless cache controls are implemented) that indicates that a target resource is now located at a permanent URL and subsequent requests should be directed to that URL as well. Additionally, the client should update any old bookmarks to the new location. The 308 status code is very similar to the 301 status code, however, if a 308 status code is sent, the client has to initiate and send the same request on the target location. A 301 status code does not have to do this. Most browsers/clients change the POST request to a GET request. See RFC7238, Section 3 for more information.  

    309-399: Unassigned

    Status codes 309 through 399 are currently unassigned. 

    4xx: Client Error 

    The classification with the most HTTP status codes, 4xx HTTP status codes are not what you want your users to see. Any status code that begins with a 4 means there is an issue with the client. 4xx status codes are usually generated if a page has been deleted and not redirected, or something incorrectly entered within a URL or link. If users get a dreaded 4xx status code, that means there is a problem with the client/browser receiving information from the server. These are errors that users will see pop up on their screen and create a negative user experience, leading to a bit of frustration and them looking somewhere else. If search engines crawl your site and receive a 404 error, for example, this will show up as an error in the report. A few 404 errors are fine and search engines do not necessarily view these as a negative thing, but a 404 that redirects to a 404 could negatively impact your SEO. Not only that, if the page in question is used to drive traffic or sales, this could lead to loss in potential revenue. 

    400: Bad Request

    A 400 Bad Request error status code means that the server cannot process the request due to an issue from the client. This could be due to any number of reasons, such as a file being too large, bad syntax, an invalid URL, or some other issue caused by a third-party application, which is why the 400 status code is sometimes uses as a catch all status code, even if there is an issue on the server-side. This can make troubleshooting a 400 status code a bit more time consuming and difficult, however, along with the 400 status code error and header information, the server can provide additional response along with it, which can be displayed to the user to help identify the issue and ease the process of troubleshooting and diagnosing the error. See RFC7231, Section 6.5.1 for more information. 

    401: Unauthorized

    A 401 Unauthorized error status code indicates that the request does not include the appropriate authentication credentials, authentication has failed, or the user must log in. The client requires authentication from the server. The terms authorized and authenticated are often use interchangeably, but they mean separate things. A status code of 401 is strictly concerned with authentication. In cases where you would want to inform a client that they are not allowed at all, then a status code of 403 should be implemented. According to the specification, the 401 status code must also include the WWW-Authenticate header from the server response, indicating to the client what authentication scheme or method the server requires. See RFC7235, Section 3.1 for more information.  

    402: Payment Required 

    Originally created as part of a way to allow for potential future digital payment methods, the 402 Payment Required error status code is officially reserved for future use, but it used some limited, but rare, situations. For more information on the 402 Payment Required error code, see RFC7231, Section 6.5.2   

    403: Forbidden

    The 403 Forbidden error status code indicates that the request from the client was understood, but the server will not authorize it, so the client cannot access it. The server can make known the reason it will not authorize the request within the response, which could be due to various reasons like incorrect password or username. Unlike the 401 status code, which require authentication, a 403 status code can indicate that the client truly does not have authorization to access those resources, so authentication in this instance is not possible. See RFC7231, Section 6.5.3 for more information. 

    404: Not Found

    One of the most common and infamous status codes encountered by users and developers, the 404 Not Found error status code indicates that the resource required from the server does not exist or is not willing to provide it to the client. A 404 status code will not indicate whether the lack of providing the resource is temporarily or permanently, but the client can make subsequent requests to access it. In cases where its known that the resources are permanently gone, the 410 status code should be used. 404 status codes, by default, are also cacheable, unless other cache controls are in place. See RFC7231, Section 6.5.4 for more information. 

    405: Method Not Allowed

    The 405 Method Not Allowed error status code indicates that a specific resource requested by the client is not supported by the server. The 405 Method Not Allowed is like the 403 Forbidden status code, however, the 403 status code indicates that the resource may be available, it is just that the client does not have the necessary authorization to carry out the request. Along with the 405 Method Not Allowed status, the server must indicate the appropriate and supported methods for the target resource. For more information on the 405 Method Not Allowed error code, see RFC7231, Section 6.5.5  

    406: Not Acceptable

    Like the 405 Method Not Allowed error status code, the 406 Not Acceptable error code indicates that there is not support for a specific request. In this case the 406 Not Acceptable status code indicates that the server understood the request, but the response is not supported or understood by the client. A client can request specific versions of a resource in the header, such as A-IM or Accept Language, among others, but if the server does not support it, it responds with the 406 Not Acceptable status code. The server can either respond with a list of appropriate resource identifiers that the client can choose from. See RFC7231, Section 6.5.6 for more information.  

    407: Proxy Authentication Required

    The 407 Proxy Authentication Required error status code is like the 401 Unauthorized status code, however, in the case of a 407 status code, in order to use a proxy, the client must first be authenticated. The proxy must return the method for authentication. Not as common today due to the rise of VPNs, proxies act as intermediaries between users/clients and the Internet, allowing users to access resources more quickly, as content is typically cached, and can also provide a layer of security and anonymity for users. For more information on the 407 Proxy Authentication Required error code, see RFC7235, Section 3.2  

    408: Request Timeout

    A 408 Request Timeout error status code means that the server did not receive a request from the client in a specified amount of time. A delayed request from the client can be due for a variety of reasons, such as a slow or broken connection. Once that time has passed, the 408 Request Timeout status is sent by the server and the user/client can resend the request again. For more information on the 408 Request Timeout error code, see RFC7231, Section 6.5.7 

    409: Conflict

    A 409 Conflict error status code indicates that the request from the client could not be processed due to a conflict with the server. The request from the client was fine, but there were issues on the server-side that prevents the request from being executed. An example of this could be if there was a request for a specific file to be edited, deleted, or created by the user, but those functionalities are not allowed. Along with the 409 response, the server should return instructions on how the user can resolve this issue or indicate why the issue is occurring. See RFC7231, Section 6.5.8 for more information. 

    410: Gone

    Like the 404 Not Found error status code we covered earlier, the 410 Gone status code indicates that the resource the client is requesting has been removed and no longer available from the server. No further information is provided in terms of URL redirection or where to access the resource. It has been removed indefinitely. For more information on the 410 Gone error code, see RFC7231, Section 6.5.9  

    411: Length Required

    The 411 Length Required error status code indicates that the server does not allow the request from the client due to a predefined request body content length. The request can be repeated by the client if a valid Content-Length header is specified in the subsequent resource request. For more information on the 411 Length Required error code, see RFC7231, Section 6.5.10  

    412: Precondition Failed

    Conditional requests to the server are allowed as part of the HTTP protocol. If the right conditions are met in the request, the request is executed and processed by the server. A 412 Precondition Failed error status code means that one, or several, conditions in the request header has failed. For example, this can be used in GET requests and a conditional request is utilized to return the resource only if that resource has changed. For more information on the 412 Precondition Failed error code, see RFC7232, Section 4.2  

    413: Request Entity Too Large

    The 413 Request Entity Too Large error status code indicates that the server will not accept and process the request due to the request body being larger than the server will allow or can process. Such examples include uploading a file where the file exceeds the maximum upload size set by the server or when the maximum number of uploads has been exceeded. In cases where the 413 Request Entity Too Large error occurs, the server may close the connection completely to prevent the client from continuing to sending the request. In some cases, it is likely the server would allow the client to retry the request, if itis a temporary condition, and should include that message back to the client. However, it is possible the request could cause the server itself to run out of physical disk space. In this case, the 507 Insufficient Storage error is the response that the client should receive back. See RFC7231, Section 6.5.11 for more information.  

    414: URI Too Long

    Not a very common server response, the 414 URI Too Long error status code means that the server refused the client request due to the URL being longer than the server can process. Browsers and search engines do put limits on the length of URLs, partly to avoid DDoS attacks or code errors, but the path of a URL or HTTP does not have explicit limits. So, if limit exceeds what is set by the server, the 414 URI Too Long error will occur. For more information on the 414 URI Too Long error code, see RFC7231, Section 6.5.12  

    415: Unsupported Media Type

    The 415 Unsupported Media Type error status code indicates the server cannot process the request body, or part of the request body, due to an unsupported media format. Even if the request from the client is supported, the 415 error may be returned if there is unsupported content in the body of the request. A 415 Unsupported Media Type error code is like the 406 Not Acceptable status code. The difference is that a 406 Not Acceptable error code is not due to the content in the header or encoding, rather, it is due to the value set within the HTTP header. Ensuring that the server can process the defined format along with sending the request with the correct form will avoid a 415 Unsupported Media Type error status code from happening. See RFC7231, Section 6.5.13 for more information. 

    416: Range Not Satisfiable

    As mentioned with the 206 Partial Request status code, it is possible for clients/browsers to request a partial response back from the server, whether it is a specific part of a file or video for example. Clients and servers use what is called range requests to execute these requests. However, if the server does not support these types of requests, it will simply return the entire resource along with a 200 OK response. If the server does support range requests, that is where the 416 Partial Request error status code enters the picture and will return what the client is asking for. In a situation where the server does support range requests, but the server does not agree with the request received because it does not fall within the range or possibly beyond the specified range, the 416 Range Not Satisfiable error status code will be returned. See RFC7233, Section 4.4 for more information.  

    417: Expectation Failed 

    Clients can use an Expect header to indicate that it expects specific behavior from the server. Like described in the 100 Continue status code, clients can check with the server if it will accept a request. If it does, the server will respond with the 100 Continue status code. If not, the 417 Expectation Failed error status code indicates that the server did not understand the Expect header or support it, therefore it cannot process the client request. For more information on the 417 Expectation Failed error code, see RFC7231, Section 6.5.14  

    418-420: Unassigned

    Error status codes 418-421 are currently unassigned, however, status code 418 I’m a Little Teapot is used in some instances. Created as an April Fool’s joke, it has gained some traction and is sometimes used as a joke or Easter egg and not used for actual everyday purposes. Most browsers ignore it as it is not an official status code. Another one in this category is the 420 Enhance Your Calm error status code that was introduced by Twitter. It is an error code that tells clients that they are being rate limited, which is a restriction on the number of requests they can make within a specified time period. Since 1989, the RFC Editor will publish the more humorous RFCs. Wikipedia has a full rundown of the more humorous April Fool’s RFCs. 

    421: Misdirected Request 

    Introduced with the HTTP/2 protocol, the 421 Misdirected Request error status code means that the server received a request that was not intended for that specific server and cannot properly respond. This can happen if the DNS (Domain Name System) is set to the wrong IP address. Clients are required to include a Host header in the request. This can also occur with sites that have a single SSL certificate from multiple domains. This can be caused by an issue with the hosting provider and/or specific browser used, so it can require a great deal of work to really understand where the issue lies. If a server knows that a domain is not configured on the request, it will respond with the 421 Misdirected Request error response. See RFC7540, Section 9.1.2 for more information. 

    422: Unprocessable Entity

    A 422 Unprocessable Entity error status code indicates an issue with the contents of the syntax of a request. The arrangement of the request was understood by the server, but the fields within the request are invalid or does not match what the server expects. Like the 102 Processing and 207 Multi-Status status codes, a 422 Unprocessable Entity error code is part of the WebDAV protocol and often used with web services/APIs. Generally, a 400 Bad Request is the recommend response, but if WebDAV is supported, then the 422 Unprocessable Entity should be used. See RFC4918, Section 11.2 for more information. 

    423: Locked

    Like the 422 Unprocessable Entity error status code, the 423 Locked error status code is also part of the WebDAV protocol. The 423 Locked status code indicates that a file, resource, or directly, for example, cannot be edited. Its purpose is to avoid multiple users updating a file, resource, etc., simultaneously. These resources can then be unlocked for editing, when necessary. For more information on the 423 Locked error code, see RFC4918, Section 11.3 

    424: Failed Dependency 

    Another status code supported by the WebDav protocol; the 424 Failed Dependency error status code indicates the request from the client failed due to a dependency on another request that also failed. WebDAV utilizes a method known as PROPPATCH to update certain resource properties. To indicate if a resource was updated successfully or not, WebDAV uses standard HTTP status code responses. Additionally, the 424 Failed Dependency status code is only used in instance where the response in the HTTP body has the 207 Multi-Status response. So, if PROPPATCH is used and resource fails to update, it will send a 4xx status code indicating there is an error updating the resource, the 424 Failed Dependency error code will also be sent along with the other requests that depended on that update being successful but failed. See RFC4918, Section 11.4 for more information. 

    425: Too Early

    Not a common HTTP status code that is used today, the 425 Too Early error response code is used in situations where an HTTP client is connecting to an HTTPS client. During the process, it may take a long time to establish a connection between the server and client. This process can pose a security issue, so the server will tell the client to retry the request until the secure TLS (Transport Layer Security) connection has been made. In that case, the 425 Too Early status code will be returned. For more information on the 425 Too Early error code, see RFC8470, Section 5.2  

    426: Upgrade Required 

    The 426 Upgrade Required error status code indicates to the client that it needs to utilize a newer protocol in order to send requests to the server. For example, the client may be using and older version of HTTP, like HTTP/1.0, but the server requires HTTP2.0. The server will not accept the request but will respond back to the client indicating which protocol or protocols are acceptable. Once the client has upgraded to the required protocol(s), the server will accept requests from the client. For more information on the 426 Upgrade Required error code, see RFC7231, Section 6.5.15 

    427: Unassigned

    Error status code 427 is currently unassigned. 

    428: Precondition Required 

    The 428 Precondition Required error status code indicates to the client that the request to the server must be a conditional request. As mentioned in the 304 Not Modified status code, a client can send a conditional request to the server, such as If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, or If-Range. However, these conditional requests are not required. If they are required by the server, the server indicates this by responding with the 428 Precondition Required error code. This is a bit similar to the 412 Precondition Failed error code, but the 412 Precondition Failed error code is returned only if the client included a conditional request in the header that does not match the state of the resource on the server’s side. By notifying users that requests must be conditional in nature, this ensures users are working with the right files or resources and helps prevent users from potentially overwriting changes. See RFC6585, Section 3 for more information. 

    429: Too Many Requests 

    Just like the name of the error code indicates, the 429 Too Many Requests error status code means that rate limiting is implemented, and that the client went over the limit for how many requests it can make in a specified amount of time. Along with the 429 Too Many Requests error response, it should be indicated how long to wait before initiating a new request to the server, but it is not formerly required to do so. For more information on the Too Many Requests error code, see RFC6585, Section 4  

    430: Unassigned

    The 430 error status code is currently unassigned, however, it was at one time proposed to be the 430 Would Block error code within the HTTP/1.1 protocol. The intent was to serve as a response to what is known as pipelining. This allowed clients to send multiple requests, over a TCP connection, while it waited for the server to respond. It never officially made it into the standard as the HTTP protocol was updated to HTTP/2.0 and support for pipelining was never widely adopted.  

    431 Request Headers Too Large 

    The 431 Request Headers Too Large error status code indicates the client sent a header request that exceed the allowable limit. Different web servers have varying allowable size limits when it comes to headers. This could be due to an individual header request being too large or due to the entire combined size of all the header requests. In most cases, this can be easy to remedy, as it is typically caused by sending too many cookies or cookies that are too large in file size. For more information on the 431 Request Headers Too Large error code, see RFC6585, Section 5   

    432-450: Unassigned

    Error status codes 432 through 450 are currently unassigned. 

    451: Unavailable Due to Legal Reasons 

    Error status code 451 Unavailable Due to Legal Reasons indicates the server is refusing to serve up the requested content due to legal reasons and should also include the reason for the error in the response to the user. Reasons for using the 451 Unavailable Due to Legal Reasons error status code could include governments that censor specific content, content that violates copyright laws, like the DMCA (Digital Millennium Copyright Acts), or content that is violates laws or court orders. The 403 Forbidden and 404 Not Found error status codes are sometimes used in place of the 451 error status code, but the 451 error status code provides more information or explanation into why the error is occurring. Users have typically gotten around the 451 error by implementing VPNs to access the content. See RFC7725, Section 3 for more information. 

    452-499: Unassigned

    Error codes 452-499 are currently unassigned.

    5xx: Server Error 

    Like the 4xx status codes, the 5xx status codes indicate there is an error, however the error in question is not likely due to a bad connection or the browser itself. 5xx status codes indicate there is an issue at the server level and cannot process the request from the client. Along with the error, the server should respond with an explanation of the error, whether it is a temporary or permanent condition, and how it may be remedied. 

    500: Internal Server Error

    The 500 Internal Server Error status code simply means that the server encountered an issue and cannot process the request. Typically, the 500 Internal Server Error code used more as a generic server error code if the exact issue does not fall within any of the other 5xx Server Error status code specifications. The 500 Internal Server Error code is probably the most used of the 5xx Server Error classification codes. See RFC7231, Section 6.6 for more information.  

    501: Not Implemented

    A 501 Not Implemented error status codes occurs when the server does not recognize the method of the request and therefore, cannot support or process the request. It is like the 405 Method Not Allowed client error status code, but a 501 Not Implemented error status code could indicate that the request method from the client is valid, just not supported by the server. The 405 Method Not Allowed error status would indicate that the method called by the client is not supported and should not have been utilized. See RFC7231, Section 6.6.2 for more information.  

    502: Bad Gateway

    The 502 Bad Gateway error status code means that a server is acting a proxy and it received a response from an origin server that came back as invalid. It is possible it is due to an overloaded server and the client can resubmit the request, but in most cases, it is due to an issue with the web server or CDN (Content Distribution Network) sitting between the client and server and may require additional troubleshooting with the hosting provider to understand why the error is being thrown. See RFC7231, Section 6.6.3 for more information.  

    503: Service Unavailable

    The 503 Service Unavailable error status code indicates the server is currently overloaded with requests or out of resources, is currently in maintenance, or possibly that the application they are trying to access is down, and the server unable to complete the request due to the current state. Clients will sometimes see a message along with the 503 Service Unavailable error status code telling them to try the request again later. However, it may not provide a definitive explanation of when or how long the 503 Service Unavailable error status code may last. See RFC7231, Section 6.6.4 for information.  

    504: Gateway Timeout

    Like the 502 Bad Gateway error status code, the 504 Gateway Timeout error status code is used when the server is acting as proxy but will respond with a 504 Gateway Timeout error status code if the response from an origin server takes too long to respond. A 502 Bad Gateway error status code should be used in cases where the response was invalid or not received by the proxy server at all. The message along with the 504 Gateway Timeout may indicate and recommend that the client try resending the request. See RFC7231, Section 6.6.5 for more information. 

    505: HTTP Version Not Supported

    A 505 HTTP Version Not Supported error status code means that the server does not support the version of the HTTP protocol used in the message of the request, and therefore, cannot process the request. Along with the 505 HTTP Version Not Supported error status code, the response from the server should include a message indicating why that specific HTTP protocol is not supported and which protocols are supported. See RFC7231, Section 6.6.6 for more information.  

    506: Variant Also Negotiates

    The 506 Variant Also Negotiates is an experimental HTTP status code and is not part of the standard today. A 506 Variant Also Negotiates indicates that there in an internal configuration issue with the server due to content negotiation issues. Content negotiation allows clients to send multiple accept headers and tells the server which specific representation of a resource to serve as indicated by the browser. This could be for serving up the right language, document format, etc. Even though the 506 Variant Also Negotiates error status code is in an experimental status and not officially part of the HTTP standard, is used in rare cases. Some Google Play users encountered this issue in the past when trying to download multiple versions of an application, causing their devices to continually try to download the app in a closed loop process. See RFC2295, Section 8.1 for more information.  

    507: Insufficient Storage

    A 507 Insufficient Storage server error status code is also part of the WebDAV protocol. The 507 Insufficient Storage error status code indicates to the client that the request, such as a PUT or POST request, was too large in file size. It can also indicate that the server has temporarily run out of storage. See RFC4981, Section 11.5 for more information.  

    508: Loop Detected

    The 508 Loop Detected server error status code, like the 507 Insufficient Storage server error code, is part of the WebDAV protocol. Within the WebDAV protocol, it is possible the client can make a request to a server for an entire directory and create a target somewhere that same directory, resulting in an infinite request/response loop. The 508 Loop Detected server error status code indicates that the server ended the client request, specifically Depth: Infinity, because the server identified the request as resulting in an infinite loop, repeatedly calling back on itself. See RFC5842, section 7.2 for more information. 

    509: Unassigned

    The 509 server error status code is currently unassigned. 

    510: Not Extended

    A 510 Not Extended server error status code is currently in proposed/experimental status and not part of the standard HTTP status code specification. The 510 Not Extended indicates to the client that the request requires an extended HTTP request. If the server responds with the 510 Not Extended server error status code, it should also include how the client should remedy their request, but the specification does not explicitly state that. There’s debate whether this should fall under the 5xx server error classification since it could be viewed as a 4xx client error, but since it is not formally part of the standard, it is not relevant and rarely used for everyday use. See RFC2774, Section 7 for more information.  

    511: Network Authorization Required

    The 511 Network Authorization Required server error status code that requires the client to authenticate itself in order to gain access to a network. For example, users might see this when trying to connect to a public Wi-Fi network at a business and users must agree to their terms and conditions before being granted access. Along with the 511 Network Authorization Required server error response, users should also be directed to where they can log in. See RFC6585, Section 6 for more information. 

    512-599: Unassigned

    Server error status codes 512-599 are currently unassigned, but some companies may use any of these as custom server error messages to clients. 

    Monitoring HTTP Status Code Responses 

    To see a list of status codes for a specific URL firsthand, you can check the developer tools tab within your browser. Along with the page load speed metrics, you can also view any server responses, along with all the associated HTTP status codes, to ensure that everything on your page is loading and rendering properly. 

    For a more proactive and automated monitoring approach, the professional monitoring solutions from Dotcom-Monitor can ensure that whenever a specific HTTP error code is encountered by a user, your teams are notified immediately so they can quickly remedy the issue. You can also use the Filters feature to remove individual HTTP status codes from tasks, alerts, and reports, so you disregard any HTTP status codes that are not relevant to your specific needs. 

    Источник

    Оптимизируйте свои подборки

    Сохраняйте и классифицируйте контент в соответствии со своими настройками.

    На этой странице описывается, как коды статуса HTTP, а также ошибки сети и DNS отражаются на позиции вашего контента в Google Поиске. Мы поговорим о 20 наиболее распространенных кодах статуса, которые обнаруживает на веб-страницах робот Googlebot, а также о самых частых ошибках сети и DNS. Такие редко встречающиеся коды, как 418 (I'm a teapot), в этой статье не рассматриваются. Все перечисленные на этой странице проблемы приводят к появлению ошибки или предупреждения в отчете об индексировании страниц, доступном в Search Console.

    Коды статуса HTTP

    Когда сервер, на котором размещен сайт, получает запрос клиента (например, браузера или поискового робота), в ответ он отправляет код статуса HTTP. Каждый такой код имеет свое значение, но многие из них предполагают, что запрос будет обрабатываться одинаково. Например, о переадресации могут сигнализировать несколько разных кодов.

    Сообщения об ошибке, генерируемые в Search Console, относятся к кодам статуса в диапазоне 4xx–5xx, а также к неудачной переадресации (3xx). Если в ответе сервера указан код статуса 2xx, полученный контент может быть проиндексирован.

    В таблице ниже приведены коды статуса HTTP, с которыми чаще всего сталкивается робот Googlebot, и пояснения о том, как обрабатывается каждый такой код.

    Коды статуса HTTP

    2xx (success)

    Роботы Google проверяют, можно ли проиндексировать контент. Если контент не загружается, например появляется пустая страница или сообщение об ошибке, в Search Console будет зарегистрирована ошибка soft 404.

    200 (success)

    Страница передается на индексирование. Наши алгоритмы могут проиндексировать контент, но это не гарантировано.

    201 (created)
    202 (accepted)

    Робот Googlebot ждет некоторое время, не загрузится ли страница, а затем передает ее для индексирования. Время ожидания зависит от агента пользователя. Например, у робота Googlebot для смартфонов и у Googlebot Image оно разное.

    204 (no content)

    Робот Googlebot сообщает алгоритмам индексирования, что контент не получен. В отчете об индексировании страниц этого сайта в Search Console может быть указана ошибка soft 404.

    3xx (redirection)

    Робот Googlebot выполняет до 10 переходов в цепочке переадресаций. Если за это время поисковый робот не получает контент, в отчете об индексировании страниц этого сайта в Search Console будет указана ошибка переадресации. Количество переходов робота Googlebot зависит от агента пользователя, например у роботов Googlebot Smartphone и Googlebot Image оно будет отличаться.

    Googlebot выполняет пять переходов в цепочке переадресаций согласно спецификации RFC 1945. Затем он прерывает операцию и интерпретирует ситуацию как ошибку 404.

    Наши роботы игнорируют любой контент, получаемый с URL переадресации. При индексировании используется контент, размещенный по конечному целевому URL.

    301 (moved permanently)

    Робот Googlebot выполняет переадресацию, а алгоритм индексации интерпретирует это действие как явный сигнал того, что перенаправление должно выполняться на каноническую страницу.

    302 (found)

    Робот Googlebot выполняет переадресацию, а алгоритм индексации интерпретирует это действие как неявный сигнал того, что перенаправление должно выполняться на каноническую страницу.

    303 (see other)
    304 (not modified)

    Робот Googlebot сообщает алгоритму индексирования, что страница не была изменена с момента предыдущего сканирования. В связи с этим система может по-новому интерпретировать сигналы, относящиеся к определенному URL. Если же она этого не сделает, то код статуса не повлияет на индексацию.

    307 (temporary redirect) Этот код интерпретируется так же, как и 302.
    308 (moved permanently) Этот код интерпретируется так же, как и 301.

    4xx (client errors)

    Роботы Google не индексируют URL с кодом статуса 4xx, а те URL, которые уже проиндексированы и выдают код статуса 4xx, удаляются.

    Роботы Googlebot игнорируют любой контент, получаемый с URL, которые возвращают код статуса 4xx.

    400 (bad request)

    Все ошибки 4xx, за исключением 429, обрабатываются таким же образом. Googlebot сообщает, что контент отсутствует.

    Если ранее URL был проиндексирован, мы удалим его из индекса.
    Обнаруженные страницы с кодом 404 не обрабатываются. Частота сканирования постепенно снижается.

    401 (unauthorized)
    403 (forbidden)
    404 (not found)
    410 (gone)
    411 (length required)
    429 (too many requests)

    Робот Googlebot интерпретирует код статуса 429 как сигнал того, что сервер перегружен и что имеет место его ошибка.

    5xx (server errors)

    В случае ошибок сервера 5xx и 429 роботы Google временно замедляют сканирование. Уже проиндексированные URL сохраняются в индексе, но в скором времени удаляются.

    Если файл robots.txt выдает ошибку сервера более 30 дней, будут выполняться правила, указанные в последней кешированной копии этого файла. Если такой копии нет, роботы Google будут действовать без ограничений.

    Роботы Googlebot игнорируют любой контент, получаемый с URL, которые возвращают код статуса 5xx.

    500 (internal server error)

    Робот Googlebot снижает скорость сканирования сайта. Частота сканирования уменьшается пропорционально количеству отдельных URL, которые возвращают ошибку сервера.
    Google удаляет из индекса URL, постоянно возвращающие такую ошибку.

    502 (bad gateway)
    503 (service unavailable)

    Ошибки soft 404

    Ошибкой soft 404 называется ситуация, когда посетитель веб-страницы видит сообщение о том, что ее не существует, при этом браузер получает ответ с кодом статуса 200 (success). Этот код означает «Успешно». В некоторых случаях открывается страница, на которой нет основного или вообще никакого контента.

    Такие страницы создаются веб-сервером, где размещен сайт, системой управления контентом или браузером пользователя. Причины могут быть разными. Пример:

    • Отсутствие файла SSI
    • Ошибка при обращении к базе данных
    • Пустая внутренняя страница результатов поиска
    • Незагруженный или отсутствующий по другой причине файл JavaScript

    Мы не рекомендуем возвращать код статуса 200 (success), а затем выводить сообщение об ошибке или указывать на наличие ошибки на странице. Пользователи могут подумать, что попали на действующую страницу, но после этого увидят сообщение об ошибке. Подобные страницы исключаются из Google Поиска.

    Если алгоритмы Google по контенту страницы определяют, что она содержит сообщение об ошибке, то в отчете об индексировании страниц этого сайта в Search Console будет указана ложная ошибка soft 404.

    Порядок исправления ошибок soft 404

    Есть разные способы устранения ошибок soft 404 в зависимости от состояния сайта
    и от желаемого результата:

    • Страница и ее контент больше не доступны
    • Страница или ее контент были перенесены
    • Страница и ее контент по-прежнему существуют

    Подумайте, какое решение будет оптимальным для ваших пользователей.

    Страница и ее контент больше не доступны

    Если страница удалена и для нее нет замены на вашем сайте с аналогичным контентом, нужно отправлять ответ с кодом статуса 404 (not found) или 410 (gone). Эти коды статуса сообщают поисковым системам, что страницы не существует, а контент не нужно индексировать.

    Если у вас есть доступ к файлам конфигурации вашего сервера, страницы с сообщениями об ошибках можно сделать полезными для пользователей. Например, на такой странице 404 вы можете разместить функции, призванные помогать посетителям в поиске нужной информации, или полезный контент, который удержит их на вашем ресурсе. Вот несколько советов по созданию полезной страницы 404:

    • Пользователям должно быть понятно, что запрашиваемая страница недоступна. Подготовьте сообщение, которое не вызовет отторжения.
    • Страница 404 должна быть выполнена в том же стиле (включая элементы навигации), что и основной сайт.
    • Разместите на странице ссылки на самые популярные статьи или записи блога, а также на главную страницу.
    • Дайте пользователям возможность сообщать о неработающих ссылках.

    Полезные страницы 404 создаются исключительно для удобства пользователей. Поисковые системы игнорируют такие страницы, поэтому рекомендуем возвращать для этих страниц код статуса HTTP 404, чтобы они не индексировались.

    Страница или ее контент перемещены

    Если страница перенесена или у нее есть замена, отправляйте ответ с кодом 301 (permanent redirect), чтобы перенаправлять пользователей. Посетителям сайта это не помешает, а поисковые системы узнают новое расположение страницы. Чтобы узнать, правильный ли код ответа отправляется при открытии страницы, используйте инструмент проверки URL.

    Страница и ее контент по-прежнему существуют

    Если нормально работающая страница вызвала ошибку soft 404, вероятно, она не была корректно загружена роботом Googlebot, во время отрисовки не были доступны важные ресурсы или показывалось заметное сообщение об ошибке. Проанализируйте отрисованный контент и код ответа HTTP с помощью инструмента проверки URL. Если на обработанной странице нет или очень мало контента или он вызывает ошибку, ошибка soft 404 может быть обусловлена тем, что страница содержит ресурсы (например, изображения, скрипты и прочие нетекстовые элементы), которые не удается загрузить.
    Возможные причины проблем с загрузкой – блокировка доступа в файле robots.txt, слишком большое количество ресурсов или слишком большой их размер, а также любые ошибки сервера.

    Ошибки сети и DNS

    Ошибки сети и DNS отрицательно влияют на показ URL в результатах поиска Google.
    Робот Googlebot интерпретирует тайм-ауты сети, факты сброса подключения и ошибки DNS так же, как и ошибки серверов 5xx. В случае сетевых ошибок сканирование начинает постепенно замедляться, поскольку сетевая ошибка означает, что сервер может не справиться с нагрузкой. Так как роботы Googlebot не смогли получить доступ к серверу, на котором размещен сайт, значит, им не удалось извлечь контент. В результате Google не может проиндексировать ранее просканированные URL, а недоступные нашим роботам URL, которые уже были проиндексированы, будут удалены из индекса Google в течение нескольких дней. Search Console может создавать сообщения о каждой возникающей ошибке.

    Ошибки отладки сети

    Эти ошибки возникают до того, как Google начинает сканирование URL, или во время этого процесса.
    Поскольку они зачастую уже присутствуют до того, как сервер возвращает ответ, то из-за отсутствия кода статуса диагностика этих ошибок может вызывать трудности. Чтобы отладить ошибки тайм-аута и сброса подключения, выполните следующие действия:

    • Проверьте настройки брандмауэра и записи в журнале. У вас может быть задано слишком общее правило блокировки. Нужно, чтобы ни одно правило брандмауэра не блокировало IP-адреса робота Googlebot.
    • Проанализируйте сетевой трафик с помощью таких инструментов как tcpdump и Wireshark. Они помогут вам найти в пакетах TCP аномалии, относящиеся к определенному сетевому компоненту или модулю сервера.
    • Если вы не можете найти ничего подозрительного, обратитесь к своему хостинг-провайдеру.

    Ошибка может относиться к любому серверному компоненту, который обрабатывает сетевой трафик. Возможно, что перегруженные интерфейсы сети не могут передавать пакеты, что приводит к тайм-аутам (невозможности установить подключение) и сбросу подключений (отправляется пакет RST, поскольку порт был закрыт по ошибке).

    Устранение ошибок DNS

    Ошибки DNS чаще всего вызваны неправильной конфигурацией, но могут также возникать из-за правил брандмауэра, которые блокируют DNS-запросы робота Googlebot. Чтобы устранить ошибки DNS, выполните следующие действия:

    • Проверьте правила брандмауэра. Нужно, чтобы ни одно правило не блокировало IP-адреса Google и чтобы были разрешены запросы как по протоколу UDP, так и по протоколу TCP.
    • Проверьте записи DNS. Убедитесь, что записи A и CNAME ведут на правильные IP-адреса и имена хостов. Пример:

      dig +nocmd example.com a +noall +answer
      dig +nocmd www.example.com cname +noall +answer
    • Убедитесь, что все ваши DNS-серверы указывают на правильные IP-адреса вашего сайта. Пример:

      dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...
    • Если вы внесли изменения в конфигурацию DNS в течение последних 72 часов, на их применение во всей сети DNS может потребоваться некоторое время. Чтобы ускорить внедрение новых настроек, вы можете очистить общедоступный кеш DNS.
    • Если вы используете собственный DNS-сервер, убедитесь, что он исправен и не перегружен.

    Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons «С указанием авторства 4.0», а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.

    Последнее обновление: 2023-02-20 UTC.

    Источник

    Понравилась статья? Поделить с друзьями:
  • 4603 ошибка ман
  • 4600 bmw ошибка
  • 460 ошибка http
  • 45у102 ошибка sel
  • 45h ошибка закрытия чека