Let’s list down the type of requests handled by the Internet computer IC and go through the paths taken by the requests.
Invariant: canisters ultimately understand only CBOR[1] encoded requests. Talking to them using any other protocol requires marshaling and unmarshaling to and from that protocol Ex. http<>cbor
Types of requests
1. CBOR encoded requests. (No ICX proxy)
These requests interact with the canisters by sending an HTTP POST request to REST endpoints of the from
http://<canisterid>.ic0.app/canisterid/api/v2/[*call | query*]
These requests originate from stand-alone NON-browser clients like dfx & quill which use the underlying agent-rs or agent-js libraries. Handling these requests is relatively simple. A HTTP put request with CBOR encoded data a request body is sent to the closet boundary nodes resolved by ic0.app. The boundary node forwards the message to the destination replica. Thus in this path, there is NO need for icx-proxy to be invoked by the boundary node routing infra as the request/response is already in the IC native CBOR format.
2. Non-CBOR encoded request. (ICX proxy or service worker path)
You can interact with canisters using any legacy protocol. One of the protocols is HTTP/s. HTTP request looks like text blocks of the form
GET /index.html HTTP/1.1
Host: www.<canisterid>.ic0.app/
Such HTTP requests originate from browsers. Now the HTTP request above has to be converted to CBOR before sending it to the replica (see invariant above), and the CBOR response has to be marshaled back into the HTTP response on its way back to the browser. These non-CBOR requests are further categorized into 2 types.
2.a Non-CBOR plain request Example https://canisterid.ic0.app/index.html
These plain non-CBOR (aka HTTP requests) are intercepted in the browser itself by the service worker. The service worker converts them CBOR and then the CBOR request is handed to the boundary nodes. After this, the path for the request is the same as CBOR requests.
2.b Non-CBOR raw request Example https://canisterid.raw.ic0.app/index.html
These non-CBOR requests bypass the service worker and onto the boundary node as HTTP requests. Here the boundary node handles the CBOR<>HTTP conversion by employing a locally run icx-proxy. That is each boundary node is locally running a icx-proxy.
Other interesting interactions.
IC local development uses an icx-proxy that routes requests to the locally run replica. Here locally mean the developers laptop 
@skilesare scenario - Any of the above-mentioned paths can be augmented by placing yet another icx-proxy in front of the boundary nodes.
We are constantly trying to simplify the paths, but are limited by the past decision which dictate certain paths be maintained for backward compatibility. Some of the raw interactions are also because of certificate verification limitations like lack of streaming in the service worker and memory restrictions in the browser that prohibit certificate checks for big sized assets