When managing and maintaining a website, there are a handful of HTTP status codes to be aware of. Some, such as the HTTP 499 error, can cause a timeout that interrupts your workflow. Therefore, you’ll need to ensure that your site is configured properly to avoid this issue.
Whether you’re seeing the HTTP 499 status code frequently or for the first time, it may indicate an issue with your website that needs to be addressed. The good news is that there are multiple steps you can take to resolve it.
Check Out Our Video Guide to Fixing the 499 Error
In this post, we’ll explain the HTTP 499 status code and what can cause the error. Then we’ll walk you through five potential solutions you can use to fix it. Let’s get started!
What the HTTP 499 Status Code Means
The HTTP 499 status code, also known as a “client closed request,” is a special case of the 502 Bad Gateway Error. It indicates that the client has closed the connection while the server is still processing the request.
HTTP 499 falls within the category of client-based errors. This means the issue is on the client side. Other common errors in this category include HTTP 400 Bad Request and HTTP 404 Not Found. With these errors, the problems are usually easy to define. However, HTTP 499 is more general.
The HTTP 499 error can happen on both Nginx and Apache servers. However, it is more common on Nginx servers because it was created by Nginx.
HTTP 499 is more common on Nginx because the server software handles client connections differently than Apache. With Nginx, each client connection is processed in a separate thread. Therefore, if one client connection takes a long time to process, it won’t slow down the other clients.
However, with Apache, all client connections are processed in the same thread. This can cause problems if one client connection takes a long time to process because it will slow down all other clients.
The HTTP 499 error can cause a timeout that interrupts your workflow- but with a little help from this guide, you can get right back on track 👩💻Click to Tweet
What Causes the HTTP 499 Error
Typically, the HTTP 499 error appears in Nginx logs. This can happen for several reasons, but most commonly, it’s due to either a browser timing out or a user canceling the request.
For example, a website may encounter an HTTP code 499 when it’s loaded with too much traffic. Alternatively, the error can happen when the request comes from algorithms that create issues within the site.
In some cases, this status code may also display when there is no response from the server, and the client has timed out waiting for a response. In these cases, it’s usually best to just try again later. However, if you are consistently getting this status code from a particular server, it may be worth investigating further to see if there is an overarching issue.
How To Fix the HTTP 499 Error (5 Potential Solutions)
Now that we understand more about the HTTP 499 error, let’s look at how to resolve it. Below are five potential solutions for the HTTP 499 status code!
1. Clear Your Browser Cache and Try Again
As we mentioned earlier, this error may be a temporary issue that can be resolved by simply trying to load the page again. It might be that your host or server is overloaded. Therefore, we recommend clearing your browser cache and trying again.
The process for clearing the cache will vary depending on your browser. If you’re using Google Chrome, you can navigate to the three vertical dots in the upper right-hand corner of the window, then go to More tools > Clear browsing data:
You’ll then be prompted to choose which data to clear from your browser cache:
When you’re done, reload your browser. You can also try using a different browser in the meantime. Then revisit your site to see whether the error message is still showing.
2. Disable Your Plugins and Extensions
Some users have reported that certain plugins cause the HTTP 499 status code error. Therefore, we recommend temporarily disabling your plugins to see if this resolves the issue.
You can do this by navigating to your Plugins screen in the WordPress dashboard, selecting all of them, then clicking on Deactivate > Apply from the bulk actions menu:
You can also connect to your site via a File Transfer Protocol (FTP) client or File Manager, then navigate to your plugins folder (wp_content > plugins). Right-click on the plugins folder and rename it to something such as “plugins_old.”
This will deactivate all of the plugins on your WordPress site. You can revisit your website to see whether the error message is still showing. If not, you can try activating your plugins one by one until you find the tool causing the issue.
3. Check Your Error Logs
When troubleshooting the HTTP 499 code, it’s essential to leverage your error logs. This approach will make it easier to narrow down the issue and determine whether it results from a specific plugin or tool.
If you’re not a Kinsta user, you can enable and view error logs by turning on WordPress debugging mode. However, if you’re a Kinsta user, you can quickly and easily see errors in the Log viewer from your MyKinsta dashboard:
You can also check your log files in Nginx (/var/log/nginx.error.log) and Apache (/var/log/apache2/error.log). Furthermore, Kinsta users can take advantage of our analytics tool to take a closer look at errors on your site. Then you can understand how often they’re occurring and whether the HTTP 499 error is an ongoing issue.
4. Use an Application Performance Monitoring (APM) Tool
When managing a website, it’s important to have reliable solutions for identifying and troubleshooting errors on your site. We recommend using an Application Performance Monitoring (APM) tool.
APM tools can help you narrow down which script or plugin may lead to various errors, such as HTTP 499. We include our Kinsta APM, as well as a variety of other DevKinsta tools, with all of our plans:
For example, your APM tool can help you collect valuable data and determine which applications are causing delays. Once enabled, you can use KinstaAPM to view the slowest transactions on your site, trace their timelines, and figure out the causes of issues. Our APM also provides insight into your PHP processes, MySQL queries, external HTTP requests, and more.
5. Contact Your Web Host and Request a Timeout Increase
As we’ve discussed, sometimes HTTP 499 errors can occur when a request is canceled because it’s taking too long. Some hosting providers use a ”kill script”.
In short, a kill script forces a request to be terminated after a certain amount of time. This script is often used in shared hosting environments to prevent long requests from impacting other sites.
If you’re a Kinsta user, this isn’t something you need to worry about. Each site hosted on our platform runs on an isolated software container that includes all resources and software. Everything is completely private, and none of your resources are shared, so we don’t run kill scripts.
However, when it comes to the HTTP 499 error, it’s important to note that the “client” may be a proxy, such as a Content Delivery Network (CDN) or load balancer. A load balancing service can act as a client to the Nginx server and proxy data between your server and users. This can cause a timeout that cancels the request to the Nginx server.
PHP timeouts happen if a process runs longer than the maximum execution time (max_execution_time) or max_input_time specified in your server’s PHP configuration. You may encounter timeouts if you have a busy website or scripts that need longer execution times. Therefore, it might be necessary to extend your timeout value.
Let’s say you have a request that is expected to take 20 seconds to complete. If you have an application with a timeout value of 10 seconds, the application will probably time out before completing the request. You’ll likely see the HTTP 499 status code in such an instance.
Therefore, it’s wise to check with your host about the values set on your server. At Kinsta, the default max_execution_time and max_input_time values are set to 300 seconds (5 minutes). The maximum PHP timeout values vary depending on your plan.
If necessary, you can reach out to your hosting provider to request a timeout increase. As a Kinsta user, you can open a ticket with our support team.
With help from this guide, you can ensure your site is properly configured to avoid seeing this error in the future. ✅ Here’s how… 🚀Click to Tweet
Summary
There are a wide variety of HTTP status codes to be aware of as a website owner. Some of the trickiest are client-based errors, such as the HTTP 499 code. The good news is that you can take a handful of steps to resolve this issue.
In this post, we discussed five potential solutions you can use to fix the HTTP 499 status code error. All of them are viable options; if one doesn’t work, another one should.
Do you want to troubleshoot and resolve issues in WordPress as painlessly as possible? Check out Kinsta hosting plans to learn how our APM tool and other solutions can streamline your website maintenance and management!
In my case, I was impatient and ended up misinterpreting the log.
In fact, the real problem was the communication between nginx and uwsgi, and not between the browser and nginx. If I had loaded the site in my browser and had waited long enough I would have gotten a «504 — Bad Gateway». But it took so long, that I kept trying stuff, and then refresh in the browser. So I never waited long enough to see the 504 error. When refreshing in the browser, that is when the previous request is closed, and Nginx writes that in the log as 499.
Elaboration
Here I will assume that the reader knows as little as I did when I started playing around.
My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.
My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.
1) uWSGI says, «I’m processing, just wait and you will soon get a response». nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.
2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.
I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.
So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.
So the conclusion is, that the problem was with uWGSI, which kept hanging («Wait a little longer, just a little longer, then I will have an answer for you…»).
How I fixed that problem, I don’t remember. I guess it could be caused by a lot of things.
Vault Forum
Welcome to Autodesk’s Vault Forums. Share your knowledge, ask questions, and explore popular Vault topics.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
-
Back to forum -
Previous -
Next
22085 Views, 3 Replies
12-20-2017
08:00 AM
Has anyone ever ran across this error message? I did a quick web search and no results about Vault. The interesting thing is it only occurs on this users machine and regardless of user (admin or otherwise) and also regardless of file. I was able to pull down the files on my machine without issue and we have the same AV product and definitions. I am having the user reboot in hopes making the computer wake up stupid will remedy the issue.
It is apparent this is a an AV issue but if anyone has any hints how to work around it other than disabling the AV I would appreciate input.
Thanks,
Rob Towne
Sr. Engineer/CAD Manager | A.L.P.
Inventor/Vault Professional/AutoCAD
- antivirus
-
Back to forum -
Previous -
Next
3 REPLIES 3
12-20-2017
10:34 AM
As information our IT department placed the Vault Server Netbios names and FQDN’s on the AV Whitelist in the AV product and that fixed the issue.
Thanks,
Rob Towne
Sr. Engineer/CAD Manager | A.L.P.
Inventor/Vault Professional/AutoCAD
12-12-2018
02:03 AM
I faced the same issue with a user having Kaspersky Antivirus which was blocking ajax requests from tag named as bank.
Antivirus(mainly Kaspersky) looks for specific words like BANK, etc in your web pages and block ajax calls or other server requests related to those keywords to protect your data. It does same with jquery files and does not allow them to run citing security issues.
Possible solutions — either remove those keywords like bank from the webpage or if it happens with a specific user/users then a browser console error is generated. It can be allowed by clicking on the browser’s console error on user end and enabling it from there.
03-18-2020
02:49 AM
I have a problem with my Avast antivirus. I use brave browser. but avast shield doesn’t turn on with it. from last few days, I have to use the browser without any security. Every time when I wanted to turn it on avast web shield won’t turn on. Don’t know whether it is the problem of the antivirus software or not. Give a solution to this problem.
-
Back to forum -
Previous -
Next
I’ve a one page checkout. When I click on ‘continue’ button after select the shipping method it redirects to dashboard page.
I’ve noticed that it print a ‘499 request forbidden by antivirus’ in the console, and I’ve noticed that this issue happens only in computers that have Kaspersky intalled.
I can’t give up all customers with Kaspersky installed. What to do?
Thanks Guys.
asked Feb 16, 2015 at 17:59
If someone visits any site with their firewall/AV settings set too high then Javascript won’t work. Do these same customers have a problem on larger sites like Walmart.com or Target.com? If so then it’s going to be up to them to lower their javascript scan settings if they want to be online.
answered Feb 16, 2015 at 18:02
seanbreedenseanbreeden
2,82417 silver badges23 bronze badges
Add your Magento site and all related domains (including files hosted elsewhere but included in your template) to the KAV trusted sites list.
See this link for help: http://support.kaspersky.com/5418 (Mostly applies to PURE and similar single-license versions of KAV. If you have Endpoint Security, you need to build a rule into your policy at the Administration Server level. I could walk you through this if you need help.)
Edit: It occurs to me just now that you may not be talking about users you can control, but random customers around the web. If that’s the case, you need to contact Kaspersky about why your site is on their blacklist and how to get it removed. I typically start here: http://support.kaspersky.com/virlab/helpdesk.html
answered Feb 16, 2015 at 18:03
ddavidnddavidn
4345 silver badges16 bronze badges
I’ve a one page checkout. When I click on ‘continue’ button after select the shipping method it redirects to dashboard page.
I’ve noticed that it print a ‘499 request forbidden by antivirus’ in the console, and I’ve noticed that this issue happens only in computers that have Kaspersky intalled.
I can’t give up all customers with Kaspersky installed. What to do?
Thanks Guys.
asked Feb 16, 2015 at 17:59
If someone visits any site with their firewall/AV settings set too high then Javascript won’t work. Do these same customers have a problem on larger sites like Walmart.com or Target.com? If so then it’s going to be up to them to lower their javascript scan settings if they want to be online.
answered Feb 16, 2015 at 18:02
seanbreedenseanbreeden
2,82417 silver badges23 bronze badges
Add your Magento site and all related domains (including files hosted elsewhere but included in your template) to the KAV trusted sites list.
See this link for help: http://support.kaspersky.com/5418 (Mostly applies to PURE and similar single-license versions of KAV. If you have Endpoint Security, you need to build a rule into your policy at the Administration Server level. I could walk you through this if you need help.)
Edit: It occurs to me just now that you may not be talking about users you can control, but random customers around the web. If that’s the case, you need to contact Kaspersky about why your site is on their blacklist and how to get it removed. I typically start here: http://support.kaspersky.com/virlab/helpdesk.html
answered Feb 16, 2015 at 18:03
ddavidnddavidn
4345 silver badges16 bronze badges
Один пользователь говорит, что я получаю сообщение об ошибке;
Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus) wentworth-miller-14015611293982427.jpg
После этого я также установил касперского и получил тот же код ошибки, в котором говорится, что этот сайт вреден для вашей системы, мой веб-сайт kimkimdir.tv.
Через несколько часов я обнаружил кое-что, может быть, важное, когда я захожу на свой веб-сайт с IP-адресом.
http://146.148.31.90:8080/
Проблем с антивирусом нет, что делать?
3 ответа
Попробуйте отключить функцию Анти-Баннер. кажется, антивирус блокирует некоторые определенные типы вызовов ajax.
4
Adeem
29 Июл 2015 в 16:52
Я столкнулся с той же проблемой, когда у пользователя был антивирус Касперского, который блокировал ajax-запросы от тега с именем bank. Антивирус (в основном Касперский) ищет определенные слова, такие как БАНК и т. д., на ваших веб-страницах и блокирует вызовы ajax или другие запросы сервера, связанные с этими ключевыми словами, для защиты ваших данных. Он делает то же самое с файлами jQuery и не позволяет им запускаться, ссылаясь на проблемы с безопасностью. Возможные решения: либо удалите такие ключевые слова, как банк, с веб-страницы, либо, если это происходит с определенным пользователем/пользователями, генерируется ошибка консоли браузера. Это можно разрешить, щелкнув ошибку консоли браузера на стороне пользователя и включив ее оттуда.
3
Eric Aya
12 Дек 2018 в 13:12
Kaspersky предлагает бесплатный онлайн-сервис для сканирования небольших файлов (я думаю, до 5 МБ). Используйте его и отсканируйте файл, который вы пытаетесь обслуживать, это даст вам больше информации.
Я очень сомневаюсь, что это имеет какое-либо отношение к node.js, поэтому я бы начал с проверки фактического файла с помощью этого антивируса.
-1
alandarev
11 Июн 2014 в 16:43
In my case, I was impatient and ended up misinterpreting the log.
In fact, the real problem was the communication between nginx and uwsgi, and not between the browser and nginx. If I had loaded the site in my browser and had waited long enough I would have gotten a «504 — Bad Gateway». But it took so long, that I kept trying stuff, and then refresh in the browser. So I never waited long enough to see the 504 error. When refreshing in the browser, that is when the previous request is closed, and Nginx writes that in the log as 499.
Elaboration
Here I will assume that the reader knows as little as I did when I started playing around.
My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.
My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.
1) uWSGI says, «I’m processing, just wait and you will soon get a response». nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.
2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.
I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.
So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.
So the conclusion is, that the problem was with uWGSI, which kept hanging («Wait a little longer, just a little longer, then I will have an answer for you…»).
How I fixed that problem, I don’t remember. I guess it could be caused by a lot of things.
Kibana Version : 7.15.1
End user using Chrome Version 95.0.4638.69 (Build officiel) (64 bits)
End user using Kaspesky Antivirus
Getting every time following Error blocking Kibana UI
legacy_light_theme.css:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
dashboards#/list?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now)):282 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self' https://gc.kis.v2.scr.kaspersky-labs.com wss://gc.kis.v2.scr.kaspersky-labs.com". Either the 'unsafe-inline' keyword, a hash ('sha256-P5polb1UreUSOe5V/Pv7tc+yeZuJXiOi/3fqhGsU7BE='), or a nonce ('nonce-...') is required to enable inline execution.
bootstrap.js:42 ^ A single error about an inline script not firing due to content security policy is expected!
:5601/api/banners/info:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
:5601/internal/security_oss/app_state:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
:5601/internal/security/me:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
:5601/api/saved_objects/_bulk_get:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
:5601/api/licensing/info:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
:5601/internal/global_search/searchable_types:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
:5601/internal/spaces/_active_space:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
:5601/internal/security/me:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
:5601/api/licensing/info:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
:5601/api/licensing/info:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
kbn-ui-shared-deps.js:21 Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.
Arguments:
[0] _isAMomentObject: true, _isUTC: false, _useUTC: false, _l: undefined, _i: now-7d/d, _f: undefined, _strict: undefined, _locale: [object Object]
Error
at Function.createFromInputFallback (https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:149088)
at https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:169264
at https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:169315
at Ct (https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:169627)
at xt (https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:169888)
at wt (https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:169970)
at i (https://***:5601/44185/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:21:146010)
at convertTimeToUTCString (https://***:5601/44185/bundles/plugin/dashboard/kibana/dashboard.chunk.1.js:9:80584)
at areTimesEqual (https://***:5601/44185/bundles/plugin/dashboard/kibana/dashboard.chunk.1.js:9:80724)
at t._next (https://***:5601/44185/bundles/plugin/dashboard/kibana/dashboard.chunk.1.js:9:136447)
T @ kbn-ui-shared-deps.js:21
:5601/api/saved_objects/_bulk_get:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
14kbn-ui-shared-deps.js:283 Uncaught Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
core.entry.js:13 Detected an unhandled Promise rejection.
Error: Request has been forbidden by antivirus
core.entry.js:6 Uncaught (in promise) Error: Request has been forbidden by antivirus
at fetch_Fetch.fetchResponse (core.entry.js:6)
at async core.entry.js:6
at async core.entry.js:6
:5601/internal/global_search/find:1 Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
Recommended Posts
- Author
-
- Share
Link to comment
Share on other sites
-
- Share
Link to comment
Share on other sites
- Author
-
- Share
Анти-баннер отключен, как и было сказано выше.
Link to comment
Share on other sites
-
- Share
у меня вот так отображается
Link to comment
Share on other sites
- Author
-
- Share
В сайдбаре должна быть реклама которая крутится через Adfox. Она не показывается у вас тоже. Посмотрите, в файрбаг, какие ошибки есть.
Link to comment
Share on other sites
-
- Share
это что ли?
Link to comment
Share on other sites
- Author
-
- Share
Да, а что показыапнт у вас файрбаг?
Link to comment
Share on other sites
-
- Share
Я не знаю, что такое файрбаг и где смотреть, что он показывает
Link to comment
Share on other sites
- Author
-
- Share
При нахождении на данной странице, нажмите f12 (в хроме) вкладка console. Покажите срин, есть ли ошибки?
Link to comment
Share on other sites
-
- Share
какие-то ошибки есть
Link to comment
Share on other sites
- Author
-
- Share
Link to comment
Share on other sites
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now
Добрый день
При работе на Open Server, абсолютно все сайты выдают это окно
Нажимаем «перейти на сайт» — всё работает от силы полчаса / час .
Потом сайт ломается, в девтулс куча сообщений о якобы новых заражениях или хз что-то связанное с антивирусом
Ошибка 499
to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus)
Через n кол-во обновлений страницы, опять появляется это окно
Переходим на сайт
И всё работает норм, следующие полчаса час
Добавление сайта в список доверенных сайтов не помогло, хотя это и геморно каждый раз добавлять сайт туда
———————————————————-
Как программиста меня очень бесит такая работа антивируса
Вирусов нет, опасности нет, но это ****ное окно постоянно мешает
Во время работы что-то не работает на сайте, и ты думаешь что ошибка в коде
Но нет ***** это опять ваш антивирус мозги ****
Работать невозможно
Как его убрать ******* раз и навсегда???
one user says that İ’m getting error;
Failed to load resource: the server responded with a status of 499 (Request has been forbidden by antivirus) wentworth-miller-14015611293982427.jpg
After that i also installed kaspersky and i got same error code it says that this website harmful for your system , my web site is kimkimdir.tv.
After hours , i found something maybe important , when i enter my web site with ip address
http://146.148.31.90:8080/
There is no any anti-virus problem , what should i do ?
asked Jun 11, 2014 at 12:38
ErdiErdi
1,8123 gold badges21 silver badges30 bronze badges
3
Try disabling Anti Banner feature. it seems antivirus is blocking some specific types of ajax calls.
answered Jul 29, 2015 at 13:52
AdeemAdeem
1,2761 gold badge16 silver badges30 bronze badges
I faced the same issue with a user having Kaspersky Antivirus which was blocking ajax requests from tag named as bank. Antivirus (mainly Kaspersky) looks for specific words like BANK, etc in your web pages and block ajax calls or other server requests related to those keywords to protect your data. It does same with jQuery files and does not allow them to run citing security issues. Possible solutions — either remove those keywords like bank from the webpage or if it happens with a specific user/users then a browser console error is generated. It can be allowed by clicking on the browser’s console error on user end and enabling it from there.
Eric Aya
69.5k35 gold badges181 silver badges252 bronze badges
answered Dec 12, 2018 at 10:12
Kaspersky offers free online service to scan small files (up to 5 MB I believe). Use it, and scan the file you are trying to serve, that will give you more information.
I highly doubt it has anything to do with node.js, thus I would start from verifying the actual file against that antivirus.
answered Jun 11, 2014 at 12:43
alandarevalandarev
8,3192 gold badges34 silver badges43 bronze badges
5
Я столкнулся с той же проблемой с пользователем, имеющим Антивирус Касперского, который блокировал запросы ajax от тега, названного банком. Антивирус (в основном Kaspersky) ищет на ваших веб-страницах определенные слова, такие как BANK и т. Д., И блокирует вызовы ajax или другие запросы сервера, связанные с этими ключевыми словами, для защиты ваших данных. То же самое происходит с файлами jQuery и не позволяет им работать, ссылаясь на проблемы безопасности. Возможные решения — либо удалите такие ключевые слова, как банк, с веб-страницы, либо, если это происходит с конкретным пользователем / пользователями, возникает ошибка консоли браузера. Это можно разрешить, нажав на ошибку консоли браузера на стороне пользователя и включив ее оттуда.
2018-12-12 10:12