Signal LynxA practical, layered setup that keeps nuisance traffic out and your webhook receiver sane.
If you run TradingView alerts into a webhook, you are letting a chart trigger a real action on a real machine. The problem is that a lot of folks set this up by opening a firewall or router port (usually 443) and calling it done. It works, right up until the day the internet reminds you that it is full of scanners and bots.
This idea (ok, maybe it's more of a blog post) is about doing it in a safe way. Just a few basic layers that, combined, solve almost every real-world problem you will run into. No expensive enterprise gear required.
Main Points:
- Do not expose your webhook receiver (computer) to the whole internet with a wide-open firewall rule.
- Allowlist TradingView's outbound webhook IPs at the firewall/router level.
- Put a reverse proxy in front (NGINX, Caddy, Apache). Let it be the 'front desk'.
- Require a simple passphrase field in the JSON payload (a PIN). Reject anything that does not match.
- Optional but smart: add rate limiting and (if you are high-risk) verify TradingView's webhook certificate.
Why 'just open port 443' is a gamble
The public internet gets scanned constantly. Most of it is not personal. It is just automated noise looking for anything that responds. If your machine is reachable from the internet, you should assume it will be found. Sometimes that traffic is harmless probing. Sometimes it is a bot trying known paths. Either way, it is attention you did not ask for. The goal here is simple: let TradingView in, keep the rest out, and make sure a random request can never trigger a trade.
Layer 1: IP allowlisting (the guest list)
TradingView publishes the IP addresses their servers use to send webhook requests. That means you can set your firewall/router to only accept inbound traffic from those IPs. Everything else gets dropped. Think of it like a guest list. If your name is not on it, you do not get in. This is typically sufficient, but as you'll read further on, we can do better.
TradingView's current list of Alert IPs:
- 52.89.214.238
- 34.212.75.30
- 54.218.53.128
- 52.32.178.7
Where you apply this depends on your setup:
- Home PC behind a router: apply it on the port-forward rule if your router supports it, and/or on Windows Firewall.
- VPS or cloud server: apply it in the provider firewall/security group and on the server OS firewall.
Layer 2: Reverse proxy (the front desk)
A reverse proxy is a lightweight server that sits on the public port and forwards approved requests to your actual webhook app. Your webhook app might be a trading engine, a relay script, a Flask app, a Node service, or something you built yourself. The point is, your webhook App should not be directly exposed to the internet, and a reverse proxy is a typical way to protect your App. Common reverse proxy choices are NGINX, Caddy, Apache. On Windows, NGINX is a popular option.
Typical pattern:
- Public port: 443 (HTTPS) or 80 (HTTP). TradingView supports webhook URLs on ports 80 and 443.
- Internal port: whatever your webhook receiver actually listens on (examples: 127.0.0.1:5000, 127.0.0.1:9000, etc).
- Reverse proxy listens publicly, then forwards internally to your app.
A tiny NGINX example (This is trimmed - do not try to implement the below verbatim):
http {
# rate limit zone (optional but recommended)
limit_req_zone $binary_remote_addr zone=webhook:1m rate=10r/s;
server {
listen 443 ssl;
location /webhook {
# allowlist TradingView IPs
allow 52.89.214.238;
allow 34.212.75.30;
allow 54.218.53.128;
allow 52.32.178.7;
deny all;
# optional rate limiting
limit_req zone=webhook burst=20 nodelay;
# forward to your local webhook app
proxy_pass http://127.0.0.1:5000;
}
}
}Note on HTTPS:
If you use "https://" in your webhook URL (port 443), you will need a valid TLS certificate. Many people use a free Let's Encrypt cert or a tunnel service that terminates TLS. Self-signed certificates will work for internal testing and TradingView Alerts but (for awareness) they may not be accepted reliably by other third party senders.
Layer 3: Passphrase in JSON (the PIN code)
IP allow listing keeps most garbage out, but it is not the whole story. If you want one extra layer that costs almost nothing, add a passphrase field in the JSON payload and validate it before you do anything else. If the passphrase is missing or wrong, your webhook receiver will ignore the request. No trade. No action.
Example webhook message body:
{
"passphrase": "YOUR_LONG_RANDOM_SECRET",
"symbol": "{{ticker}}",
"action": "BUY",
"price": "{{close}}",
"time": "{{time}}"
}This is not about hiding secrets in your chart. It is about making sure the request is meant for your system. While a short passphrase is sufficient, treat this like a password... and it goes without saying, do not reuse passwords from anywhere else.
Optional: Rate limiting (keep nuisance traffic from becoming a problem)
Even if you allowlist TradingView, rate limiting is still useful. It prevents accidental loops, repeated alerts, or misconfigured clients from hammering your receiver. NGINX supports this with limit_req_zone and limit_req. A simple setting like 10 requests per second per client IP with a small burst buffer is usually plenty.
Optional (high OPSEC): Verify TradingView's webhook certificate
If you are operating at higher risk, TradingView documents a method where you can verify certificate fields to confirm a request really came from TradingView. This is only relevant when using HTTPS. Most people do not need this, but it is a nice option if you want more certainty than IP allowlisting alone.
Common mistakes (save yourself a weekend)
- Using a LAN IP (a LAN IP will start with 192.168.x.x) as your TradingView webhook URL. TradingView must send to a public URL/IP.
- Opening a port but forgetting to restrict it to TradingView IPs.
- Putting sensitive info in the webhook URL or message. Treat webhooks like public internet traffic.
- Using HTTPS with a certificate that the sender will not accept, then wondering why nothing arrives.
- Building a webhook receiver that does not respond quickly. Slow responses can lead to missed or canceled webhook deliveries.
Simple checklist
- Expose only what you must (prefer 443 with HTTPS when possible).
- Allowlist TradingView webhook IPs at the firewall/router/provider firewall.
- Put a reverse proxy in front and deny everything else.
- Require a passphrase in the JSON body and validate it before placing trades.
- Add rate limiting, and consider certificate verification if your threat model demands it.
None of this needs to be complicated. The goal is intentional rules fostering common sense security. Lock the door, use the guest list, and add a PIN before you let a webhook move money.
This is a security and reliability post, not financial advice. If you automate trading, you are responsible for your own risk controls, position sizing, and safety checks.
If you are looking to automate your TradingView strategies, route signals to exchanges, or simply want safer, smarter strategy structures, please keep Signal Lynx in your search. The Signal Shield Software can automatically configure your Windows computer to be a secure webhook receiver.