Here is an example of what 401 could look like in the web servers access_log. In this example, 401 was returned when john.doe attempted to authenticate at example.com/auth.php.
10.15.112.57 - john.doe [10/Oct/2020:21:36:16 -0400] "GET /auth.php HTTP/1.1" 401 4153 130989 example.com +
Invalid username / password
Obviously, the most common reason for 401 to be returned is that an invalid username or password was used in the request.
In the most simple (and not very common) scenario, the client would have went directly to www.example.com/auth.php and auth.php resides on the web server itself. In this example, the request and response would look something like this.
Often, a request is referred. For example, the client may have done a Google search. In this example, the referred would contain www.google.com. The refer directive can be added to LogDirective so that the access_log contains the referer.
Requests are often routed from the web server onto some other system, such as another web server, an application server (e.g. JBoss, Tomcat, WebSphere), an access management system (e.g. SAML), and the list goes on. In turn, the next system could also pass the request onto other systems. The point being made here is that many other systems are often at play here after the web server processes the request. These backend systems tell the web server if the request is unauthenticated, so that the web server will log 401 in the access_log.