I hear both terms used in either direction. It can be somewhat confusing!
The HTTP spec indicates the requests are "downstream" and dependencies are "upstream" [1]
nginx indicates the opposite [2], even naming modules based on "upstream" being the direction of dependencies.
It may seem trivial, but I get a twinge in the back of my neck every time I hear one over the other; I believe others may have a similar experience. Perhaps the considerable knowledge and experience of the HN community can help clear this up?
Simple example:
Client -> Proxy -> Load Balancer -> Gateway -> Application Server -> Database
<- <- <- <- <-
On the one hand, it just seems natural that "upstream" refers to the inbound request being sent from one system to another. It takes effort (connection pooling, throttling, retries, etc.) to make a request to an (upstream) dependency, just as it takes effort to swim upstream. The response is (usually) easy... just return it... hence, "downstream". Recall the usual meaning of "upload" and "download". Upstream seems to make sense when talking about processing/effort.
But conversely, an individual client request is like a drop of water, that feeds into a trickle (proxy), that moves through the larger load balancer, etc. Certainly, the application server's database is most likely much larger than the client. So, the size of the stream (usually) gets larger the deeper into the stack a request goes. Downstream seems to make sense when talking about data size/volume.
[1] https://datatracker.ietf.org/doc/html/rfc7230#section-2.3
[2] https://nginx.org/en/docs/http/ngx_http_upstream_module.html
That said, I think I tend to use "upstream" in a similar sense to how package maintainers talk about packages: "upstream" is the source (where the thing originally came from) and "downstream" is the sink (where I will send it to). This implies that "upstream" for a request is "downstream" for a response, and vice versa. I don't know if that's necessarily correct usage, but that's how I've done it.