Coder Legion - Recent posts tagged proxy

How to Use a WAF with Let's Encrypt Automatic HTTPS Without Guessing Renewal

Tue, 27 Oct 2026 02:47:17 +0000

Checking an SSL option is not the same job as renewing a certificate. If the goal is to use a web application firewall together with Let's Encrypt automatic HTTPS, I separate those jobs before I change DNS. The SafeLine pages available for this guide describe a self-hosted reverse-proxy WAF, an application form, and an SSL checkbox for HTTPS apps. They do not describe an ACME client, a Let's Encrypt account, HTTP-01 routes, DNS-01 hooks, or a renewal schedule. This is a decision checklist for that gap. It is not a claim that SafeLine issues or renews certificates for you.

SafeLine is placed in front of a web application. Clients talk to the WAF, and the WAF forwards traffic it considers safe to the origin. The introduction describes that role as a reverse proxy, which is different from a forward proxy that hides a client. Documented attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse. The same page lists web-attack defense, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. Feature descriptions also cover rate limiting, CAPTCHA challenges, an authentication challenge that asks visitors for a password, and dynamic protection that encrypts HTML and JavaScript on each visit. None of those controls is a certificate authority. Source: https://docs.waf.chaitin.com/en/home

That split is the whole point of the checklist. A certificate lets browsers trust the name on the public listener. A WAF policy decides which requests may continue. Automatic HTTPS fails when port ownership, challenge reachability, or certificate storage is assumed instead of tested. Attack filtering can still look healthy on the day renewal breaks.

I walk through six decisions before the cutover.

Decide who owns the public ports. The application guide says you set a domain, a listen port such as 80 or 443, and an upstream address. For HTTPS apps, you check the SSL option. After saving, you resolve the domain to the IP of the server running SafeLine. If that server becomes the only public answer for the name, any renewal agent left on the old origin may stop seeing inbound challenges. Write the current listener down before you edit DNS. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Decide where the visitor certificate is presented. The SSL option tells the proxy to handle HTTPS on the listen port. The supplied text does not say the product requests a certificate, stores an account key, or renews one. Until you confirm newer documentation, plan to present a certificate you already know how to obtain, or keep issuance on a host that can still complete the challenge. Do not read automatic HTTPS into a checkbox.

Map the renewal method to a path that survives the proxy. Let's Encrypt automation commonly uses the ACME protocol. HTTP-01 looks for a token on port 80. TLS-ALPN-01 uses a special handshake on port 443. DNS-01 publishes a TXT record and does not need the WAF to pass an HTTP token. None of these methods appears as a SafeLine feature in the sources used here. If your automation is HTTP-01 and the WAF takes port 80, renewal can fail while the current certificate still serves. Run a renewal test before the live certificate is close to expiry, and keep the old listener available until that test passes.

Decide the upstream hop separately. SafeLine forwards cleaned traffic to the real address you enter as upstream. The guide does not require that hop to be HTTPS, and it does not document automatic certificates for the origin. If the origin sits on a private network, HTTP on that hop may be acceptable to you. If you need encryption to the origin, configure and verify that yourself. Record the choice. Do not inherit it from the public SSL option.

Confirm the WAF host is actually a supported place to terminate traffic. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, at least 1 CPU core, 1 GB of memory, 5 GB of disk, and SSSE3. Installation can follow the documented automatic command or a manual Compose layout, with configuration and data written under a directory you create, commonly /data/safeline. The web console is then opened at https://<safeline-ip>:9443/ unless you change the management port. An ARM install needs a Pro license; the Personal Edition is not supported on ARM. The LTS release line is no longer maintained starting from 9.1.0-LTS on 14 August 2025. Those constraints tell you whether this host should be the public HTTPS endpoint. They do not add issuance. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Prove filtering only after the HTTPS path is real. The application guide lists sample probes for SQL injection, XSS, path traversal, code injection, and XXE, then tells you to inspect the attack list and open a detail view. Use a domain you control. A block page shows that inspection is active. It does not show that the next certificate renewal will succeed.

My order is install, log in through the administrator account from the documented docker exec safeline-mgt resetadmin step, add the application, check SSL only when a certificate is ready for that listener, point DNS at the SafeLine host, then test both a malicious request and a renewal. If the renewal client cannot complete its challenge, stop. Designs that do not require an undocumented SafeLine integration include moving renewal to DNS-01, or keeping the challenge listener with the automation you already run, and moving visitor traffic only after a renewal test passes. Pick a design you can test. Do not add an issuance command. These documents do not provide one.

Does SafeLine issue or renew Let's Encrypt certificates?

Not based on the documents used here. They cover reverse-proxy filtering, application fields, and an SSL option for HTTPS apps. They do not document ACME, Let's Encrypt, or automatic renewal. Keep certificate lifecycle in a process you can already explain.

Is the SSL checkbox the same as automatic HTTPS?

No. Checking SSL means the application should be served over HTTPS on the listen port you chose. Automatic HTTPS also needs a certificate, a private key, a renewal method, and a working challenge. The application guide does not tie the checkbox to a certificate authority.

What fails if DNS moves before a renewal test?

The site can keep serving the certificate you already installed, then fail on the next renewal. HTTP-01 and TLS-ALPN-01 need the public challenge to reach the client that ordered the certificate. If only the WAF answers, and no documented challenge handler exists, renewal fails even though attack logs still update.

Does the upstream have to be HTTPS too?

The docs say SafeLine receives visitor traffic and forwards safe traffic to the upstream address. They do not mandate the upstream scheme and do not describe automatic origin certificates. Choose HTTP or HTTPS for that hop from your trust boundary, then verify it. The public SSL option does not answer that question.

What should I verify on the SafeLine host first?

Check architecture, Docker version, Compose version, CPU, memory, disk, and SSSE3 against the deploy guide. Add the application with domain, port, upstream, and SSL only if HTTPS is intended. Resolve the name to the SafeLine server. On ARM, confirm a Pro license, because the Personal Edition is not supported there. Then test renewal separately from the attack samples.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Use a WAF with Let's Encrypt Automatic HTTPS: A Cutover Checklist

Tue, 27 Oct 2026 02:46:45 +0000

Automatic HTTPS sounds simple until a reverse-proxy WAF sits on the public address. Let's Encrypt can renew a certificate, but the supplied SafeLine documentation does not describe an ACME client, a certificate upload workflow, or an automatic renewal job. This guide is therefore a decision checklist, not a promise that SafeLine issues or renews Let's Encrypt certificates for you.

Start by separating three jobs that are easy to mix together. The certificate authority proves control of a name and signs a certificate. The TLS endpoint presents that certificate to browsers. The WAF inspects HTTP after it can see the request. SafeLine's documented role is the third job, implemented as an HTTP/HTTPS reverse proxy: it receives traffic for the original site, filters malicious requests, and forwards trusted traffic upstream. That model is described in the application guide at https://docs.waf.chaitin.com/en/GetStarted/AddApplication and in the product overview at https://docs.waf.chaitin.com/en/home.

What the console actually documents

When you add an application, the console asks for a domain, a listen port, and an upstream address. For an HTTPS application, the same dialog says to check the SSL option. After that, you resolve the domain to the SafeLine server. Those fields tell you where clients will connect and where cleaned traffic goes. They do not tell you which program runs certbot, where the private key is stored, or how a renewal hook reloads the proxy.

Treat the SSL checkbox as a routing requirement, not as evidence of automatic issuance. If clients use port 443, SafeLine must be the process listening there, or something in front of it must forward that port without breaking the Host header. The documented examples use 80 or 443. The management console itself is separate: the deploy guide opens it at https://<safeline-ip>:9443/. Do not point public site DNS at 9443 and call that application HTTPS.

Checklist before you automate renewal

Use this order so certificate automation does not fight the proxy.

Confirm the host can run SafeLine. The deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy requires Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU also needs the ssse3 instruction. On ARM, the same guide says a Pro license is required and the Personal Edition is not supported. If you planned an ARM box only because a certificate client was already installed there, fix the license and architecture question before you automate anything.
Choose the public name clients will type. The application domain can be a domain name, a hostname, or an IP address. Let's Encrypt issuance for a bare IP is a different problem from name-based issuance, and these sources do not document either path inside SafeLine. If you need automatic HTTPS, plan the name and the renewal client outside the undocumented area, then make the presented certificate match the domain entered in the application dialog.
Decide who terminates TLS. Because SafeLine is the reverse proxy clients reach, the practical default is that the public certificate is presented on the SafeLine listen port. Renewal must therefore update the material that this proxy presents, or you must put another TLS endpoint in front and still satisfy the documented DNS step. Do not assume an undocumented integration will copy certificates into the container.
Keep port 80 and port 443 explicit. HTTP-01 style validation generally needs a reachable HTTP challenge on port 80. DNS-01 does not. Neither method is described as a SafeLine feature. If your renewal method needs port 80, make sure the WAF listen plan does not silently capture that port without a path for the challenge. If you cannot prove that path from the current docs, run renewal on a host layout you already understand, then only proxy the finished HTTPS site.
Point DNS only after the listen port and upstream are set. The application guide says to resolve the entered domain to the SafeLine server IP, then access the protected application through that domain. Renewing against the old origin IP after this cutover will fail or, worse, validate the wrong host.
Preserve the upstream. SafeLine forwards to the real application address you enter. The origin should accept traffic from the WAF and should not require browsers to connect to it directly. If the origin also has its own certificate, that is an internal hop. These sources do not specify upstream TLS settings, so do not invent a toggle. Verify the hop with a normal request after cutover.
Turn protection on only after a clean page load. Documented controls include web-attack filtering, rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS encryption, as listed at https://docs.waf.chaitin.com/en/home. Rate limiting is described as a defense against denial-of-service patterns, brute-force attempts, traffic surges, and other abuse. A renewal client that suddenly requests the same challenge URL, or a monitoring probe that looks automated, can trip bot or rate controls. Test a normal browser visit first, then review the attack list in the console before you tighten those controls.

Prove the proxy, not the certificate story

The application guide includes intentional test requests for SQL injection, XSS, path traversal, code injection, and XXE. Replace the sample domain with yours. A block page means the request was inspected. Open the console attack list and use the detail view. A valid certificate in the browser only proves TLS presentation. It does not prove that SafeLine is on the path, and a block page does not prove that Let's Encrypt will renew next month.

Also separate the management plane from the site. Administrator access is created with docker exec safeline-mgt resetadmin after installation, as documented in the deploy guide. Store that password outside any public web root used for certificate challenges. The .env file is created with restricted permissions in the manual install; do not place private keys or database passwords in a directory that an HTTP challenge client serves to the internet.

What to record for the next renewal

Write down four facts before you leave the change window: the application domain, the SafeLine listen port, the upstream address, and the external system that actually holds the certificate and key. Add the date you last presented a working certificate on that listen port. When renewal fails later, those four facts tell you whether the outage is DNS, the undocumented certificate handoff, the upstream, or a protection rule. The sources do not provide a SafeLine command that renews Let's Encrypt certificates, so a runbook that says the WAF renews it is already wrong.

If the LTS package is in use, note that too. The deploy guide says the LTS line will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it recommends upgrading. Certificate automation on an unmaintained proxy is a poor place to discover a reload problem.

Does SafeLine issue Let's Encrypt certificates automatically?

The supplied install, overview, and application documents do not describe ACME, certbot, or automatic Let's Encrypt issuance. Check the SSL option for an HTTPS application, but plan issuance and renewal with a process those pages actually document or with an external client you operate yourself.

Where should the public certificate be presented?

Clients resolve the application domain to the SafeLine server and connect to the listen port you configure, commonly 443 for HTTPS. The certificate visitors see should match that name. How the key is loaded into SafeLine is not specified in these sources, so do not invent an upload or reload command.

Can I validate Let's Encrypt through the WAF?

Only if your chosen challenge can succeed on the path you control. These documents do not define an HTTP-01 exception, a DNS-01 plugin, or a renewal hook. If you cannot explain the challenge path without guessing a feature, terminate validation elsewhere and bring the finished certificate to the proxy through a procedure you have already tested.

Which SafeLine controls can interfere with automation?

Rate limiting, CAPTCHA, and authentication challenge are documented visitor controls. A challenge client or health check can look like abuse. Confirm a normal visit and review the console attack detail before enabling stricter controls on the host that also serves renewal traffic.

What should I test after the DNS cutover?

Load the real site through the protected domain, confirm the certificate name matches that domain, then send the documented SQL injection, XSS, path traversal, code injection, and XXE samples with your own domain. A block page plus an entry in the attack list shows inspection. Repeat a benign page load so you also know that legitimate traffic still reaches the upstream.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Decide Whether a WAF Belongs Behind Cloudflare or Any CDN

Tue, 27 Oct 2026 02:45:36 +0000

A CDN and a self-hosted web application firewall answer different placement questions. Cloudflare, or any other content delivery network, usually becomes the public name that visitors resolve. SafeLine, as documented, is a reverse proxy that is supposed to receive the application traffic before the origin does. The supplied product pages never describe a Cloudflare connector, a generic CDN origin mode, header restoration, cache bypass, or a shared certificate workflow. This article is a decision checklist for that gap. It does not turn silence in the docs into a setup procedure.

Start with the traffic path the product actually documents. The home page defines a WAF as a filter and monitor for HTTP traffic between a web application and the Internet, and it says deploying a WAF in front of an application places a shield between the application and the Internet. SafeLine is described as a reverse proxy: clients pass through it before they reach the server. It filters, monitors, and blocks malicious HTTP/S traffic and is intended to prevent unauthorized data from leaving the app, using policies that separate malicious traffic from safe traffic. The listed core capabilities are defenses for web attacks, proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list names protection against attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, plus rate limiting for DoS attacks, brute-force attempts, traffic surges, and other abuse. CAPTCHA, an authentication challenge that asks visitors for a password, and dynamic protection that encrypts HTML and JS on each visit are also documented. Those controls apply to traffic SafeLine proxies. They are not documented as rules pushed into a CDN. Source: https://docs.waf.chaitin.com/en/home

The application guide then fixes the public address. After SafeLine is installed, you add an application with a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps use the SSL option. SafeLine receives traffic for the original site, cleans malicious traffic, and forwards the rest to the upstream. The following instruction is to resolve that domain to the IP of the server where SafeLine runs. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

That sentence is the conflict. If visitors must resolve the name to a CDN, you are no longer following the documented public path. A CDN-in-front design would require the CDN to connect onward to SafeLine, and SafeLine to connect onward to the application. The pages do not say how to configure that hop, which certificate belongs where, or whether SafeLine will see the visitor address or the CDN address. Treat those as unknown. Do not fill them with settings copied from another product.

Walk the checklist in order.

Confirm the host before you argue about DNS. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and a minimum of 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3. An ARM installation needs a Pro license to work properly, and the Personal Edition is not supported on ARM. LTS is no longer maintained starting from 9.1.0-LTS on 14 August 2025, and the page recommends upgrading. A placement debate does not relax those requirements. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Separate the console from the site. MGT_PROXY is the number of proxy layers in front of the management console. It should be used only when configuring a proxy for the console, and the default is 0. The console example port is 9443. Changing MGT_PROXY does not put protected sites behind Cloudflare or any other CDN.

Write the path you can still defend. Domain, listen port, SSL choice, and upstream must match the application dialog. If the public name points at a CDN, label that design custom. The only checks these sources support are reachability checks you can observe yourself: the intermediary can open the SafeLine listen port, SafeLine can open the upstream, and a test request arrives at the proxy rather than stopping at a cache.

List controls that depend on the address SafeLine sees. IP-based rate limiting is a documented capability, described as throttling traffic that exceeds defined limits. The pages do not name a trusted CDN header and do not say SafeLine restores the original client address. If the only connection SafeLine sees comes from an intermediary, IP limits may apply to that intermediary. Attack inspection still requires the request to reach SafeLine. A response served from a cache never enters the documented proxy path, so it is outside the claim that SafeLine cleaned it.

Close the bypass. The documented model forwards cleaned traffic to the upstream you configure. If clients can still reach that upstream directly, the proxy is optional. A CDN in front does not, by itself, remove a public origin.

Retest with the cases already published, not with a new exploit catalog. The application guide gives SQL injection, XSS, path traversal, code injection, and XXE query examples and says to replace the sample host with your domain. Success, as documented, is the blocking page plus an entry in the console attack list, including the detail view. If the request never appears there, do not credit SafeLine for a block that happened somewhere else.

The home page also prints an effect evaluation on 33669 samples for ModSecurity Level 1, CloudFlare Free, SafeLine Balance, and SafeLine Strict. Detection is listed as 69.74%, 10.70%, 71.65%, and 76.17%. False positives are 17.58%, 0.07%, 0.07%, and 0.22%. Accuracy is 82.20%, 98.40%, 99.45%, and 99.38%. That table compares separate evaluations. It is not a test of SafeLine chained behind CloudFlare or any other CDN, and it does not supply placement steps.

The same page says SafeLine is production-ready. Read that as a statement about the documented proxy deployment, not as approval for an undescribed CDN hop. If the documented path is enough, resolve the name to SafeLine and point upstream at the application. If a CDN must remain the public edge, keep the plan limited to what you can verify and leave certificate mapping, cache exceptions, and original visitor identity unmarked until a source actually specifies them.

Does SafeLine document putting sites behind Cloudflare?

No. The home, deploy, and application pages describe a self-hosted reverse-proxy WAF and tell you to resolve the application domain to the SafeLine server. They do not document a Cloudflare or generic CDN integration.

What should resolve to the SafeLine address?

The application guide says to resolve the domain you configured to the IP of the server where SafeLine runs, after you set domain, port, and upstream.

Can MGT_PROXY place the WAF behind a CDN?

No. MGT_PROXY counts proxy layers for the management console only. The deploy guide says to use it only for that console proxy, and the default is 0.

What breaks if a CDN connects to SafeLine?

The docs do not define client-address restoration. IP-based rate limiting and any control tied to the address SafeLine sees may follow the intermediary address. Requests that a cache answers never reach the proxy.

How do I confirm SafeLine inspected a request?

Use the documented SQL injection, XSS, path traversal, code injection, and XXE examples against your own domain. Look for the blocking page and a console attack detail. Absence from the console means you cannot claim the proxy inspected that request.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Judge a WAF Behind Cloudflare or Any CDN

Tue, 27 Oct 2026 02:45:04 +0000

A CDN and a WAF can sit on the same request path, but only one of those roles is described in the SafeLine guides supplied for this article. SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic between an application and the Internet, and it is meant to stand in front of the application as a reverse proxy (https://docs.waf.chaitin.com/en/home). The application guide narrows that further: SafeLine is an nginx-based reverse proxy that receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Nothing on the home page, the deploy page, or the application page documents Cloudflare, a generic CDN origin mode, a trusted proxy list, or a client-IP header. If the search is how to put a WAF behind Cloudflare or any CDN, the accurate answer from these sources is a placement checklist, not a switch to enable.

The documented visitor path is short. In Applications, you add an application and enter the domain, hostname, or IP; the port SafeLine will listen on, such as 80 or 443; the SSL option when the app is HTTPS; and the upstream, which the guide calls the real address of the original app. After those fields are saved, the guide tells you to resolve that domain to the IP address of the server where SafeLine is located, then access the protected application through the domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That sentence is the whole DNS design the product states. A CDN owns the public name instead. Clients resolve to the CDN, and the CDN fetches an origin you chose in the CDN. Those are different resolution targets. You cannot satisfy both resolve the domain to the SafeLine server and resolve the domain to the CDN for the same name at the same time. One of them is outside the guide.

That conflict is the decision, not a missing checkbox.

Write the three addresses before you change records. Address one is the public name visitors type. Address two is the SafeLine listen address and port from Add Application. Address three is the upstream SafeLine will forward to. Protection only matches the guide when address one resolves to address two, and address two forwards to address three. If a CDN must be address one, then address two is no longer the documented public target. Label that design undocumented. Do not rename it to a SafeLine CDN feature.

Keep the upstream pointed at the application. The upstream is not the previous origin name, and it is not the CDN. If the CDN origin is SafeLine and the SafeLine upstream is the CDN, traffic has nowhere stable to land. The guide's forwarding story is one direction: SafeLine receives, cleans, and forwards to the original app (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Draw that arrow before you draw a CDN arrow.

Do not confuse the console with the site. The deploy guide tells you to open the console on the SafeLine server IP at port 9443, and MGT_PORT is the console port setting (https://docs.waf.chaitin.com/en/GetStarted/Deploy). On the same page, MGT_PROXY is the number of console proxy layers. It should only be used when configuring the proxy for the console. The default is 0, and no proxy is configured. It does not say it trusts a CDN, rewrites client addresses, or publishes an application. Leave it at 0 unless you are deliberately proxying the console and you understand you are changing console access, not site protection. Do not point a CDN origin at port 9443 in order to protect the website. That port is the management UI in the install flow, not the application listener you set to 80 or 443.

Ask what SafeLine can see, then stop where the docs stop. Core capabilities include defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). The same introduction describes blocking common web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal; throttling traffic that exceeds defined limits in order to defend against DoS attacks, bruteforce attempts, traffic surges, and other abuse; CAPTCHA challenges; an authentication challenge that asks visitors for a password; and dynamic protection that encrypts HTML and JS on each visit. IP-based rate limiting is explicit. If the CDN connects to SafeLine from the CDN address rather than from each visitor, SafeLine may see only that shared address. These guides never say SafeLine reads a forwarded client header, so you cannot claim that rate limits, access lists, or bot controls still distinguish visitors after that hop. If per-visitor control is the reason you deployed the WAF, the documented design is the direct path, where the domain resolves to SafeLine.

Prove the block in the console, not on a provider status page. The application guide's own check is to request test cases for SQL injection, XSS, path traversal, code injection, and XXE against your protected domain, expect the blocking page, and then open the attack list and its detail view (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Run that check while the domain resolves to the SafeLine server. If you later place a CDN in front, repeat a normal request and one of those checks, and compare the console. A new attack detail supports the claim that SafeLine received the request. No new detail means the CDN result is not evidence of SafeLine inspection. If the CDN serves a cached response, the request may never reach SafeLine, and these guides do not list cache-bypass controls.

Match the host to the deploy guide before you argue about edges. The minimums are Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, one CPU core, 1 GB of memory, 5 GB of disk, and SSSE3 on the CPU (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM server needs a Pro license; the Personal Edition is not supported on ARM. A CDN in front does not change those constraints, and the install page does not list provider-specific packages.

Use the home-page comparison table only as a warning. It includes a CloudFlare column among detection figures (https://docs.waf.chaitin.com/en/home). A column name is not an origin tutorial, a compatibility statement, or permission to copy provider settings into SafeLine. Placement still comes from the application guide's domain, port, upstream, and DNS instructions.

Order the work so rollback is obvious. Bring the direct path up first: console login, application fields, domain pointed at the SafeLine server, a normal page from the upstream, and a blocked test visible in the attack detail. Freeze that configuration. If a CDN is still required for caching or reach that SafeLine does not claim to provide, change DNS only as a separate, reversible step owned outside SafeLine. Record that the product docs do not cover the hop. Retest direct and proxied access independently. If the console stops explaining the blocks, put the domain back on the SafeLine address. Filling in guessed SSL modes, origin authentication, or real-IP headers will not make those behaviors appear in the current documents.

Does SafeLine document a Cloudflare or generic CDN mode?

No. The cited guides describe a reverse proxy and tell you to resolve the application domain to the SafeLine server. They do not document a CDN front end.

Which name has to point at SafeLine?

The domain, hostname, or IP you enter in Add Application. The application guide says to resolve that domain to the SafeLine server IP and then use it to reach the protected app.

Can MGT_PROXY put a website behind a CDN?

No. MGT_PROXY is the console proxy layer count. It defaults to 0 and is only for proxying the console, not for application traffic or a CDN origin.

What becomes unproven if every client shares one CDN address?

The docs list IP-based rate limiting and a web access control list, but they do not describe restoring a visitor address from a CDN header. Treat per-visitor controls as unproven in that layout.

How do I show that SafeLine blocked the request rather than the CDN?

Resolve your own application domain to SafeLine, use the guide's attack checks, and confirm the blocking page plus an attack detail in the console. A result that never creates that detail is not SafeLine evidence.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Configure Rate Limiting with a WAF Without Guessing the Ceiling

Mon, 26 Oct 2026 02:23:01 +0000

Configuring rate limiting is a policy decision that happens to be enforced by a proxy. If you start from a round number, you will either block a shared office network or leave a login form open to guessing. SafeLine's own pages are unusually clear about the boundary: they name the control, and they do not hand you a sample rule.

The product overview lists IP-based rate limiting among the core capabilities, next to web-attack defenses, bot defense, HTML and JavaScript encryption, and a web access control list (https://docs.waf.chaitin.com/en/home). The feature note says rate limiting defends web apps against DoS attacks, bruteforce attempts, traffic surges, and other abuse by throttling traffic that exceeds defined limits. Read that as a contract. You define the limits. The WAF throttles what exceeds them. The overview, the install guide, and the application guide do not publish default thresholds, rule-field names, or a shell command that creates a limit (https://docs.waf.chaitin.com/en/GetStarted/Deploy, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). This checklist is how to configure the control without pretending those missing details exist.

Confirm the reverse proxy before you throttle anyone

A rate limit can only count requests that reach the WAF. SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet, and it sits as a reverse proxy so clients pass through it before they reach the server (https://docs.waf.chaitin.com/en/home). The application guide describes the same design in implementation terms: SafeLine is developed based on nginx, receives traffic for the original site, removes malicious traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

The documented setup is in the Web Admin Console, not in a rate-limit API. On the Applications page, use Add Application. Enter the original domain, hostname, or IP. Set the port SafeLine will listen on, such as 80 or 443, and check SSL for HTTPS apps. Set the upstream to the real address that should receive cleaned traffic. After that, resolve the domain to the SafeLine server. Until DNS points there, clients can still bypass the proxy, and any later limit is optional for attackers who know the origin.

Prove the path with two checks that the docs actually support. First, load the site through the proxied domain and confirm the upstream responds. Second, try a harmless attack-shaped request of the kind the application guide lists, such as a SQL injection style query, an XSS-style query, a path traversal query, a code injection query, or an XXE-style query, with your own domain in place of the example host. A blocking page means the proxy inspected the request. The console attack list, opened from detail, is where you confirm the event. Neither check proves a rate limit is on. They only prove you are about to configure throttling on the path users actually use.

The install guide is the other half of whether you can even reach the console. It expects Linux, Docker, and Docker Compose, and it opens the console at https://<safeline-ip>:9443/ after startup (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That page is about bringing the instance up. It is not a rate-limit reference, so do not search it for a hidden throttle flag.

Treat the documented identity as the whole identity

The capability is IP-based. Configuration starts by accepting that limit, not by wishing for a user-based quota the supplied pages never describe. An address limit groups every request that arrives from the same IP. It will merge coworkers behind one office firewall. It will split an attacker who rotates addresses. If your abuse problem is one account across many IPs, or one IP across many accounts, IP throttling is only a partial answer. Say that in the change ticket so nobody later treats a quiet chart as proof that credential stuffing stopped.

Write the policy in plain language before you touch a number. Decide which path is expensive enough to protect first. Login, password reset, and any route that sends mail or SMS usually come before the homepage. Decide which shared addresses must survive a normal morning. A support team, a campus NAT, or a partner integration can look like a surge. Then name the failure mode you are buying down. Bruteforce wants a low ceiling on a small form. A traffic surge on a content page wants a higher ceiling. A DoS flood wants the origin kept alive even if some clients wait. The overview names all three. One number rarely serves all three equally well.

SafeLine also documents payload defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, path traversal, and related attacks (https://docs.waf.chaitin.com/en/home). Keep those rules in the design, but do not count them as rate limiting. A patient scanner can stay under a loose IP ceiling and still send exploit strings. A legitimate monitoring job can send clean requests fast enough to hurt a small upstream. Volume and malice are different axes.

Choose the number from your origin, then watch the first peak

Because the docs say the product throttles traffic that exceeds defined limits, the missing input is the definition. Take it from the origin's capacity, measured by you, not from a blog example.

Time the sensitive path under a normal peak. Note the request rate at which latency or errors become unacceptable. Then note the busiest legitimate IP in that same window, especially if it is a shared network. The ceiling should sit above that legitimate burst and below the rate at which one address can consume the origin by itself. If you cannot measure either number, you are not ready to turn the control on. Waiting is better than publishing a guess that blocks customers.

If the console you are running lets you attach a limit to one application or one path, start with the weakest critical route and leave everything else alone. If it exposes only a broader IP limit, document that constraint and pick the number required by the weakest critical route. Do not assume per-user keys, geographic buckets, or header-based quotas. Those shapes are not in the supplied sources.

Change a single limit, record the old value, and compare throttle events with access logs through the next real peak. Success is specific: guessing and floods slow down, and the shared NAT you wrote down still completes login. If good traffic is throttled, raise the limit or narrow the scope you can actually configure. If a single client can still stall the origin, the limit is too high or it is not on the path you tested.

Pair volume controls with the other documented challenges

Rate limiting is the volume tool. The same overview documents neighboring tools that answer other questions, and mixing them up is how configurations get noisy.

Captcha challenge is described as a bot control: human users are allowed, crawlers and bots are blocked. Authentication challenge asks visitors for a password or blocks them. Dynamic protection encrypts HTML and JavaScript on each visit. Those are useful beside an IP limit when the problem is automation or casual replay, not raw request rate. They are not hidden rate-limit modes, and the pages do not say they share counters with IP throttling.

A sensible order is proxy, attack-inspection check, then rate limit, then an optional challenge on the route that attracts bots. Roll back the last change if the next peak looks wrong. Also close the bypass on the origin itself by allowing only the WAF host to connect. That origin restriction is your firewall or security group, not a SafeLine feature listed in these guides. Without it, the documented reverse-proxy model is advice rather than the only door.

Review the policy when the application changes. A new login endpoint, a marketing spike, or a partner that crawls from one address can invalidate yesterday's ceiling. The WAF will keep enforcing the old definition until you change it.

What does SafeLine document about configuring rate limiting?

It documents IP-based rate limiting that throttles traffic above limits you define, aimed at DoS attacks, bruteforce attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). The supplied install and application pages do not list rate-limit fields, defaults, or commands. Configure only the limit control you can see in your console, after the app is proxied.

Does a block page mean my rate limit works?

No. The application guide's block page and attack-list detail show that SafeLine inspected a malicious-looking request and blocked it (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That verifies the reverse proxy. A rate limit still needs its own test: traffic from one IP above the limit you defined should be throttled, and traffic below it should pass.

Can I copy a threshold from somewhere else?

You should not. Nothing in the supplied official pages gives a recommended request rate. A limit that fits a static blog can lock out a shared office on a login form. Measure the origin and the busiest legitimate IP, then set the ceiling between those two facts.

How is rate limiting different from captcha or an auth challenge?

Rate limiting throttles volume that exceeds a defined limit. Captcha challenge is documented as a human-versus-bot check. Authentication challenge requires a password. Dynamic protection encrypts page code per visit (https://docs.waf.chaitin.com/en/home). Use the one that matches the failure you are seeing, and do not expect one of them to enforce another's job.

That is the main design limit of an IP-based control. Count that address as one client, measure its real peak, and set the ceiling above that peak. If the abuse you care about is automated rather than merely fast, consider the documented captcha or authentication challenge as a separate control instead of crushing the shared address.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Configure Rate Limiting with a WAF: A Checklist Before You Enforce Limits

Mon, 26 Oct 2026 02:22:29 +0000

Rate limiting looks like a settings page problem, but the useful work happens before any limit is enforced. A web application firewall sits in front of the origin and decides which HTTP traffic is allowed to continue. SafeLine describes that role as a reverse proxy: clients reach the WAF first, and only traffic that passes policy is forwarded to the application. IP-based rate limiting is one of its documented core capabilities, alongside attack defenses, proactive bot-abuse defense, HTML and JavaScript code encryption, and a web access control list (SafeLine introduction, https://docs.waf.chaitin.com/en/home).

The product page states the purpose of rate limiting directly: defend web apps against DoS attacks, brute-force attempts, traffic surges, and other abuse by throttling traffic that exceeds defined limits (SafeLine features, https://docs.waf.chaitin.com/en/home). That sentence is the whole public contract. It does not publish field names, default counters, window sizes, or a recommended number of requests per IP. If you are looking for a click-by-click recipe, the supplied configuration guide does not provide one. It documents how to place an application behind the proxy, not how to tune a throttle. The practical response is a checklist: decide what you are protecting, define the unit of traffic, separate throttling from other controls, put the proxy in the path, then measure before you block.

Start with the asset, not the slider. A login form, a search endpoint, a file download, and a public homepage do not share a sensible limit. Brute-force risk is concentrated on authentication and password-reset paths. A traffic surge may be a marketing campaign hitting the homepage. A DoS pattern may be many requests from one address, or many addresses sharing one expensive route. Write down the route, the method, and the business action before you write down a number.

Next, define the identity you can actually count. SafeLine documents IP-based rate limiting, so the documented unit is the client IP as seen by the WAF (SafeLine introduction, https://docs.waf.chaitin.com/en/home). That is useful and also incomplete as a security model. Offices, mobile carriers, and privacy relays can put many people behind one address. A single attacker can also rotate addresses. Your checklist should record whether the site has shared egress, whether you terminate TLS at SafeLine, and whether another proxy already sits in front. If another proxy is present, the address SafeLine sees may be the proxy, not the visitor. Do not assume a header rewrites that view unless you have verified it in your own deployment. The public docs supplied here do not describe header trust or rate-limit exceptions.

Separate four controls that are easy to blur together. Attack blocking is for malicious request content such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal (SafeLine features, https://docs.waf.chaitin.com/en/home). Rate limiting is for volume that exceeds a defined limit, including DoS, brute force, surges, and other abuse. A CAPTCHA challenge is documented as a way to allow human visitors while blocking crawlers and bots. An authentication challenge, when turned on, requires a visitor to enter a password or be blocked. Dynamic protection encrypts HTML and JavaScript on each visit. None of those descriptions says that one feature replaces the others. A signature can stop a malicious payload that arrives slowly. A throttle can stop a flood of otherwise ordinary requests. A challenge can slow automated clients that still stay under a crude IP cap.

Place the WAF before you judge any limit. SafeLine is described as an nginx-based HTTP and HTTPS reverse proxy that receives traffic for the original site, removes malicious attack traffic, and forwards the remaining traffic upstream (Add an application, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The documented application fields are Domain, Port, and Upstream. Port examples are 80 and 443, with SSL checked for HTTPS apps. After those settings, the domain must resolve to the SafeLine server. Until that path is real, a rate limit cannot see the traffic you intend to protect, and any number you choose is fiction.

Only then collect a baseline. For at least one normal business day, and ideally across a peak, record requests per minute for the whole site and for the sensitive routes, unique source IPs, error rates, and the slowest upstream endpoints. Note scheduled jobs, health checks, and partner integrations that look like bursts. Pick a limit above the legitimate peak with explicit headroom, then decide the action: throttle, temporary block, or a challenge if that control is already part of your policy. Roll the change out on one application, watch both blocked events and real user complaints, and keep a written rollback. The docs show that attack events can be reviewed in the web console, including an attack list and a detail view (Add an application, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Use that habit for volume events too: if you cannot explain who was limited and why, the limit is not configured, it is only enabled.

A sound configuration is therefore a short written policy: protected routes, IP as the documented counting key, a measured ceiling, an enforcement action, an exception process for shared networks, and an owner who reviews false blocks. The WAF can throttle traffic that exceeds defined limits. You still have to define them from your own traffic, because the official pages do not supply those numbers for you.

What does SafeLine document about rate limiting?

It documents IP-based rate limiting and says the feature throttles traffic that exceeds defined limits in order to defend against DoS attacks, brute-force attempts, traffic surges, and other abuse (SafeLine features, https://docs.waf.chaitin.com/en/home). It does not, in the pages used here, publish the console fields, default thresholds, or a sample policy.

Does rate limiting replace attack detection?

No. Attack defenses target malicious request classes such as injection, XSS, SSRF, and path traversal. Rate limiting targets excess volume. A rare malicious request can be dangerous without looking like a flood, and a flood can be made of requests that are individually ordinary.

Where does rate limiting fit in the request path?

SafeLine must be in front of the origin as a reverse proxy. The documented setup is an application with a domain, a listening port, an upstream address, and DNS pointed at the SafeLine server (Add an application, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Limits apply to traffic that actually arrives there.

Why is an IP limit risky for legitimate users?

Many users can share one public address, so a strict per-IP ceiling can throttle an office or a mobile network during a normal peak. Record shared-egress cases before enforcement, and review blocks against a measured baseline rather than a guessed round number.

What should I check after enabling a limit?

Confirm the domain still reaches the origin through SafeLine, compare blocked volume with the baseline, inspect console details for surprising sources, and keep a rollback if a partner, monitor, or campaign was not in the checklist. Do not treat a quiet console as proof that the limit is correct; it may only mean the threshold is too high to observe.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Protect a Next.js App with a WAF Before You Change DNS

Fri, 23 Oct 2026 04:02:28 +0000

A Next.js app is still a web application that speaks HTTP. That is the only placement fact you need before you look for a framework plugin. The SafeLine documents used here do not describe a Next.js SDK, App Router hook, or hosting-platform add-on. Treat protection as a reverse-proxy decision, then walk a checklist before you move DNS.

SafeLine is a self-hosted web application firewall. Its documentation says it filters and monitors HTTP traffic between a web application and the Internet, and that it works as a reverse proxy so clients reach the WAF before they reach the origin server (https://docs.waf.chaitin.com/en/home). The application guide says SafeLine is developed based on nginx, receives traffic for the original website, cleans malicious attack traffic, and forwards safe traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). For a Next.js deployment, the upstream is the address that actually serves the app, such as a Node process, a container, or another proxy you already operate. Do not add an undocumented Next.js middleware path and treat that path as the firewall.

Placement checklist

Start with exposure. If users already reach the app by a domain over HTTP or HTTPS, you can put SafeLine on that path. In the Web Admin Console, open Applications, choose Add Application, and enter Domain, Port, and Upstream. Domain can be a domain name, hostname, or IP address. Port is the port SafeLine listens on, such as 80 or 443, and HTTPS apps should use the SSL option. Upstream is the real address SafeLine will forward to (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). After those fields are saved, resolve the domain to the IP address of the server where SafeLine runs. Until that DNS change is correct, and until you have written down the previous origin address for rollback, the checklist is unfinished.

Confirm the host can run the proxy. The install guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB memory, and 5 GB disk. The CPU must support ssse3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). On ARM, the same guide says SafeLine requires a Pro license to work properly and that the Personal Edition is not supported. If the machine in front of Next.js is ARM and you expected the Personal Edition to run there, stop and choose another architecture or a licensed Pro install. The guide also says the LTS line will no longer be maintained starting from 9.1.0-LTS (14 August 2025), and it recommends the latest version if you have concerns about staying on that line.

Choose controls from the documented list only. The product page lists defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). Named coverage includes SQL injection, XSS, code injection, os command injection, CRLF injection, ldap injection, xpath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, http-flood, and bot abused. Rate limiting throttles traffic that exceeds defined limits, including DoS attacks, bruteforce attempts, traffic surges, and other abuse. A CAPTCHA challenge is described as allowing human users through while blocking crawlers and bots. An authentication challenge, when turned on, requires visitors to enter the password or be blocked. Dynamic protection, when turned on, dynamically encrypts HTML and JS code on each visit.

Those controls are relevant because a Next.js app still emits HTML and JavaScript and still accepts HTTP requests on pages, route handlers, and other endpoints. They do not replace validation, authorization, or secret handling in application code. Nothing in these sources says dynamic encryption understands a particular Next.js rendering mode, or that it replaces a policy you set in the app. There is also no documented promise that a strict policy will ignore harmless JSON, file uploads, or query strings that your routes legitimately use. That is why the checklist includes a real-user retest, not only attack samples.

As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price. The documentation also calls the product production-ready, protecting over 1,000,000 websites and handling over 30,000,000,000 HTTP requests daily (https://docs.waf.chaitin.com/en/home). Read those scale statements as product context, not as a forecast for your own site. The same page reports an effect evaluation on 33669 samples: SafeLine, Balance showed 71.65% detection, 0.07% false positives, and 99.45% accuracy, while SafeLine, Strict showed 76.17% detection, 0.22% false positives, and 99.38% accuracy. Match the stricter profile to a site that can tolerate more false positives, and retest real Next.js routes before you leave it on.

Verification checklist

After the application is proxied, use the test cases in the application guide and replace the sample domain with yours. The guide lists SQL injection, XSS, path traversal, code injection, and XXE-style query examples (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A blocking page means SafeLine stopped that request. Then open the console attack list and use the detail view. Also request a normal page, a client-side navigation, and one legitimate POST that your users need. A proxy that stops the samples but breaks a real form is not done.

Keep the management console off the public app hostname unless you intend to expose it. The install guide opens the console at https://<safeline-ip>:9443/ and creates the first administrator with docker exec safeline-mgt resetadmin (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Store that initial password outside the Next.js repository. Record the upstream URL, the listen port, whether SSL is enabled, and the DNS rollback value in the same change note.

Does SafeLine ship a Next.js integration?

No. The install guide, the application guide, and the product overview used here describe a reverse proxy and an application record. They do not describe a Next.js plugin, middleware package, or platform add-on. The working record is domain, listen port, SSL when needed, and upstream.

Can the Next.js process keep its current port?

Yes, if that port is the upstream SafeLine forwards to. SafeLine listens on the port you configure, commonly 80 or 443, while the origin can remain on an internal port. The public domain must resolve to the SafeLine server, which is the change you should not make until the checklist above is filled in.

Which Next.js defects does this checklist remove?

It does not patch framework defects. It can filter HTTP attack classes named in the product documentation, throttle traffic over defined limits, challenge bots, require a password gate, and encrypt HTML and JS when dynamic protection is enabled. Authorization inside route handlers remains an application problem.

Should every challenge be enabled on the first day?

No. CAPTCHA, the authentication challenge, rate limiting, and dynamic HTML and JS encryption are separate features. Turn on the ones that match abuse you can name, then repeat the legitimate page and POST checks. A public marketing route and a signed-in app route do not need the same gate.

Which host choice blocks the Personal Edition?

ARM does. The deploy guide says a Pro license is required on ARM and that the Personal Edition is not supported there. Before you call the checklist complete, also confirm Docker, Docker Compose, disk, memory, and the ssse3 instruction on the SafeLine host, and prefer a maintained release over the unmaintained LTS line.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Protect a Next.js App When No Framework Plugin Exists

Fri, 23 Oct 2026 04:01:56 +0000

If you are asking how to protect a Next.js app with a WAF, start by rejecting the idea of a hidden framework connector. The SafeLine documents supplied here never mention Next.js, React Server Components, a middleware file, or a platform add-on. They describe a self-hosted web application firewall that sits in front of a web application and filters HTTP traffic. The honest guide is a decision checklist: either your Next.js origin can sit behind that reverse proxy, or this product path does not fit. Do not fill the gap with an integration the sources do not describe.

SafeLine protects web apps by filtering and monitoring HTTP traffic between the application and the Internet. Deployed in front of the app, it is a reverse proxy: clients pass through it before they reach the server, and it blocks malicious HTTP and HTTPS traffic according to policy (https://docs.waf.chaitin.com/en/home). The application guide adds that SafeLine is developed based on nginx, receives traffic for the original site, cleans malicious attack traffic, and forwards safe traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A Next.js server is in scope only as that upstream. Page routes, API routes, and form posts are protected to the extent they arrive as HTTP requests the proxy can see.

Run the fit checklist before DNS cutover

Work through these gates in order. A later control cannot repair a failed gate.

First, confirm you own an upstream address. In the console you add an application with a Domain, a listen Port, and an Upstream. Domain may be a domain name, a hostname, or an IP address. Port is what SafeLine listens on, such as 80 or 443, and HTTPS applications should use the SSL option. Upstream is the real address of the original app (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). For Next.js, that upstream is the host and port of the Node process or container you actually run. If the app is hosted where you cannot place your own reverse proxy in front of it, stop. These pages do not document another mode.

Second, plan the client path. After the application record exists, you resolve the domain to the IP of the SafeLine server and reach the protected app through that domain. If visitors can still open the Next.js port directly, the WAF is optional and the exposure remains. Write the public port and the upstream port on two lines so Upstream never points back at SafeLine itself.

Third, check the WAF host against the deploy guide before you promise a launch date. SafeLine expects Linux on x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU also needs the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM install requires a Pro license to work properly. The Personal Edition is not supported on ARM. The LTS release is no longer maintained starting from 9.1.0-LTS on 14 August 2025, and the guide strongly recommends moving to the latest version, or waiting about a month after a new release if you want a calmer upgrade.

Fourth, separate the management plane from the app plane. The web console is served at https://<safeline-ip>:9443/. The initial administrator account is created with docker exec safeline-mgt resetadmin, which prints the initial username and password. Store that password. Do not assume the console is protected just because the Next.js site is.

Fifth, decide which documented controls match this app, and leave the rest off until you have evidence. The core list is defenses for web attacks, proactive bot abused defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). Rate limiting is documented against DoS attacks, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is documented to allow human users and block crawlers and bots. An authentication challenge requires a password before the visitor continues. Dynamic protection, when turned on, dynamically encrypts HTML and JS from the web server on each visit.

Map those controls onto Next.js without inventing a parser

Next.js does not get a special inspection profile in these documents. What you can say is narrower and still useful. A production Next.js app usually publishes HTML, JavaScript, and JSON over HTTP. Those are the surfaces the documented feature list talks about. The attack categories named on the product home page include SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse, among others. The application guide uses query-string trial cases for SQL injection, XSS, path traversal, code injection, and XXE, then expects a blocking page and an entry in the attack list with a detail view.

Use that as a verification method, not as a claim that every Next.js bug class is covered. Replay the guide sample cases against your domain after DNS points at SafeLine. Confirm the block page. Open the attack detail. Then exercise a normal page load, a normal API call, and a normal form post so you can see whether a strict policy collides with legitimate traffic. The home page publishes an evaluation table, but this checklist does not treat that table as a sizing tool for your app.

Rate limiting belongs in the first tuning pass if the Next.js app has a login, a search box, or any route that triggers expensive server work. Bot and CAPTCHA controls belong next if anonymous clients scrape or hammer the site. The authentication challenge is a site gate, not your session implementation. Dynamic HTML and JS encryption is a documented option for pages that serve HTML and JS, which Next.js does, but the docs do not say it is required, and they do not say it is aware of client rendering. Turn it on only after a page-level test.

Keep the claims inside the sources

SafeLine states that it is production-ready, that it protects over 1,000,000 websites, and that it handles over 30,000,000,000 HTTP requests daily (https://docs.waf.chaitin.com/en/home). As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price. Those figures help a budget conversation. They do not change the install floor, and they do not prove that a minimal 1 core and 1 GB host will carry your traffic. The deploy guide gives a minimum, not a capacity plan.

I would also refuse three common overclaims. There is no documented command that installs SafeLine inside a Next.js repository. There is no documented connector for a hosted frontend platform that will not let you set an upstream. There is no documented promise that proxy filtering replaces authorization, output encoding, or dependency patching inside the app. The WAF can filter, monitor, and block malicious HTTP traffic, and the home page also says it prevents unauthorized data from leaving the app by applying policy. That is a proxy control. It is not a code review.

If the checklist fails at upstream ownership or DNS placement, do not publish a protected label. A request that never passes through SafeLine is outside every feature named above.

Does SafeLine document a Next.js integration?

No. The install and application guides describe a reverse proxy and an application record. They do not document a Next.js package, config plugin, middleware hook, or server-action mode. If you cannot proxy the origin, this setup is the wrong fit.

Which fields matter when the upstream is a Next.js server?

Domain, Port, and Upstream. Domain is the name clients use. Port is the SafeLine listen port, with SSL checked for HTTPS. Upstream is the real Next.js address. After saving, resolve that domain to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

What should I test on the first day?

Use the application guide sample cases for SQL injection, XSS, path traversal, code injection, and XXE, with your domain in place of the sample host. Expect the blocking page, then check the attack list and the detail view. Also send ordinary page, API, and form traffic so a policy problem is visible before users are.

When is dynamic protection a reasonable option?

When you want the documented behavior: HTML and JS encrypted dynamically on each visit. It is listed with the other main features, not as a Next.js switch (https://docs.waf.chaitin.com/en/home). Test real pages first. Do not treat it as a substitute for safe rendering in the app.

What host and license facts should a buyer check?

Linux, x86_64 or arm64, current Docker and Compose versions from the deploy guide, ssse3, and at least 1 core, 1 GB of memory, and 5 GB of disk. ARM needs a Pro license; the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide, and SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

The Importance of Reliable Internet Infrastructure for Modern Businesses

Fri, 21 Aug 2026 00:04:06 +0000

Modern businesses depend on reliable digital infrastructure to operate efficiently. From online services and software platforms to global research and automation systems, stable connectivity plays an important role in daily operations.

As companies expand into international markets, they often need access to different regions, networks, and online environments. Reliable IP infrastructure helps organizations test services, analyze markets, and manage digital workflows more effectively.

Proxy technology has become an important part of modern internet infrastructure. It allows businesses and developers to create flexible connections for different technical requirements.

Professional solutions such as those available through the AccsTrust shop help companies access proxy infrastructure designed for various online workflows:

https://accstrust.com/shop

A strong digital foundation allows businesses to improve efficiency, scale operations, and adapt to changing online requirements.

Heimdall MCP

Mon, 11 May 2026 17:41:11 +0000

If you've been building with MCP servers lately, you've probably hit this wall: something goes wrong (or just feels slow) and you have zero visibility into what actually happened.

Which tool did Claude call? What input did it send? Did the server error silently? How long did it take?

That's the gap Heimdall fills.

What is Heimdall?

Heimdall is a transparent proxy for MCP servers. It sits between your MCP client (Claude Desktop, OpenCode, Cursor, or any other) and your MCP server — local or remote — and records every interaction as an OpenTelemetry span.

No modifications to your server. No SDK to integrate. No infra to run. Just wrap your existing server and start seeing what's happening inside.

The name comes from Norse mythology: Heimdall is the guardian of the Bifrost bridge, with the ability to see and hear everything that crosses between worlds. That's exactly the role this proxy plays.

The problem in one screenshot

You're running a Claude agent that orchestrates 5+ MCP tools. One of them is consistently slow. Another occasionally returns empty results. You have no way to know which one, when, or why — unless you dig into logs manually.

With Heimdall, every tool call becomes a structured span:

{
  "name": "mcp.tool.call",
  "attributes": {
    "gen_ai.tool.name": "search_documents",
    "mcp.duration_ms": 843,
    "mcp.status": "ok"
  },
  "events": [
    { "name": "request",  "body": { "query": "quarterly report" } },
    { "name": "response", "body": { "results": [...] } }
  ]
}

Stored. Queryable. Yours.

Zero config wrapping via mcp.json

The easiest way to use Heimdall requires zero access to the server's source code. Just install it globally and update your mcp.json:

npm install -g @cardor/heimdall-mcp

Before — your current config:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["my-server.js"]
    }
  }
}

After — wrapped with Heimdall:

{
  "mcpServers": {
    "my-server": {
      "command": "heimdall",
      "args": [
        "--store", "sqlite://~/.heimdall/traces.db",
        "--",
        "node", "my-server.js"
      ]
    }
  }
}

That's it. Restart your client and every tool call starts being recorded. The -- separator tells Heimdall where its args end and the real server command begins.

For remote servers (HTTP or SSE), it's just as simple:

{
  "mcpServers": {
    "remote-server": {
      "command": "heimdall",
      "args": [
        "--store", "postgres://user:pass@localhost/mydb",
        "--target", "http://my-remote-mcp.com/sse"
      ]
    }
  }
}

Heimdall exposes stdio to your client, talks HTTP/SSE to the real server, and intercepts everything in between.

What gets recorded

Heimdall captures all standard MCP events:

Event	What's recorded
`tools/call`	Tool name, input args, response, duration, status
`tools/list`	Available tools and their schemas
`resources/read`	URI, MIME type, response size
`prompts/get`	Prompt name, arguments, rendered output
`initialize`	Client/server versions, negotiated capabilities
`shutdown`	Total session duration

Every span follows the OpenTelemetry gen_ai.* semantic conventions, so if you later want to send traces to Jaeger, Honeycomb, or Grafana Tempo, the data is already well-formed.

Storage options

Pick the backend that fits your setup:

SQLite — local file, zero infra

--store sqlite://./traces.db
# or with absolute path
--store sqlite:///Users/you/.heimdall/traces.db

Best for: local development, single-machine setups, quick debugging sessions.

Uses @libsql/client under the hood — pure WASM, no native bindings, no node-gyp.

Postgres — your existing database

--store postgres://user:password@localhost:5432/mydb

Best for: production environments, teams sharing observability data, long-term storage with SQL queries across multiple servers.

MySQL

--store mysql://user:password@localhost:3306/mydb

Same use case as Postgres. Pick whichever you already run.

All three use drizzle-orm with a shared schema, so the query experience is consistent regardless of which backend you choose.

Using it as a TypeScript library

If you have access to your server's code and want tighter integration, Heimdall ships as a fully-typed TypeScript library with a fluent builder API:

import { McpProxy } from 'heimdall-mcp'

const proxy = await McpProxy
  .create()
  .inbound({ transport: 'stdio' })
  .outbound({ transport: 'http', url: 'http://localhost:3001' })
  .store('sqlite://./traces.db')
  .build()

await proxy.start()

You can also plug in custom interceptors — for example, to redact sensitive fields before they're persisted, or to add your own business logic on top of the tracing:

import { McpProxy, type Interceptor } from 'heimdall-mcp'

// Custom interceptor: redact API keys from tool inputs before storing
const redactSecrets: Interceptor = {
  name: 'redact-secrets',
  async intercept(request, ctx, next) {
    const sanitized = redactSensitiveFields(request)
    return next(sanitized)
  }
}

const proxy = await McpProxy
  .create()
  .inbound({ transport: 'stdio' })
  .outbound({ transport: 'http', url: 'http://localhost:3001' })
  .store('postgres://user:pass@host/db')
  .intercept(redactSecrets)
  .build()

Design goals

A few decisions worth calling out:

No native dependencies. SQLite runs via WASM (@libsql/client), Postgres via the pure-JS postgres package, MySQL via mysql2. You can install and run Heimdall in any Node 22+ environment without compilation steps.

Transport mixing. Your client connects via stdio. Your server can be stdio, HTTP, or SSE. Heimdall bridges them transparently — useful for wrapping local CLI servers behind an HTTP interface without touching their code.

Get started

npm install -g @cardor/heimdall-mcp

GitHub: github.com/enmanuelmag/heimdall-mcp
Website: https://stack.cardor.dev/heimdall

If you try it out, I'd love to hear what you think — especially feedback on the interceptor API design and the OTel schema. Open an issue or find me on X \[@enmanuelmag\].

How to Configure Nginx as a Proxy Server?

Fri, 01 May 2026 11:10:59 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article we could able to server simple html page.

Now lets see how to use nginx as a proxy server.

Setting Up a Simple Proxy Server

One of the frequent uses of nginx is setting it up as a proxy server, which means a server that receives requests, passes them to the proxied servers, retrieves responses from them, and sends them to the clients.

We will configure a basic proxy server, which serves requests on behalf of another server running in port 8080.

Here is example of how to configure it.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        location / {
            proxy_pass http://localhost:8080; # Proxies traffic to the backend on 8080

        }
    }
}

This will be a simple server that listens on the port 8080.

Add Static Files For Existing Proxy Server

let's assume we have a static files in /var/www/html directory and we want to server another application running on port 8080.

so, we can configure both these in nginx it self.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        location / {
            proxy_pass http://localhost:8080; # Proxies traffic to the backend on 8080

        }

        location /static/ {
            root /var/www/html; # Serves static files from /var/www/html
        }
    }
}

This way we will be able to serve both static files and other server running in port 8080.

Conclusion

We could able to setup simple proxy server and serve both static files and other server running on different port.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

My favorite failed attempt at JS syntax sugar—TS unions via BigInt masks and proxies.

Fri, 26 Sep 2025 02:22:54 +0000

Pipetype: TypeScript Unions ≈ Bitwise Operators, and My Favorite Failed Experiment

Note: This is an actual library: https://github.com/overthemike/pipetype

1. A Tale of Two Pipes `|`

JavaScript is full of quirks, but few quirks are as weird and interesting as humble vertical bar: |.

In TypeScript, | is the union operator:

type ID = string | number

→ “Either-or.” A value can be a string, or a number.

In JavaScript’s bitwise world, | flips switches:

1  |  2  //  3

0001 | 0010  ←  `|` tells you to look at each bit of both numbers and if either are present, mark it: 1, otherwise: 0
Let's put organize them vertically to make it easier to see.

0001  ←  1
0010  ←  2
  ↓↓
0011  ←  3

→ “Both at once.” A new number with two switches turned on.

Two worlds. Same symbol. Different vibes.
And yet… they kind of rhyme.

TypeScript unions = a value can be validated by any of these types.
Bitwise OR = turn on any combination of these flags.

This has all of the markings of my newest rabbit hole experiment. How much and how close could we replicate TypeScript syntax at runtime?

2. BigInt Joins the Party

Bitwise tricks are fun, but JavaScript numbers only give you 53 safe bits.

That’s like having a switchboard with only 53 buttons:

  [ 1 ]  [ 2 ]  [ 3 ]  ...  [ 53 ]

Great for a small project. Terrible when you want an arbitrary number of unions.

Enter BigInt. No limit on bits.

  [ 1 ]  [ 2 ]  [ 3 ]  ...  [ 1,000,000+ ]

Infinite lockers. Infinite switches. No more ceiling.

BigInt became the foundation: every validator gets its own bit in an infinite skyline.

3. Bits as Pointers: The Validator Map

The whole trick works because each validator needs a unique bit — like giving every locker in a hallway its own light switch.

3.1 Bit Shifting 101

We start with the number 1n. In binary, that looks like:

1n = 0b0001
// '0b' is the prefix for binary

Now apply a left shift (<<):

1n << 0n → don’t move it → 0001 (still 1n)
1n << 1n → move left once → 0010 (2n)
1n << 2n → move left twice → 0100 (4n)
1n << 3n → move left three times → 1000 (8n)

Each shift is multiplying by 2 — giving us the sequence of powers of 2:

1n, 2n, 4n, 8n, 16n, ...

That’s why shifting is so useful here: every shift guarantees only one bit is on, so no two validators collide.

Start:  0001  (1n)

<< 1 →  0010  (2n)

<< 1 →  0100  (4n)

<< 1 →  1000  (8n)

3.2 Using Shifts for Validators

This is how we assign unique “slots” for our validators:

const validators = new Map<bigint, (x: unknown) => boolean>()

validators.set(1n << 0n, (x) => typeof x === "string") // 0001
validators.set(1n << 1n, (x) => typeof x === "number") // 0010
validators.set(1n << 2n, (x) => Array.isArray(x))      // 0100

Now, combining them is easy with |:

string | number → 0001 | 0010 = 0011 (3n)

And testing is easy with &:

0011 & 0010 = 0010 → includes "number"
0011 & 0100 = 0000 → does NOT include "array"

3.3 Feels Like Math Homework

This works, but writing 1n << 0n, 1n << 1n, 1n << 2n everywhere gets old fast.

So, we add a helper: getNextFlag() — so we can just ask for “the next available bit” instead of shifting by hand.

let lastFlag = 0n;

function getNextFlag(): bigint {
  lastFlag = lastFlag === 0n ? 1n : lastFlag << 1n;
  return lastFlag;
}

3.4 Cleaner Validator Setup

Now assigning validators looks like this:

const validators = new Map<bigint, (x: unknown) => boolean>();

validators.set(getNextFlag(), (x) => typeof x === "string") // 0001
validators.set(getNextFlag(), (x) => typeof x === "number") // 0010
validators.set(getNextFlag(), (x) => Array.isArray(x))      // 0100

Much easier to read, but you still know what’s happening under the hood: each new flag is just another power of 2.

4. Proxy: Turning Math into Sugar

All of this is neat, but nobody wants to write flags all day.

That’s where Proxy shines: we intercept property access and generate flags on the fly.

const Type = new Proxy({}, {
  get(_, key: string) {
    const bit = getNextFlag()
    validators.set(bit, (x) => typeof x === key)
    return bit
  }
})

const myType = Type.string | Type.number

Now it looks like TypeScript.

Runtime JavaScript:

// defined elswhere
const string = Type.string((val) => typeof val === 'string')
const number = Type.number((val) => typeof val === 'number')

// your file
import { Type, string, number } from './types'

Type.StringOrNumber = string | number

Underneath:

0001 | 0010 → 0011

It’s really just syntactic sugar. JavaScript pretending to be TypeScript.

Well, it was. It's not really that useful.

5. The Dream vs. The Reality

At this point, the experiment felt magical:

Ergonomic unions at runtime.
BigInt masks for infinite validators.
Syntax that looked like TypeScript.

But then reality hit.

TypeScript’s compiler can’t see through BigInt.

From the type system’s perspective, these masks were just numbers. Opaque. Un-inferable.

The magic broke. Without inference, the ergonomics collapsed.
TypeScript couldn’t narrow. Couldn’t hint. Couldn’t help.

What started as sweet sugar ended as brittle runtime math.

There are ways of doing it, but they get kind of ugly. We already have fantastic and full-featured libraries like zod and valibot that bring inference for free for just a small syntax fee comparatively.

6. My Favorite Failed Experiment

That’s when I had to admit it: Pipetype failed.

It wasn’t the tool that would unify runtime and compile-time unions. It was a clever curiosity that buckled under TypeScript’s strict compiler gaze.

But I still love it.

It taught me how far | can stretch.
It showed me how BigInt changes the playground.
It reminded me how Proxies can cosplay as syntax.

Sometimes your best experiments are the ones that fail, because they teach you where the limits really are.

Appendix: Deep Cuts

Bitwise as Lockers: OR (|) opens multiple lockers. AND (&) checks if a locker belongs.

0101 & 0001 → true  (locker 0 included)
0101 & 0010 → false (locker 1 not included)

BigInt for Infinite Validators: Beyond 53 bits, normal numbers wobble. BigInt? Infinite switches.
Proxy for Sugar: Type.string wasn’t a string. It was a BigInt mask.
Why It Failed: No TypeScript inference. Without narrowing, runtime unions lost their edge.

That’s Pipetype: a mash-up of unions and bitmasks, Proxies and sugar, BigInts and dreams — and the lesson that sometimes failure is the most fun of all.

Under the hood explanation of Immer library.

Tue, 24 Jun 2025 15:26:14 +0000

Immer (German for: always) is a tiny package that allows you to work with immutable state in a more convenient way.

— Immer Documentation

Immer uses Proxies under the hood and therefore to understand the details of this library we need to know a little about proxies. So..

What is a Proxy? Let’s refer to javascript.info

A Proxy object wraps another object and intercepts operations, like reading/writing properties and others

The syntax to create a Proxy:

let proxy = new Proxy(target, objectTrap)

Notice in the above snippet I have introduced a term called objectTrap. We need to understand it because it is one of the key ideas used by the library to do its deeds. So..

Let’s google what does a object trap in proxy do?

In the context of JavaScript Proxies, a “trap” refers to a handler function that intercepts and modifies how specific operations are performed on the target object.

An example to understand how exactly this works.

 let user = {
  name: "John",
  _password: "***"
};
user = new Proxy(user, {
  get(target, prop) {
    if (prop.startsWith('_')) {
      throw new Error("Access denied");
    }
    return target[prop];
  },
});

In the above snippet, user is born as an object but is eventually christened into a proxy with an objectTrap that has a get function defined on it. Now, when we call user[“_password”], the get method inside the objectTrap will be triggered and give us an error. I hope you all get the basic idea of proxy.

Now, let’s look at the relevant objectTrap code in the library:

const objectTraps = {
    get(target, prop) {
      if (prop === isProxySymbol) return target;
      return createProxy(target)[prop];
    },
    set(target, prop, value) {
      const current = createProxy(target)[prop];
      const newValue = createProxy(value);
      if (current !== newValue) {
        const copy = getOrCreateCopy(target);
        copy[prop] = isProxy(newValue) ? newValue[isProxySymbol] : newValue;
      }
      return true;
    }}

For now, all that we must understand is that the above objectTrap is overriding reading and writing of object properties via the get and set methods and these methods are purely working with proxies rather than the direct objects which we provide to the library. Now, it is time to look at an example code which uses immer to mutate an object:

const baseState = {
  name: "John",
  age: 20,
  address: {
    city: "New York",
  },
};

const thunk = (draft) => {
  draft.name = "Jane";
  draft.address.city = "Los Angeles";
  draft.newKey = "newKey";
};

const newState = immer(baseState, thunk);

So, let’s try to understand the above code which uses Immer to mutate an object.

Here, we are trying to update the name and city which is a property inside address and add a new property called newKey. Notice that the callback provided to the immer function directly mutates the draft object. This is the power of the library-it allows us to update the object directly, without having to create a copy as we typically do when updating a React state object.

Let’s now dig into the immer function.

The immer function first creates a proxy object from the given baseState and here is the library code that does that:

const rootClone = createProxy(baseState);

let’s look at the implementation of createProxy:

function createProxy(base) {
    if (isPlainObject(base) || Array.isArray(base)) {
      if (isProxy(base)) return base; // avoid double wrapping
      if (proxies.has(base)) return proxies.get(base);
      const proxy = new Proxy(base, objectTraps);
      proxies.set(base, proxy);
      return proxy;
    }
    return base;
  }

So, createProxy creates a proxy for the base state and adds it to a private map called proxies. This is used by the library to track all the proxies that have been created.

After createProxy the library invokes the thunk function like so:

thunk(rootClone);

So, what is happening?

rootClone, which is a proxy, is passed to the callback we provided to the Immer function. For now, it may not be clear what is happening, so let's look at the last function that Immer calls and then come back here:

return finalize(baseState);

The library is invoking the final function with baseState which is confusing. At this point, I had the following question in my mind:

How does it track all the changes made to the proxy and how does it
merge with the baseState?

Its time, let’s take a look at what happens when we invoke the thunk with the proxy called rootClone

Take a look at the thunk again:

const thunk = (draft) => {
  draft.name = "Jane";
  draft.address.city = "Los Angeles";
  draft.newKey = "newKey";
};

So, the draft object that the library passes to the thunk is a proxy. We also know that when we access or assign a property on the proxy, the object trap is invoked. For example, in draft.name = "Jane";, we are assigning a property, so the set trap is triggered. Let’s take another look at the set trap:

set(target, prop, value) {
      const current = createProxy(target)[prop];
      const newValue = createProxy(value);
      if (current !== newValue) {
        const copy = getOrCreateCopy(target);
        copy[prop] = isProxy(newValue) ? newValue[isProxySymbol] : newValue;
      }
      return true;
    }

For draft.name = "Jane"; let’s log the values of target, prop, value.

console.logs:

target { name: 'John', age: 20, address: { city: 'New York' } }
prop name
value Jane

Let’s walk through the code of set trap. First, it creates a proxy for the target object and looks up its name property and then assign it to current and then creates a proxy for value and assign it to newValue

If current and newValue are different it invokes getOrCreateCopy on target and assign it to copy. So let’s stop here and dig a little deeper on the implementation details of the function getOrCreateCopy

Implementation of getOrCreateCopy in the library:

function getOrCreateCopy(base) {
    let copy = copies.get(base);
    if (!copy) {
      copy = Array.isArray(base) ? base.slice() : Object.assign({}, base);
      copies.set(base, copy);
    }
    return copy;
  }

Notice, the copies map. copies along with proxies keeps track of the changes made to the baseState.

The above function is straightforward: if base is not found in copies, a copy of that object is made and copies is updated.

Now, let’s go back to set trap. When current and newValue is different it creates a copy for that target by invoking getOrCreateCopy function and updates the given prop value of that copy with the newValue and returns true.

So what have we learnt till now. Let’s summarise:

immer invokes the thunk by passing it a proxy.
whenever a proxy is created the proxies map is updated accordingly.
when we try to get or set any property on the proxy, it is intercepted by the corresponding
trap functions, which update the copies map accordingly.

So, let’s simplify this ongoing agony and assume that the thunk has completed its execution and therefore the proxies map and copies map are updated accordingly.

Let’s log the final proxies after the thunk gets executed:

Map(2) {
  { name: 'John', age: 20, address: { city: 'New York' } } => { name: 'John', age: 20, address: { city: 'New York' } },
  { city: 'New York' } => { city: 'New York' }
}

Similarly, Let’s log the final copies

Map(2) {
  { name: 'John', age: 20, address: { city: 'New York' } } => {
    name: 'Jane',
    age: 20,
    address: { city: 'Los Angeles' },
    newKey: 'newKey'
  },
  { city: 'New York' } => { city: 'Los Angeles' }
}

Now, let’s again go back to the final function call in the immer function:

return finalize(baseState);

Implementation of finalize:

function finalize(thing) {
    if (!hasChanges(thing)) return thing;
    const copy = getOrCreateCopy(thing);
    Object.keys(copy).forEach((prop) => {
      copy[prop] = finalize(copy[prop]);
    });
    return copy;
  }

Implementation of hasChanges:

function hasChanges(base) {
    const proxy = proxies.get(base);
    if (!proxy) return false; // nobody did read this object
    if (copies.has(base)) return true; // a copy was created, so there are changes
    // look deeper
    const keys = Object.keys(base);
    for (let i = 0; i < keys.length; i++) {
      const value = base[keys[i]];
      if (isPlainObject(value) && hasChanges(value)) return true;
    }
    return false;
  }

Finally, we meet recursion. So, in simple words finalize checks if there is a change in the given object and peaks into copies and return the appropriate value by recursively walking through the copy object.

Just read through the implementation of finalize and hasChanges, it’s easy to see how they use proxies and copies to reconstruct the given baseState with its updated parts and return it to the user.

That is all for now. This is a hobby blogpost to document by diggings into the source code of various libraries that I have used or come to admire. At the current amount I am trying to understand fixi.js and preact/signals. I hope that I would be able to write a more clear blogpost on these libraries in the future.

Thanks for reading and for being patient. I’m open to any feedback!

Coder Legion - Recent posts tagged proxy

How to Use a WAF with Let's Encrypt Automatic HTTPS Without Guessing Renewal

Does SafeLine issue or renew Let's Encrypt certificates?

Is the SSL checkbox the same as automatic HTTPS?

What fails if DNS moves before a renewal test?

Does the upstream have to be HTTPS too?

What should I verify on the SafeLine host first?

How to Use a WAF with Let's Encrypt Automatic HTTPS: A Cutover Checklist

What the console actually documents

Checklist before you automate renewal

Prove the proxy, not the certificate story

What to record for the next renewal

Does SafeLine issue Let's Encrypt certificates automatically?

Where should the public certificate be presented?

Can I validate Let's Encrypt through the WAF?

Which SafeLine controls can interfere with automation?

What should I test after the DNS cutover?

How to Decide Whether a WAF Belongs Behind Cloudflare or Any CDN

Does SafeLine document putting sites behind Cloudflare?

What should resolve to the SafeLine address?

Can MGT_PROXY place the WAF behind a CDN?

What breaks if a CDN connects to SafeLine?

How do I confirm SafeLine inspected a request?

How to Judge a WAF Behind Cloudflare or Any CDN

Does SafeLine document a Cloudflare or generic CDN mode?

Which name has to point at SafeLine?

Can MGT_PROXY put a website behind a CDN?

What becomes unproven if every client shares one CDN address?

How do I show that SafeLine blocked the request rather than the CDN?

How to Configure Rate Limiting with a WAF Without Guessing the Ceiling

Confirm the reverse proxy before you throttle anyone

Treat the documented identity as the whole identity

Choose the number from your origin, then watch the first peak

Pair volume controls with the other documented challenges

What does SafeLine document about configuring rate limiting?

Does a block page mean my rate limit works?

Can I copy a threshold from somewhere else?

How is rate limiting different from captcha or an auth challenge?

What if legitimate users share a single public IP?

How to Configure Rate Limiting with a WAF: A Checklist Before You Enforce Limits

What does SafeLine document about rate limiting?

Does rate limiting replace attack detection?

Where does rate limiting fit in the request path?

Why is an IP limit risky for legitimate users?

What should I check after enabling a limit?

How to Protect a Next.js App with a WAF Before You Change DNS

Placement checklist

Verification checklist

Does SafeLine ship a Next.js integration?

Can the Next.js process keep its current port?

Which Next.js defects does this checklist remove?

Should every challenge be enabled on the first day?

Which host choice blocks the Personal Edition?

How to Protect a Next.js App When No Framework Plugin Exists

Run the fit checklist before DNS cutover

Map those controls onto Next.js without inventing a parser

Keep the claims inside the sources

Does SafeLine document a Next.js integration?

Which fields matter when the upstream is a Next.js server?

What should I test on the first day?

When is dynamic protection a reasonable option?

What host and license facts should a buyer check?

The Importance of Reliable Internet Infrastructure for Modern Businesses

Heimdall MCP

What is Heimdall?

The problem in one screenshot

Zero config wrapping via mcp.json

What gets recorded

Storage options

SQLite — local file, zero infra

Postgres — your existing database

MySQL

Using it as a TypeScript library

Design goals

Get started

How to Configure Nginx as a Proxy Server?

Setting Up a Simple Proxy Server

Add Static Files For Existing Proxy Server

Conclusion

My favorite failed attempt at JS syntax sugar—TS unions via BigInt masks and proxies.

1. A Tale of Two Pipes `|`