This concept (typically used as part of an attack) is often called "pivoting", as in "I used the server's request forwarding feature to pivot from the Internet to localhost". There's no way to "spoof" localhost traffic over TCP; TCP requires a valid source IP address to complete the handshake. On UDP, you might manage it if the application was listening on external interfaces but was rejecting any connection that doesn't come from the local host - this is different from only listening on the loopback interface, which is what you would normally do if you only wanted local traffic - but I've never heard of that approach being used, probably because it's a stupid way to configure a server.
There are a number of ways you can pivot a network connection to a local (internal) network, or to localhost (which is essentially an extra-small - one machine only - local network). Let's take a trivial, contrived example: the machine running the local-connections-only server is also running an open proxy server exposed to the Internet. You connect to the proxy, and tell it to connect you to 127.0.0.1 on the desired port. The proxy server sends out that request on your behalf, and connects to the restricted server. The proxy then relays your traffic to the restricted server, and its traffic back to you.
There are a number of less-contrived examples that may work. XML External Entity attacks are probably the most common, and can be used to make various kinds of requests, such as HTTP, HTTPS, FTP, and possibly others, to a host and port of your choice (relative to the vulnerable XML parser, which is usually in a web server, so requesting "localhost" in the XXE would make the web server connect to itself on the specified protocol on port). That won't usually get you interactive traffic, but is good for simple requests and can usually be made as often as desired (this can also be used to port-scan an internal network for certain kinds of servers). Anything that lets an external program have the server make an arbitrary request on the external user's behalf can be abused to send a request to the server's localhost-only services.
Another option that might sometimes be relevant is to use this sort of attack to gain privileges on a host after you have compromised it and gained arbitrary code execution in a low-privilege environment. Imagine, for example, a sandboxed web server. You compromise the server and drop a reverse shell on it, letting you run code within the server's sandbox. You then open a network connection to another service on the same server (but outside the webserver's sandbox) that is listening on localhost but is otherwise unauthenticated. If the sandbox doesn't restrict you from doing this and the target server exposes anything not visible from within the sandbox directly, you've just effectively gained additional privileges.