SOCKS.CONF(5)

✨ SOCKS.CONF(5) ✨

okay bestie, gather round 💖 this is the manual page for socks.conf, the socks client configuration file syntax — and ngl it's the little file that decides where all your socksified traffic actually goes. lowkey iconic.

---

🎀 NAME 🎀

socks.conf — socks client configuration file syntax

---

💅 DESCRIPTION 💅

so the config file for the socks client library is what lets you control logging and server selection. that's the whole vibe.

it's split into two parts, bestie:

• global settings
• routes

and you can comment out any line using the standard comment character #. yes queen, comment your life away 🫶

---

🦋 FORMAT 🦋

the global settings are just a keyword, then a colon, then the value. simple as that. ✨

• debug — set this field to 1 and boom, debugging is turned on 🔥
• logoutput — this value controls where the client library sends its logoutput. it can be either syslog, stdout, stderr, a filename, or a combination of those. the default is no logging. heads up though: the value syslog may conflict with the program being socksified if that program also uses syslog 😭 so watch out for that.
• resolveprotocol — the protocol used to resolve hostnames. valid values are udp, tcp and fake. the default is udp.
• route.badexpire — how long the "bad" marking of a route should remain set before it is removed. default is 300 seconds.
• route.maxfail — how many times a route can fail before it is marked as bad. default is 1.
• timeout.connect — the number of seconds the client will wait for a connect to the proxy server to complete. the default is 0, which means the client should use the system's default. periodt.

---

🌈 ROUTES 🌈

the routes are specified with a route keyword. inside a pair of parenthesis ({}) a set of keywords control the behavior of the route. yes bestie, {} — that's the parenthesis situation here, don't come for me.

each route can contain three address specifications: from, to and via. a route is selected for a connection based on the values within the route block. it's giving matchmaking but for packets 💖

when searching for a route to match the client's request, the library will look in this order, no skipping:

1. first for a direct route
2. then for a socks_v4 route
3. then a socks_v5 route
4. then a http route
5. and lastly for a upnp route

depending on how the library is configured and what environment variables are set (peep the manual for socksify(1)), there may or may not be an automatic fallback to an auto-generated direct route if no other route is found. so like... sometimes it saves you, sometimes it doesn't 🙈

the route block can contain the following:

👑 ADDRESSES 👑

each address field can consist of:

• a IP-address (and where meaningful, a netmask, separated from the IP-address by a / sign)
• a hostname
• a domainname (designated by the leading .)
• or an interfacename (where meaningful)

each address can be followed by a optional port specifier. slay.

• from — the route is used only by requests coming from the address given as value.
• to — the route is used only by requests going to the address given as value.
• via — address of the proxy server that should be used as a gateway for the connection, or the special value direct to indicate the connection should be direct rather than go via any proxy server.

in the case of upnp, the address can also be the name of the interface to use for discovering the upnp controlpoint, if the full url for the IGD is not yet known, or the special value broadcast to indicate the client should broadcast for an upnp-router on all available network interfaces. yes bestie, broadcast — it's yelling into the void hoping a router answers 📣

• port — parameter to from, to and via. accepts the keywords eq/=, ne/!=, ge/>=, le/<=, gt/>, lt/< followed by a number. a portrange can also be given as "port <start #> - <end #>", which will match all port numbers within the range <start #> and <end #>. math girlie hours 🧚

🌸 Options 🌸

• clientcompatibility — enables certain options for compatibility with broken servers. valid values are: necgssapi, for compatibility with servers implementing gssapi the NEC socks way. (yes, "broken servers" is literally in the manual. we said what we said 💀)
• command — the server supports the given commands. valid commands are bind, bindreply, connect, udpassociate and udpreply. the default is all commands supported by the protocols set for the route.

can be used instead of, or to complement, protocol.

• gssapi.enctype — which encryption to enforce for GSSAPI-authenticated communication. possible values are clear, integrity, or confidentiality. the default is to try for confidentially, but accept whatever the server offers except clear, as clear is not part of the SOCKS GSSAPI standard. 🚫
• gssapi.servicename — which servicename to use when involving GSSAPI. default is "rcmd".
• method — list of authentication methods the client supports and which to offer the server. currently supported values are none, gssapi, and username. the default is all supported methods.
• protocol — the protocols the server supports. supported values are tcp and udp. the default is all supported protocols.
• proxyprotocol — the proxy protocols the server supports. currently supported values are socks_v4, socks_v5, http, and upnp. the default is socks_v4 and socks_v5.

⚠️ note that if the socks server requires any form of authentication, you need to explicitly set this to socks_v5, as v4 does not support authentication. no cap, v4 simply cannot do it.

---

💜 EXAMPLES 💜

see the example directory in the distribution. (yes that's the whole section, they're keeping it mysterious 🙈)

---

⭐ ENVIRONMENT ⭐

• SOCKS_USERNAME — use the value of SOCKS_USERNAME as the username when doing username authentication.
• SOCKS_PASSWORD — use the value of SOCKS_PASSWORD as the password when doing username authentication.

😭 not recommended as other users on the system might be able to see your password. bestie please, do not do this.

• SOCKS_AUTOADD_LANROUTES — if this variable is set to "no", the client will not try to auto-add direct routes for all addresses on the LAN. the default is to add them.
• SOCKS_DISABLE_THREADLOCK — if this variable is set, the client will not perform threadlocking. the default is for the client to attempt to figure out for itself whether the application to socksify needs threadlocking or not. main character energy: it just figures it out itself 💅

some additional environment variables are documented in socksify(1).

• FILES — /etc/socks.conf 📁

---

🫶 AUTHORS 🫶

for inferno Nettverk A/S:

• Michael Shuldman
• Karl-Andre' Skevik

---

🔥 SEE ALSO 🔥

socksify(1), sockd(8), sockd.conf(5)

information about new releases and other related issues can be found on the Dante WWW home page: http://www.inet.no/dante/

---

💀 BUGS 💀

see the accompanying BUGS file. new ones should be reported to dante-bugs@inet.no. (they're collecting them like pokémon cards, send yours in 📮)

---

and that's the whole page bestie!! this one is from the File Formats Manual, dated July 29 2013, and it's SOCKS.CONF(5) — go forth and route responsibly ✨💖