DEV Community: tuanha

401 Unauthorized Error: Causes and Solutions

tuanha — Fri, 05 Jun 2026 13:55:26 +0000

Are you trying to access a website or call an API, only to be suddenly met with a 401 Unauthorized error? This error indicates that the server has rejected the authentication credentials you provided, or that you failed to provide any credentials at all.

In this article, I will explain what a 401 error is, list the most common causes, and guide you through four ways to resolve it—ranging from simple fixes to more advanced troubleshooting. Whether you are a regular user or a website administrator, you will find the right solution here.

What is the 401 Unauthorized Error?

The 401 error is an HTTP status code in the 4xx category (client-side error). When a server returns a 401 code, it is essentially saying: “I need you to authenticate before I can grant access to this resource, but the information you provided is either invalid or missing.”

It is important to distinguish this: 401 relates to authentication—the server does not yet know who you are. This is fundamentally different from a 500 Internal Server Error, which is a server-side issue.

Although the official name is “Unauthorized,” its actual meaning is closer to “Unauthenticated.” Put simply, the server is asking: “Who are you? Please prove it.”

When a browser receives a 401 response, the server also includes a WWW-Authenticate header, which indicates the authentication method it accepts. Examples include Basic Auth (username/password), Bearer Token (used for APIs), or Digest Auth. The browser uses this header to trigger a login popup, or an application will know it needs to resend the request with the correct credentials.

You may encounter the 401 error in various forms, depending on the server and browser:

401 Unauthorized
HTTP Error 401
Authorization Required
Access Denied

Regardless of how it is displayed, they all mean the same thing: the server requires you to authenticate first.

Distinguishing 401 vs. 403 Errors

Many people confuse the 401 error with the 403 Forbidden error. The difference is as follows:

401 Unauthorized: The server does not know who you are. You need to log in or provide valid authentication credentials. Once you have authenticated correctly, you will be granted access.

403 Forbidden: The server knows who you are, but you do not have permission to access that specific resource. Logging in again will not help; you must contact the administrator to be granted the necessary permissions.

In simple terms: 401 means “not logged in,” while 403 means “logged in, but lack sufficient permissions.” Since the solutions for these are completely different, always identify the error correctly before attempting to fix it.

5 Common Causes of the 401 Error

1.Incorrect Login Credentials

The simplest cause is entering an incorrect username or password. This could be due to a typo, having Caps Lock enabled, or using an outdated password that has since been changed. This is frequently encountered when accessing WordPress admin pages (/wp-admin), cPanel, or other systems that require authentication.

Additionally, if you are using a password manager, it is possible that it is automatically filling in an outdated password saved previously. Always double-check the auto-filled information before clicking “Login.”

2.Expired Session

Most websites set an expiration time for each login session. If you leave your browser tab idle for too long, the session will expire. At this point, any subsequent requests will be rejected by the server with a 401 status code.

For example, WordPress defaults to a session duration of approximately 48 hours (or 14 days if you check the “Remember Me” box). For banking or financial applications, the session timeout is typically only 5 to 15 minutes for security reasons. Logging in again is the quickest way to resolve this.

3.Directory Protection with .htpasswd

On Apache servers, administrators can use an .htaccess file combined with an .htpasswd file to require authentication when accessing a specific directory. If you attempt to access a URL within that directory without entering the correct credentials, the server will return a 401 error.

# Example of .htaccess configuration for directory protection
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/user/.htpasswd
Require valid-user

The configuration above requires all visitors to enter a username and password. If the .htpasswd file is corrupted, the AuthUserFile path is incorrect, or the password hash within the file is improperly formatted, the server will return a 401 error to everyone, even if they enter the correct credentials.

On Nginx, a similar mechanism is used via the auth_basic and auth_basic_user_file directives. The principle is the same; only the configuration syntax differs.

4.Invalid or Expired API Token
For applications using REST APIs, a 401 error typically occurs when the access token has expired, been revoked, or is sent with an incorrect format in the Authorization header. This scenario is common when working with the WordPress REST API, third-party services, or mobile apps communicating with a backend API.

# Example of an API request with a missing or incorrect token
curl -H "Authorization: Bearer expired_token_here" https://api.example.com/data
# Server returns:
# HTTP/1.1 401 Unauthorized
# {"error": "invalid_token", "message": "Token has expired"}

Readmore :
https://haduymusic.com/website-knowledge/401-unauthorized-error-causes-and-solutions/

High VPS CPU Usage (100%): Causes and Fixes

tuanha — Thu, 04 Jun 2026 13:50:18 +0000

When your VPS CPU spikes to 100%, the first symptom is usually a sluggish SSH connection, website timeouts, and even simple commands like ls can lag for several seconds. This situation is very common with VPS hosting, especially when running WordPress or high-traffic web applications.

The problem is that many administrators immediately think of upgrading their VPS the moment they see 100% CPU usage. In reality, there are many different underlying causes—ranging from heavy MySQL queries and misconfigured PHP-FPM to hidden malware. Understanding the root cause will help you fix the issue properly instead of throwing money out the window.

Checking the Current CPU Status

The first step is to see exactly where your VPS is bottlenecked. These three commands will give you a quick overview:

Checking the Load Average with uptime

uptime

Example Output :

12:34:56 up 5 days, 2:15, 2 users, load average: 3.45, 2.89, 1.67

Load average represents the average number of processes waiting for the CPU over the last 1, 5, and 15 minutes. If your VPS has 2 CPU cores and the load average is above 2.0, it is a clear sign of an overload. In the example above, a load average of 3.45 on a 2-core VPS means the CPU is heavily bottlenecked.

💡 Tip: Load average > number of CPU cores = VPS is overloaded, immediate action required

Viewing Real-Time Statistics with the top Command

top

Example Output:

top - 12:35:21 up 5 days, 2:15, 2 users, load average: 3.21, 2.95, 1.89
Tasks: 127 total, 4 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 85.3 us, 12.1 sy, 0.0 ni, 2.1 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 2048.0 total, 156.4 free, 1654.2 used, 237.4 buff/cache
MiB Swap: 1024.0 total, 890.2 free, 133.8 used. 231.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3429 mysql     20   0   1.2g   456m    12m S  67.3  22.9   8:45.67 mysqld
 1847 www-data  20   0   456m    89m     8m R  18.7   4.5   2:34.12 php-fpm
 1923 www-data  20   0   421m    76m     7m S  12.1   3.8   1:56.34 php-fpm
  982 nginx     20   0   128m    24m     6m S   2.3   1.2   0:45.11 nginx

The %Cpu(s) line shows the CPU breakdown:

us (user): 85.3% – User-space processes (MySQL, PHP, Apache…)
sy (system): 12.1% – Kernel/system processes
id (idle): 2.1% – Idle CPU (the lower this is, the more alarming)
wa (wait): 0.5% – Waiting for disk I/O
st (steal): 0.0% – Steal time (CPU time “stolen” from your VPS by the physical host)
A Visual Interface with htop

htop

htop offers a much cleaner, color-coded interface:

Green: User processes (normal activity)
Red: System/kernel processes
Gray: Waiting for I/O (disk, network)
Cyan: Steal time (a sign that the VPS host is oversold)
Blue: Low priority processes
⚠️ Note: If you see a lot of red or cyan, it is a sign that you need to investigate further.

Distinguishing Between Different Types of CPU Load

Not all 100% CPU scenarios are created equal. By looking closely at the %Cpu(s) line in the top command, you can pinpoint the primary culprit:

High %us (>70%) – User-Space Applications
This is the most common scenario. The CPU is being heavily consumed by applications running in user-space, such as MySQL, PHP-FPM, Apache, Nginx, or Node.js.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so     bi     bo   in   cs us sy id wa st
 6  0      0 512000  85532 890140    0    0      2      8   85  156 78 15  7  0  0
 5  1      0 511800  85532 890144    0    0      0      4   92  189 82 12  6  0  0

Symptoms:

High r (6, 5): Multiple processes are actively waiting for CPU cycles.
High us + sy (78+15=93%, 82+12=94%): The CPU is working under extreme load.
Low id (7%, 6%): The CPU has virtually zero idle time to rest.
Low wa (0%): No disk or network I/O bottlenecks are present.
Solution: Optimize your applications, tune your database queries, or adjust service configurations.

High %sy (>30%) – System/Kernel Space
The CPU is being heavily consumed by the operating system kernel, usually due to heavy network I/O, excessive context switching, or driver-related issues.

Symptoms:

No single user-space process shows abnormally high CPU usage.
Massive spikes in network traffic (monitored via iotop or iftop).
High rate of context switches (monitored via vmstat).
Solution: Check network traffic, tune kernel parameters, or contact your VPS provider.

High %wa (>20%) – I/O Wait
The CPU is sitting idle while waiting for disk or network I/O operations to complete. This is not an actual CPU performance issue, but rather a storage bottleneck.

iotop -ao  # View which processes are reading/writing the most to the disk

Example Output :

Total DISK READ:  125.67 M/s | Total DISK WRITE:  234.12 M/s
  PID USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
 3429 mysql     89.23 M/s   156.78 M/s   0.00 % 67.23 % mysqld
 2341 root      23.45 M/s    78.90 M/s   0.00 % 23.12 % rsync

ℹ️ If you see a high %wa, refer to the guide on dealing with high Disk I/O for specific troubleshooting steps.

High %st (>5%) – Steal Time
Your CPU cycles are being “stolen” by the physical host to serve other virtual machines. This is a telltale sign of an oversold provider or a “noisy neighbor” on the same hardware.

🚫 Warning: If steal time is above 10%, contact support immediately—this is an infrastructure-level issue.

Finding the Process Hogging the CPU

Once you understand the type of load, the next step is to pinpoint exactly which process is “eating” your CPU.

Using the ps Command to Sort by CPU Usage

ps aux --sort=-%cpu | head -15

Example Output :

USER       PID %CPU %MEM    VSZ    RSS TTY      STAT START   TIME COMMAND
mysql     3429 67.3 22.9 1234567 456789 ?      Sl   10:23   8:45 /usr/sbin/mysqld
www-data  1847 18.7  4.5  456789  89012 ?      S    09:15   2:34 php-fpm: pool www
www-data  1923 12.1  3.8  421345  76543 ?      S    09:18   1:56 php-fpm: pool www
www-data  2156  8.9  3.2  398765  65432 ?      S    09:45   1:23 php-fpm: pool www
root      2341  6.7  1.2  234567  23456 ?      D    11:30   0:45 rsync -av /backup/

Reference :
https://haduymusic.com/server-administration/high-vps-cpu-usage-100-causes-and-fixes/