# Citrix NetScaler Rewrite & Responder — AppExpert Policy Engine Deep Dive

Source: https://ai.techclick.in/blog_citrix_netscaler_rewrite_responder_appexpert
Markdown: https://ai.techclick.in/blog_citrix_netscaler_rewrite_responder_appexpert.md
Publisher: Techclick Infosec Pvt Ltd

Master Citrix NetScaler (ADC) AppExpert policies in 2026: rewrite actions, responder policies, default-syntax advanced expressions, policy bind points and evaluation order — with real use cases and interview tips.

Citrix NetScaler Rewrite &amp;amp; Responder — AppExpert Policy Engine Deep Dive student learning map
                     A visual study map for Citrix NetScaler Rewrite &amp;amp; Responder — AppExpert Policy Engine Deep Dive showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Citrix NetScaler Rewrite &amp;amp; Responder — AppExpert...
                     Citrix · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   🎯 By the end you will be able to

   2. Understand
   Pick where you want to start

   3. Prove
   ① The AppExpert policy model —...

   4. Practice
   ② Rewrite policies — transparent...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

             Most engineers think…

             Most people treat NetScaler policies as 'the magic rewrite box' — paste a command from a forum, it works, move on. That works until it doesn't, and then no one knows why the policy isn't firing.

 The real model is three parts: an  expression  that matches traffic, an  action  that transforms or replies, and a  bind point  that anchors the policy to a specific stage in the pipeline. Once you see those three parts clearly — and understand that  priority number  controls order, not the order you typed the commands — you can write, debug and migrate any rewrite or responder policy from first principles.

## ① The AppExpert policy model — expression, action, bind point

 Every NetScaler AppExpert policy has exactly three parts. The  expression  (written in advanced default-syntax) evaluates incoming or outgoing traffic and returns true or false. The  action  is what happens when it is true — for rewrite: insert, replace, or delete a header; for responder: redirect, drop, or send an HTML page. The  bind point  says  where in the pipeline  the policy is applied: on the request path, the response path, a specific virtual server, global, or a named policy label.

 NetScaler AppExpert uses the  advanced default-syntax  for all new policies. Expressions start with the traffic object ( HTTP.REQ ,  HTTP.RES ,  CLIENT.IP ) and chain methods:  HTTP.REQ.URL.STARTSWITH(&quot;/api/&quot;) . The evaluator short-circuits left-to-right, so put the cheapest check first.

 When multiple policies match, NetScaler picks the one with the  lowest bind priority number  that is true — this is the single most important rule for debugging unexpected behaviour. If no policy matches, the default action (NOOP for rewrite, NOOP for responder) is taken.

  Figure 1 — AppExpert policy evaluation pipeline
   Every HTTP request passes through four decision points before reaching the backend — expressions gate each stage.
- AppExpert policy evaluation pipeline Client request hits vServer Responder eval reply now or pass Rewrite eval modify request Backend sees final request Rewrite eval modify response Every HTTP request passes through four decision points before reaching the backend — expressions gate each stage. Quick check · Q1 of 10 · Understand A NetScaler AppExpert policy that evaluates to true but has no matching action is configured as… a) A syntax error — every policy must have an action b) A policy with a NOOP action, which passes traffic through unchanged c) A global bind by default d) A policy label entry point Correct: b. NOOP is a valid action for both rewrite and responder. It means the policy matched but no modification is made — useful to deliberately stop chain evaluation or as a placeholder. 👉 So far: AppExpert = expression (matches traffic) + action (rewrite or respond) + bind point (where in the pipeline). Priority number controls order — lower fires first. ## ② Rewrite policies — transparent request and response modification A rewrite policy modifies HTTP traffic in transit without the application or the client knowing. Common actions: insert_http_header (add a header), replace_http_res (swap a header value), delete_http_header (remove a header), replace (change a URL segment or body substring). The application sees the rewritten traffic; clients see the rewritten response. ### The four rewrite action types INSERT_HTTP_HEADER — adds a new header (e.g. X-Forwarded-Proto: https ). Used to pass the client protocol to a backend that sits behind SSL offload.
- DELETE_HTTP_HEADER — removes a header (e.g. strip Server: from responses to hide stack identity).
- REPLACE — replaces a substring: rewrite /old-app/ to /new-app/ in the URL, or swap a cookie domain.
- INSERT_BEFORE / INSERT_AFTER — splice content into the URL or body at a matched position.  Rewrite policies can be bound to the  REQUEST  direction (fires before the request reaches the backend) or the  RESPONSE  direction (fires on the reply coming back). Getting this direction wrong is the most common rewrite mistake — if you are adding a request header, bind to REQUEST; if you are stripping a response header, bind to RESPONSE.

  Figure 2 — Rewrite action types — what each one does
   Four rewrite action types cover all header and URL modification scenarios in NetScaler ADC.
- Rewrite action types — what each one does INSERT_HTTP_HEADER Add a new header — e.g. X-Forwarded-Proto for SSL offload DELETE_HTTP_HEADER Remove a header — e.g. strip Server from responses REPLACE Swap a URL segment, cookie domain, or body substring INSERT_BEFORE / AFTER Splice content at a matched position in URL or body Four rewrite action types cover all header and URL modification scenarios in NetScaler ADC. ✏️ Advanced default-syntax tap to flip The modern expression language for all NetScaler AppExpert policies. Uses dot-notation on traffic objects: HTTP.REQ, HTTP.RES, CLIENT.IP. Replaces the older classic syntax. 🔄 Rewrite action tap to flip Modifies HTTP traffic transparently — insert, delete or replace headers, URL segments or body content. The backend still processes the (rewritten) request. ⚡ Responder action tap to flip Sends an immediate reply from NetScaler (redirect, HTML page, DROP) before the backend sees the request. Four action types: REDIRECT, RESPONDWITH, DROP, NOOP. 🎯 Bind priority tap to flip A number (1–2147483647) that controls evaluation order — lower fires first. Two policies at the same priority are ordered alphabetically by name. gotoPriorityExpression = NEXT or END controls chaining. Always name the direction In any answer about rewrite, say REQUEST or RESPONSE explicitly. 'I added a rewrite policy' is incomplete — an interviewer will immediately ask which direction. Header injection goes on REQUEST; stripping response headers (like Server or X-Powered-By) goes on RESPONSE. Get the direction wrong in production and the action either never fires or corrupts the wrong side of the transaction. Quick check · Q2 of 10 · Apply You need to add the header 'X-Real-IP' with the client source IP to every request before it reaches the backend. Which rewrite action type do you use? a) DELETE_HTTP_HEADER on RESPONSE b) REPLACE on REQUEST c) INSERT_HTTP_HEADER on REQUEST with CLIENT.IP.SRC as the value d) RESPONDWITH on REQUEST Correct: c. INSERT_HTTP_HEADER adds a new header. Binding to REQUEST ensures it is added before the backend sees the connection. CLIENT.IP.SRC is the advanced-syntax expression for the client source address. 👉 So far: Rewrite modifies traffic transparently. Four action types: INSERT_HTTP_HEADER, DELETE_HTTP_HEADER, REPLACE, INSERT_BEFORE/AFTER. Bind to REQUEST or RESPONSE — get the direction right. ## ③ Responder policies — send a reply before the backend ever sees the request A responder policy fires on the request path and sends a reply directly from NetScaler — the backend never sees the connection. This is what separates responder from rewrite: rewrite modifies traffic that still flows; responder terminates the flow with an immediate answer. The four responder actions are: REDIRECT (301/302 with a target URL — the most common use, e.g. HTTP-to-HTTPS redirect), RESPONDWITH (sends a complete HTTP response you define — useful for maintenance pages, health-check endpoints, or custom 403 pages), DROP (silently drops the TCP connection — useful to block scanners without feeding them a response), and NOOP (pass-through; used to break policy label chains deliberately). The interview line: use responder when the answer comes from NetScaler; use rewrite when the answer still comes from the backend but modified. A maintenance-mode page is a responder (NetScaler answers). Injecting a request-id header is a rewrite (backend still handles the request). Confusing these two is a guaranteed mark-drop in any NetScaler interview. Figure 3 — Responder actions — four ways to terminate a request A responder policy sends a reply from NetScaler directly; the backend never sees the connection. Responder actions — four ways to terminate a request Responder fires on REQUEST REDIRECT (301/302) RESPONDWITH (HTML) DROP (silent close) NOOP (pass-through) A responder policy sends a reply from NetScaler directly; the backend never sees the connection. Binding a responder policy to RESPONSE Responder policies only fire on the REQUEST direction — you cannot bind them to a response. The CLI will accept the command but the policy will never trigger. If your redirect or maintenance page is not working, check 'show vserver  ' and verify the bind type is REQUEST, not RESPONSE. ### ▶ Watch an HTTP request get redirected to HTTPS by a responder policy Step through the full AppExpert evaluation for a plain HTTP request. Press Play for the healthy path, then Break it to see the classic bind-point mistake. ① HTTP request Client sends GET http://loans.example.in/apply — hits the HTTP vServer on port 80. ▼ ② Responder eval NetScaler evaluates the responder policy: expression HTTP.REQ.IS_VALID && !CLIENT.SSL.IS_SSL returns true. ▼ ③ REDIRECT fires Action = REDIRECT to https://loans.example.in/apply (301). NetScaler sends the 301 directly — backend never sees the request. ▼ ④ Client follows Client re-requests on HTTPS (443). The HTTPS vServer has no responder policy — request reaches the backend normally. Press Play to step through the HTTPS redirect path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Analyze A responder policy with action REDIRECT fires on a request. What does the backend server see? a) The original request, plus a Location header b) Nothing — NetScaler replies directly and the backend never receives the connection c) The redirected request on the new URL d) A TCP RST from the backend Correct: b. Responder terminates the flow: NetScaler sends the 301/302 directly to the client. The backend never receives the original connection — that is the whole point of responder vs rewrite. 👉 So far: Responder fires on REQUEST and answers from NetScaler: REDIRECT (301/302), RESPONDWITH (HTML), DROP (silent), NOOP (pass). Backend never sees the connection. ## ④ Bind points, evaluation order & common use cases Policies can be bound at three levels. vServer bind : the policy fires only for traffic hitting that virtual server — the most surgical option. Global bind ( add rewrite global or add responder global ): fires for all matching traffic on the appliance — use with care and a tight expression. Policy label : a named chain of policies you can call from another policy's goto-expression, enabling branching and reuse. Within a bind point, evaluation order is controlled by the priority number (lower fires first) and the gotoPriorityExpression . Setting goto to NEXT continues to the next matching policy; END (the default) stops evaluation after the first match. If two policies have the same priority, NetScaler picks alphabetically by name — avoid duplicates. ### Five use cases you will be asked about HTTP-to-HTTPS redirect : responder REDIRECT, expression HTTP.REQ.IS_VALID && !CLIENT.SSL.IS_SSL , bound to the HTTP vServer.
- Insert X-Forwarded-For : rewrite INSERT_HTTP_HEADER on REQUEST, CLIENT.IP.SRC as the value, bound to the LB vServer.
- Strip Server header : rewrite DELETE_HTTP_HEADER on RESPONSE, expression TRUE.
- Maintenance page : responder RESPONDWITH a 503 HTML payload, expression TRUE, enabled only during maintenance windows via policy enable/disable.
- URL rewrite : rewrite REPLACE on REQUEST, expression matching the old URL prefix, replacing with the new path.
  Figure 4 — Rewrite vs Responder — which to use when
   Pick rewrite when the backend still handles the request; pick responder when NetScaler itself answers.
- Rewrite vs Responder — which to use when Rewrite policy Backend still handles request Modifies headers, URL or body Binds to REQUEST or RESPONSE Examples: X-Forwarded-For, URL Responder policy NetScaler answers directly Redirect, drop or HTML reply Binds to REQUEST only Examples: HTTPS redirect, 503 page Pick rewrite when the backend still handles the request; pick responder when NetScaler itself answers. Priya at a Mumbai fintech faces this After migrating a loan portal from HTTP to HTTPS, some mobile clients are still landing on HTTP pages. The HTTP-to-HTTPS redirect policy was added but is not firing for those clients. Likely cause The responder REDIRECT policy was bound to the HTTPS vServer (443) instead of the HTTP vServer (80). Since the redirect should fire on plain HTTP connections, it must be bound to the HTTP vServer. Diagnosis Run 'show responder policy  ' — the bound entity shows the HTTPS vServer. The HTTP vServer has no responder policy bound. NetScaler CLI ▸ show responder policy   ▸ show vserver   -summary Fix Unbind the policy from the HTTPS vServer. Bind it to the HTTP vServer: 'bind lb vserver   -policyName   -priority 100 -type REQUEST -gotoPriorityExpression END'. Verify From a mobile client or curl, send a plain HTTP request to the portal. Confirm you receive a 301 to the HTTPS URL. The HTTPS vServer should have no responder policy bound. Use the policy expression evaluator before going live NetScaler has a built-in expression evaluator: 'nsconmsg -d current -g ns_policy_hits' shows policy hit counts in real time. Before binding to a production vServer, test your expression with 'show policy expression  ' or use the GUI Expression Evaluator (AppExpert > Expression Evaluator) against a sample URL. Confirm the expression returns true for the traffic you intend to match and false for everything else. Quick check · Q4 of 10 · Evaluate Two rewrite policies are bound to the same vServer REQUEST at priority 100 and 200. The first (pri 100) matches and has gotoPriorityExpression END. What happens? a) Only priority 100 fires; END stops further evaluation b) Both policies fire because both are bound to the same vServer c) Priority 200 fires first because higher numbers have precedence d) Both fire in alphabetical order by policy name Correct: a. Lower priority number fires first. gotoPriorityExpression END stops the chain after the first match. So priority 100 fires, rewrites traffic, and evaluation stops — priority 200 never runs. 👉 So far: Bind at vServer (surgical), global (all traffic), or policy label (chain/branch). gotoPriorityExpression NEXT continues; END stops. Five use cases: HTTPS redirect, X-Forwarded-For, strip Server header, maintenance page, URL rewrite. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the three parts of every AppExpert policy? What is the difference between a rewrite policy and a responder policy? How does NetScaler decide which policy fires when multiple policies match? What are the four responder action types? When should I bind a policy at the vServer level vs globally? How do I debug a rewrite or responder policy that is not firing? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which advanced default-syntax expression object gives you the incoming HTTP request URL? a) CLIENT.IP.SRC b) HTTP.RES.STATUS c) HTTP.REQ.URL d) SERVER.IP.DST Correct: c. HTTP.REQ.URL exposes the request URL as a string object in the advanced default-syntax. You chain methods on it — e.g. HTTP.REQ.URL.STARTSWITH('/api/') or HTTP.REQ.URL.CONTAINS('login'). Q6 · Understand A rewrite policy is bound to a vServer with direction RESPONSE. On which traffic does it evaluate? a) Responses sent by the backend to the vServer before forwarding to clients b) Requests arriving from clients at the vServer c) All traffic on the appliance regardless of direction d) Only SSL-decrypted traffic Correct: a. Direction RESPONSE means the policy evaluates HTTP responses on their way back from the backend to the client. REQUEST direction evaluates the inbound client request before it reaches the backend. Q7 · Apply You want to block vulnerability scanners by silently closing the TCP connection when the User-Agent header contains 'Nikto'. Which policy type and action? a) Rewrite policy with DELETE_HTTP_HEADER on REQUEST b) Responder policy with RESPONDWITH a 403 page c) Rewrite policy with REPLACE on the User-Agent header d) Responder policy with action DROP Correct: d. DROP is the responder action that silently closes the TCP connection — no response is sent at all, which starves scanners of information. RESPONDWITH gives them a status code to log. Rewrite cannot terminate a connection. Q8 · Analyze Policy A (priority 50, goto NEXT) and Policy B (priority 150, goto END) are both bound to the same REQUEST bind point. Both expressions evaluate to true. What fires? a) Only Policy B, because END means it has final say b) Both A and B fire: A first (lower priority), then B because goto NEXT continues evaluation c) Only Policy A, because priority 50 is lower and NEXT stops further evaluation d) Neither, because conflicting goto expressions cancel each other Correct: b. Priority 50 fires first (lower number = first). Its gotoPriorityExpression is NEXT, so NetScaler continues to the next matching policy — priority 150. That fires with goto END, stopping any further evaluation. Both actions execute. Q9 · Evaluate A team bound an HTTP-to-HTTPS responder policy globally instead of to the HTTP vServer. What is the most likely unintended consequence? a) No consequence — global is always safer than vServer binding b) HTTPS clients on port 443 may also match the policy and enter a redirect loop c) The policy will never fire because responder cannot be bound globally d) The expression automatically excludes SSL traffic so there is no risk Correct: b. A global bind fires for all vServers. If the expression does not explicitly exclude SSL traffic (!CLIENT.SSL.IS_SSL), HTTPS clients hitting the 443 vServer can also match and get redirected back to HTTPS — an infinite loop. Always include the SSL check or bind to the HTTP vServer only. Q10 · Evaluate After adding a RESPONDWITH maintenance-page responder policy, all traffic — including the health-check URL /health — is getting the 503 page. What is the cleanest fix? a) Delete the policy during maintenance windows only b) Change the action to REDIRECT instead of RESPONDWITH c) Tighten the expression to exclude the health-check path: add && !HTTP.REQ.URL.EQ('/health') d) Use a rewrite policy instead for maintenance pages Correct: c. The expression 'TRUE' (or a broad match) catches everything including the monitor probe. Adding !HTTP.REQ.URL.EQ('/health') to the expression excludes the health path, so load balancer monitors still get a 200 while users get the 503 maintenance page. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the key difference between a rewrite policy and a responder policy, and when would you use each? Then compare with the expert version. Compare with expert answer Expert version: A rewrite policy modifies HTTP traffic in transit (inserting, deleting or replacing headers, URL segments or body content) while the backend still handles the request. A responder policy intercepts the request on the NetScaler and sends a complete reply — redirect, HTML page or DROP — before the backend ever sees the connection. Use rewrite when you need to pass modified traffic to the application (add a header, rewrite a URL). Use responder when the answer should come entirely from NetScaler (HTTP-to-HTTPS redirect, maintenance page, blocking scanners). ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Citrix NetScaler (ADC) at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Advanced default-syntax The modern NetScaler expression language using dot-notation on traffic objects (HTTP.REQ, HTTP.RES, CLIENT.IP). Replaced the older classic expression syntax for all AppExpert policies. Rewrite policy An AppExpert policy that modifies HTTP headers, URL or body content in transit. The backend still handles the (modified) request. Binds to REQUEST or RESPONSE direction. Responder policy An AppExpert policy that fires on REQUEST and sends a complete answer from NetScaler (REDIRECT, RESPONDWITH, DROP, NOOP) without the backend ever seeing the connection. Bind point Where a policy is anchored in the NetScaler pipeline — a specific vServer, a global bind, or a named policy label — combined with the direction (REQUEST or RESPONSE). Bind priority A number (1–2147483647) that controls evaluation order within a bind point. Lower number fires first. Duplicate priorities are resolved alphabetically by policy name. gotoPriorityExpression Controls chaining after a policy match: NEXT continues to the next matching policy; END (default) stops evaluation. Can also be set to a specific priority number to jump. Policy label A named chain of policies that can be invoked from another policy's goto expression, enabling branching, reuse and modular policy design. RESPONDWITH A responder action that sends a complete, user-defined HTTP response (status code + headers + body) directly from NetScaler, used for maintenance pages, custom error pages and health endpoints. #### 📚 Sources Citrix / Cloud Software Group — NetScaler (ADC) Rewrite feature documentation: actions, policy expressions and bind points . docs.netscaler.com
- Citrix / Cloud Software Group — NetScaler Responder feature guide: REDIRECT, RESPONDWITH, DROP and NOOP actions . docs.netscaler.com
- Citrix / Cloud Software Group — AppExpert policies and expressions: advanced default-syntax expression reference . docs.netscaler.com
- Citrix / Cloud Software Group — Policy evaluation: priority, gotoPriorityExpression and policy labels . docs.netscaler.com
- Citrix / Cloud Software Group — NetScaler ADC 14.x release notes and AppExpert policy engine updates (2025-2026) . docs.netscaler.com
- Cloud Software Group Support — Troubleshooting rewrite and responder policies: hit counters, expression evaluator and bind verification . support.citrix.com

### What's next?

             Got the policy engine? Next, go deep on NetScaler Content Switching and Load Balancing vServer binding — how the same AppExpert expressions route traffic across server groups, health monitors and SSL profiles.

                 Next · All interview lessons →
                 Practice on exam.techclick.in →

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt
