Internet browsing appears in the gateway proxy's log. A website on the office LAN does not. Before changing the URL filter, establish whether the LAN request ever reached the gateway.

For a directly connected IPv4 destination, the client can resolve the destination's link-layer address and send to it on the local segment. Its default gateway is not automatically on that path. A transparent interception rule on the gateway cannot redirect packets the gateway never receives.

For example, two hosts in the same on-link subnet may exchange traffic through a switch while the proxy machine is attached to another switch port. Merely being on that LAN does not make the proxy the forwarding point.

Choose the intended path

An explicit proxy setting can send the participating application's request to the proxy even when the target website is local. Check bypass rules and PAC decisions too: they may deliberately choose DIRECT for private names or addresses.

If interception is required, the network must actually place the interception point in the path; on a Linux gateway, distinguish local and forwarded packet paths. Routed subnet separation or a deliberately inline bridge can do that in suitable designs, but each changes forwarding and failure behavior. A bridge elsewhere on the LAN is not automatically inline.

Keep the application protocol requirement separate. Even after traffic crosses the box, the listener must support the interception mode. Moving the packets is not permission to decrypt HTTPS or a guarantee that an ordinary SOCKS port can accept them.

Record the client's selected route, the local segment and the actual forwarding device. A missing proxy log can be a correct description of the topology rather than a logging failure.

འབྲེལ་བའི་རྩོམ་ཡིག