How to Fix 400 Bad Request Chrome Error on Linux

You may from time to time receive a message that reads 400 Bad Request while trying to browse the Web with Chrome on Linux. While this error is by no means restricted to this browser or even this operating system, many users report that it’s a major problem when running this kind of configuration. The 400 error is part of the same standard HTTP status code list that the more common 403 Forbidden and 404 Not Found errors that most users are used to.

Fortunately, the fix is normally very easy. Check that you’re connected to the Internet and make sure that you haven’t misspelled the URL that you were trying to visit in Chrome. If you have Mozilla Firefox installed as it is on many modern Linux distributions, then try visiting a page that was giving you the 400 Bad Request Chrome error. Should you be able to view it in Firefox and the other tricks didn’t cure the problem, the you probably have a corrupted cookie. You might also have a proxy issue.

Method 1: Clearing Cookies to Fix the 400 Bad Request Error in Chrome

Cookies can become corrupt or out of date much like any other asset can over time. Click on the Control menu next to the URL address and select Settings. Scroll down and you might have to click on  “Show advanced settings…” if the full page doesn’t come up right away.

Scroll down until you see a button marked “Clear browsing data” and then click on it. Choose “Obilterate the following items from: the beginning of time” and then make sure that “Cookies and other site and plugin data” is selected. Remember that everything else with a check in the box next to it will get cleared as well. You might want to uncheck everything else, but if you want a good cleaning then make sure to click everything besides Passwords and Autofill form data. If you don’t mind loosing saved passwords, then you can even clean this out. We ran it on a test machine that didn’t have anything really saved, but more than likely you’ll have something you want to preserve. If you clear out everything but saved passwords and form data, then you’ll loose your logins but be able to immediately log right back in again.

Click Clear browsing data once you’re sure you have only the right check boxes selected, wait a moment and then try to navigate to a site that was giving you trouble. You should find this corrected the issue. If the vast majority of sites load correctly at this point but you’re still having problems with one or two, then you may choose to simply wait a while then try again later. It could be that there’s something wrong with the resource, even though the 400 error is generally caused by a malformed browser request.

Method 2: Checking System Proxy Settings

Chrome under GNU/Linux doesn’t permit you to configure them individually the way that Firefox does, but you might find that you’ve configured it with a command line utility or something else. The first method involves less playing around and generally fixes it on the vast majority of systems tests. You can still check how Chrome handles system proxy settings though. Click on the Control menu and head to Settings once again. Just to be safe, scroll down until you see the word Network and click on “Change proxy settings…”

On the off chance that you actually do get to configure options, then make sure that the “Use system proxy settings” box is checked and then try refreshing a page. Most likely, though, you’ve received a message about how you had a problem launching your system configuration. It’s safe to ignore this. Close the tab by clicking on the X button or push Ctrl+W. You’ll probably want to try clearing out cookies again, then you’ll want to restart Chrome to see if it works right now. If not, then you should probably restart your system if you’re absolutely sure that you’re connected to the Internet. You should be all set at this point even in the most irregular of situations. While firewalls can technically cause this type of problem too, you probably would have seen that as an issue in every browser that you were using by that point and therefore ruled that out.

ABOUT THE AUTHOR

Kevin Arrows


Kevin Arrows is a highly experienced and knowledgeable technology specialist with over a decade of industry experience. He holds a Microsoft Certified Technology Specialist (MCTS) certification and has a deep passion for staying up-to-date on the latest tech developments. Kevin has written extensively on a wide range of tech-related topics, showcasing his expertise and knowledge in areas such as software development, cybersecurity, and cloud computing. His contributions to the tech field have been widely recognized and respected by his peers, and he is highly regarded for his ability to explain complex technical concepts in a clear and concise manner.