No, its not fixed, you can even consider it a problem. But Valve made the game this way. Not to make it more realistic but to compensate for the lage with the help of interpolation by its last know postion and coordinates.
TS, i love the teamplay style, but nowadays only ts_lobby is ran except on the trickshot server. Roleplay is crap.
Valve's explenation of the hitboxes:
Lag Compensation
Let's say a player shoots at a target at client time 10.5. The firing information is packed into a user command and sent to the server. While the packet is on its way through the network, the server continues to simulate the world, and the target might have moved to a different position. The user commands arrives at server time 10.6 and the server wouldn't detect the hit, even though the player has aimed exactly at the target. This error is corrected by the server-side lag compensation (sv_unlag 1)
The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed:
Command Execution Time = Current Server Time - Client Latency - Client View Interpolation
Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes:
This screenshot was taken on a listen server with 200 milliseconds of lag (using net_fakelag), right after the server confirmed the hit. The red hitbox shows the target position on the client where it was 100 milliseconds ago. Since then, the target continued to move to the left while the user command was traveling to the server. After the user command arrived, the server restored the target position (blue hitbox) based on the estimated command execution time. The server traces the shot and confirms the hit (the client sees blood effects). Client and server hitboxes don't exactly match because of small precision errors in time measurement. Even a small difference of a few milliseconds can cause an error of several inches for fast-moving objects. Multiplayer hit detection is not pixel perfect and has known precision limitations based on the tickrate and the speed of moving objects. Increasing the tickrate does improve the precision of hit detection, but also requires more CPU, memory, and bandwidth capacity for server and clients.
The question arises, why is hit detection so complicated on the server? Doing the back tracking of player positions and dealing with precision errors while hit detection could be done client-side way easier and with pixel precision. The client would just tell the server with a "hit" message what player has been hit and where. We can't allow that simply because a game server can't trust the clients on such important decisions. Even if the client is "clean" and protected by VAC (Valve-Anti-Cheat), the packets could be still modified on a 3rd machine while routed to the game server. These "cheat proxies" could inject "hit" messages into the network packet without being detected by VAC (a "man-in-the-middle" attack).
Network latencies and lag compensation can creates paradoxes that seem illogical compared to the real world. For example, you can be hit by an attacker you can't even see anymore because you already took cover. What happened is that the server moved your player hitboxes back in time, where you were still exposed to your attacker. This inconsistency problem can't be solved in general because of the relative slow packet speeds. In the real world, you don't notice this problem because light (the packets) travels so fast and you and everybody around you see the same world as it is right now.Source:
http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html