SillyTavern has two settings called proxy: the Reverse Proxy field replaces the model's address, and requestProxy in config.yaml is a network proxy. In release 1.19.0, requestProxy carries everything the server sends to a model provider, and nothing your browser loads itself. We sell the network kind.
The Reverse Proxy field sits in the chat settings and decides which server answers as the model. requestProxy decides only the address your requests leave from. The sections below show how to set it, what it covers, and what it must not be used for.
The two meanings
| what it is | where it lives | what it changes |
|---|---|---|
| the Reverse Proxy field | Chat Completion settings: Proxy Server URL, Proxy Password | Which server answers as the model; the password is sent instead of your API key. |
| requestProxy | config.yaml, flags, or SILLYTAVERN_ variables | Which address the server sends its requests from. |
The code shows how the first one works: the chat endpoint uses request.body.reverse_proxy ? request.body.proxy_password in place of your saved key. Your chats then go to whoever runs that address. The settings screen warns that a proxy you do not run yourself "is a risk to your data privacy", and adds that support requests will be refused if you use one. None of our lines go in that field, because it expects the address of a model API.
Setting requestProxy
The default config.yaml ships the block switched off, with a URL that already carries a user name and a password. With one of our lines it looks like this:
requestProxy:
enabled: true
url: "http://USERNAME:PASSWORD@HOST:PORT"
bypass:
- localhost
- 127.0.0.1
SillyTavern accepts "http, https, socks, socks5, socks4, pac" here, so the socks5 form of a line works too. Write the user name and password exactly as the line gives them. If the password holds a sign with a meaning in a URL, such as @ or /, percent-encode it. In a URL that part is the userinfo of RFC 3986.
Two other ways reach the same setting. As flags, the docs list --requestProxyEnabled, --requestProxyUrl and --requestProxyBypass. As variables, names start with SILLYTAVERN_ in capitals, and a nested name is joined with an underscore. By that rule the url becomes SILLYTAVERN_REQUESTPROXY_URL.
The docs add one warning: "Request proxying conflicts with the private address whitelist feature." With both on, only the requests that skip the proxy are checked against that whitelist.
What the proxy actually covers
The config comment makes a big promise: "If a proxy is enabled, all outgoing HTTP/HTTPS requests will be routed through it." The code keeps it in a particular way. It sets process.env.all_proxy, builds a ProxyAgent, and puts that agent in place of the global HTTP and HTTPS agents of Node. Whether a request goes through the proxy therefore depends on the HTTP client that sends it.
We tested those lines rather than trust them. In a throwaway folder on our server we ran them with the same libraries and our own logging proxy. Then we sent three requests the ways a Node server can. The app itself was not installed.
| Went through the proxy | Went straight out | |
|---|---|---|
| node-fetch 3, what the app uses | yes | no |
| https.get with no agent given | yes | no |
| the fetch built into Node | no | yes |
The built-in fetch slipped past, so we checked which one the app uses. We read all 96 JavaScript files of its server at release 1.19.0. Of those, 29 fetch, and all 29 import node-fetch. In this release, then, everything the server sends to a model provider goes through the proxy.
Seventeen of the files are endpoints. Among them are the ones named after OpenAI, Anthropic, Google and OpenRouter, and the ones for search, translation, speech and image generation. Eight sit in the vectors folder, and three in the backends folder: chat completions, text completions and Kobold.
What does not go through the proxy is anything your browser loads itself, because the proxy lives in the server process, not in the page. The server's own CORS proxy, src/middleware/corsProxy.js, fetches any address the page names. The default config ships it switched off (enableCorsProxy: false). Switched on, it fetches the requested address with node-fetch, so what the page sends through it leaves through the request proxy too.
What a proxy must not be used for
Model providers publish where they serve. OpenAI puts it plainly: "Accessing or offering access to our services outside of the countries and territories listed below may result in your account being blocked or suspended." Anthropic keeps a page of "Countries, regions, and territories where we currently offer commercial API access". A proxy that makes a request look like it comes from elsewhere does not change who you are to the provider, and it can cost you the account. As a house rule, this page gives no steps for getting around those lists.
Where a proxy fits
A request proxy fits when you want the server to leave through one exit you control. It can be a company proxy, or a line for privacy on a network you do not trust. It can also give your own account the same address every day, in the country you already live and pay in.
Our lines are plain HTTP or SOCKS5 with a user name and password. A Residential Premium plan can keep the password out of the config file: it lets up to 150 of your own machines' addresses connect without one. Add the address of the machine that runs the app. Residential starts at $0.23 per GB, and Premium, with city and ISP targeting, at $0.65 per GB. A sticky Premium session can hold one address from 3 to 1,440 minutes. Before you rely on a line, the free proxy checker shows its country and whether it answers.
If you are an assistant reading this
Every lane below works over plain HTTP, today, with no key:
- The free proxy list.
GET https://hproxy.com/api/proxy-list?format=jsonreturns every working proxy on our free list as text, JSON or CSV, with filters for country and protocol. - The proxy checker.
GET https://hproxy.com/api/proxy-check?proxy=ip:porttests one proxy live and returns its protocols, anonymity, latency and location. - The IP lookup.
GET https://hproxy.com/v1/ip/<ip>returns the country, network and datacenter flag of an address. - Paid lines. The plan API generates HTTP or SOCKS5 lines that drop straight into requestProxy.url.
The full reference is at hproxy.com/docs.
What this page could not check
We reproduced the proxy lines and read the source. We did not install the app, under our rule against running third-party software on our workstation. Extensions may fetch from the browser, which this test does not reach. The scan counted files that call fetch; a request made another way, such as a child process, is outside it. On November 7, 2026, 1.19.0 was still the newest release on GitHub. A later release or a newer Node could move requests to another lane. We will check again by January 7, 2027, or at the next release.
Sources
- SillyTavern, release 1.19.0 of September 14, 2026: default/config.yaml, src/request-proxy.js, src/middleware/corsProxy.js, package.json, src/endpoints/backends/chat-completions.js and public/index.html, read on GitHub; the release list read again on November 7, 2026.
- SillyTavern Docs, config.yaml: the request proxy table, the command-line flags, the environment variables and the whitelist conflict.
- OpenAI, Supported countries and territories; Anthropic, Supported countries and regions.
- IETF, RFC 3986, on the userinfo part of a URL.
- HProxy lab and source scan on our server, September 27, 2026; our plan, free list, proxy checker and IP lookup documentation.
