1.) Yes: if you specify a local port forwarding (option -L in OpenSSH), your SSH client will act as a proxy that forwards the connection that's incoming to a specified local port/socket onto a specified target at the remote end of the SSH connection. And if you specify a remote port forwarding (option -R in OpenSSH), the sshd daemon at the remote end will act as a proxy that forwards connections incoming to a a specified remote port/socket to the specified target on the local side of the SSH connection.
In both cases, both the SSH client and the sshd daemon work together to implement the functionality, but whichever is accepting the incoming connections could be said to act as a proxy for the actual service on the opposite side of the SSH connection.
2.) Also yes, but then the request must be specified using a protocol that is understood by SSH. A dynamic port forwarding (option -D in OpenSSH) does just that, supporting the SOCKS4 and SOCKS5 protocols.
For example:
You might have a server room full of equipment with web-based remote console functionality. Since those aren't always updateable to the latest TLS standards, you've connected them to a strictly local network segment that is accessible through a particular network administrators' workstation only. This workstation has two NICs: one to the regular network, and another to the remote console segment, but it is intentionally configured to not act as a router. Of course the network administrators' workstation runs Linux :-)
You're on a well-earned vacation, when the big boss calls and tells you that the your stand-in is sick from food poisoning and some old router in the server room needs to be rebooted ASAP. You're hundreds of miles away from the server room. Through the company VPN, you can access the network administrators' workstation remotely, but you know from experience that using X11 forwarding to run a remote browser is painfully slow. So, what do you do?
<connect VPN>
laptop$ ssh -D 1234 tim@netadmin_workstation.company.intra
netadmin_workstation$
Now, as long as that SSH connection is up, you can fire up a local browser, configure it to use a SOCKS proxy located at localhost:1234 and all the outgoing network connections from that browser will go out through the SSH connection to the netadmins' workstation, and from there on as regular TCP connections to whatever address specified in the browser. Effectively, your browser's network connections will now seem to originate from the netadmins' workstation, while the browser (and any associated Java applets) will still be run fully locally, with minimum latency.
And so you can access the Java-based web GUI of that pesky old router remotely with a somewhat tolerable level of latency...
(If you're using Firefox, you may want to set an about:config option network.proxy.socks_remote_dns to True, in order to have the browser also forward any DNS requests through the SOCKS proxy connection, so you can use the DNS resolution of the netadmins' workstation too.)
(Disclaimer: any resemblance of the above description to any particular series of real-life events is entirely coincidental. Something very much like it has probably happened many, many times in a lot of different places all over the world.)
