• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question is a code 499 a problem?

larryk

Regular Pleskian
Hi,

running nginx, FPM application served by nginx,

testing/watching a site via real time log files.

1) i don't see the problem in the browser, but i see the error in log file
2) i've seen it a few times, not a lot
3) this is what i see:

Code:
2016-12-19 15:08:30    Error    192.154.179.34    499    GET /contact/ HTTP/1.1    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12    0    nginx access
2016-12-19 15:08:30    Access    192.154.179.34    200    GET /contact/ HTTP/1.1     Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12    28.0 K    nginx access

again, i see no problem in the browser, but only see the 499?

Should i be concerned?
I guessing its just a short/quick timing issue?

OR is there something that needs to be done?

thanks
 
The nginx web server expands the 4xx error space to signal issues with the client's request. These are only used for logging purposes, no actual response is sent with these codes.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.
 
thanks... but :)

1) so the 499 code is not important, is not a concern?
2) if #1 above is correct, why is plesk logging it? (other than to confuse me and make me create this thread *GRIN* )


just for my knowledge --- is this what it means:
a) a person's browser tries to access/request a web page on plesk, nginx server (example: www .domain.com/index.html)
b) the person's browser initiates the request, but the browser closes/ ends the request BEFORE the plesk server can response to the request
c) steps A & B happen for a 2nd time and everything goes according to plan

NOW, no one knows how or why steps A and B occurred... it just did, but there is no problem?
as you can see in the original post, the 1st and 2nd request happen at same time.

do other people see this happening?
is it normal?
is it a nginx thing?

NOTE: i'm still testing my new plesk server and have seen it a few times. I guess I'm a little worried that it could happen a lot once I go live?
 
does anyone else get these 499 codes?

update: the client (gets a "the domain.com took too long to repond") message in the browser?
I believe this is related to the 499 codes?

there is an issue, but not sure how or where or how to help my client?
do i say its your fault?
is there something that can be tweaked on my server?

help?

any thoughts?
 
updated... this is over my head, but these 2 links list items about "time out settings"?

http://stackoverflow.com/questions/...-despite-config-php-and-aws/15621223#15621223

http://stackoverflow.com/questions/12973304/nginx-499-error-codes


important items? again.. all this over my head:

1)
One of the reasons for this behaviour could be you are using http for uwsgi instead of socket. Use the below command if you are using uwsgi directly.

uwsgi --socket :8080 --module app-name.wsgi

Same command in .ini file is

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi


2)
Try to play with these settings:

  • php-fpm`s request_terminate_timeout
  • nginx`s fastcgi_ignore_client_abort
3)
request_terminate_timeout was one of the settings I changed (see the middle of the original post) and has been set to 120 fastcgi_ignore_client_abort I'd not tried this before and enabling it has made a difference as now NginX is reporting a 200 response in the access log rather then the 499
 
Probably all a waste of time. It's purely a client issue, nothing else. No need to worry about server configuration.

Example 1: Client clicks link A, then clicks B immediately afterwards.
Example 2: A bad plugin, antivirus software, virus on the client computer interrupts traffic.
Example 3: IP of client changes or other awkward network things are happening while a request is unprocessed.
Example 4: Browser window closes.

update: the client (gets a "the domain.com took too long to repond") message in the browser?
Your client has a network or connectivity issue.
 
thanks Peter for the help... but this is what I know:

1) my client is not doing any of the 4 examples you provided ... this is my client using the browser in a password protect directory, updating DB records, etc. (ie. its not a random site visitor)
2) the browser error page can show up instantly OR take several seconds/ little time before showing the timeout issue
3) the browser has done this before: a) flashes the error or pauses b) THEN AUTOMATICALLY refreshes itself and/or just ends up showing the page fine (as if nothing happened)
4) obviously, the page/site works the majority of the time... so something odd, limited, somethings happens.... however, for example...
1 out of 10 or 20 or 30 times it happens?

do those items help try to figure out something?

the problem did not exist before (while I was on apache and old server) :(
now, nginx and a MUCH better server...

there seems like something could be tried? those settings that were listed in other people's discussions... you don't think any of those would help?
or help to try to test something?

thanks!
 
... those settings that were listed in other people's discussions... you don't think any of those would help?...

No, they don't help. It's a network issue. It could be a proxy server between the client and the Plesk host, it could also be a malware. It is really very unlikely that it is related to a setting on the host. The "fastcgi_ignore_client_abort" for instance more or less means "don't show the error message", but that's only curing symptoms, not the cause. The cause will be found on the client or in the client's network.
 
thanks... i had my hosting support team basically come back with the same answers. (from nginx statements, etc. etc)
While I don't disagree and guessing the answer/solution doesn't exist?

I forget what I was doing today, but the 499 happened to me: see attached image
it was a site home page.
my browser is fine. my internet connection is fine. and so on and on.

I would say its next to impossible to find a fault in my setup/client side, that would explain the 499.

but anyway... seems the 499 nginx error is a "just hope it doesn't happen much" because no one can fix it. :(
it does happen, to many people, but not enough to cause a problem (UNLESS you are a person who gets it).
 

Attachments

  • 499.png
    499.png
    17.9 KB · Views: 9
while I'm still trying/struggling to find a solution... this "499 issue" does not happen on any other sites the client goes on? it ONLY happens on this vhost.
To me, that says it's an issue related to my server, even though everything points to the client having the issue :(
 
Back
Top