[Feature request] SOCKS Proxy Support for sslocal

Summary

Currently, sslocal does not natively support forwarding traffic through another SOCKS proxy. I am requesting a new feature and config option that allows sslocal to route its traffic through a specified SOCKS5 proxy.

Use Case

The use case involves chaining sslocal traffic through another SOCKS proxy. For example, if a local SOCKS proxy is exposed on 127.0.0.1:1234 and only this socks proxy allowed to connect to the internet, I would like to configure sslocal to route its traffic through this proxy natively (without relying on other package/binary).

This feature is especially useful in scenarios like SSH tunneling (ssh -D) to a VPS, where sslocal could utilize the local SSH SOCKS proxy for further forwarding.

Workarounds Tried

1. local-tunnel

openbsd# sslocal -v --protocol tunnel  -b "127.0.0.1:1080" -f "127.0.0.1:1234" ...
2025-05-27T04:59:22.080355343-04:00 DEBUG main ThreadId(01) shadowsocks_rust::sys: rlimit NOFILE adjusted rlimit { rlim_cur: 1024, rlim_max: 1024 }    
2025-05-27T04:59:22.080621565-04:00  INFO main ThreadId(01) shadowsocks_rust::service::local: shadowsocks local 1.23.4 build 2025-05-27T08:01:34.889851441+00:00    
2025-05-27T04:59:22.081944065-04:00  INFO tokio-runtime-worker ThreadId(02) shadowsocks_service::local::tunnel::tcprelay: shadowsocks TCP tunnel listening on 127.0.0.1:1080

But the service that try to get through don't succeed:

socks_handshake: TCP port read failed on recv(): Operation now in progress (errno=36)

1. External binary/package

I attempted to use socksify (similar to proxychains on BSD) to achieve this, but it results in the following error:

openbsd# socksify sslocal -v ....  
2025-05-27T04:44:45.61702666-04:00 DEBUG main ThreadId(01) shadowsocks_rust::sys: rlimit NOFILE adjusted rlimit { rlim_cur: 1024, rlim_max: 1024 }    
2025-05-27T04:44:45.617247157-04:00  INFO main ThreadId(01) shadowsocks_rust::service::local: shadowsocks local 1.23.4 build 2025-05-27T08:01:34.889851441+00:00    

thread 'main' panicked at /home/shadowsocks-rust/src/service/local.rs:1002:50:  
create local: Os { code: 61, kind: ConnectionRefused, message: "Connection refused" }  
stack backtrace:  
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.  
Abort trap

Note: I also got sslocal to start but probably due to socksify hooking, sslocal start listening on 0.0.0.0:XXXX where “XXXX” is a random port. It doesn't seem to apply the config file.

Proposed Solution

Add native support for specifying a SOCKS proxy in sslocal's configuration or command-line arguments.

For example:

sslocal --socks-proxy 127.0.0.1:1234  ...

Or allow forward to support socks5?

This would ensure sslocal encapsulates its traffic within the specified SOCKS5 proxy without requiring external tools like socksify, proxychains, etc...

Benefits

• Simplifies integration in environments where a SOCKS proxy is the only allowed outbound connection.
• Reduces dependency on third-party tools for SOCKS chaining.
• Improves usability and flexibility for users requiring advanced routing scenarios.

Environment

• Version: shadowsocks local 1.23.4 (commit c28c40cc56648257139a6f3cc85406983906c8e9)
• Platform: OpenBSD 7.7
• Additional Context: SSH-based SOCKS proxy (ssh -D).

Thank you for considering this feature request!