How do you configure Angular CLI dev server proxying?
Tests Angular CLI proxying to bypass CORS locally. Good answer: create proxy.conf.json with target and path, register it in angular.json serve options as proxyConfig, then restart ng serve.
What's really being asked
This question evaluates whether you understand the Angular CLI development server's built-in proxy capability and can distinguish a frontend build-tool solution from backend or browser workarounds. Senior engineers should know that CORS is a browser security feature, but during local development the CLI can transparently route requests through the dev server to avoid cross-origin friction without altering the production API.
The full answer
First, create a proxy configuration file such as src/proxy.conf.json containing a path pattern and target. For example, map /api to http://localhost:3000 with secure set to false if the backend uses HTTP. Second, wire this file into the project by adding the proxyConfig option under the serve target in angular.json, pointing to the proxy file path. Third, emphasize that the ng serve process must be restarted after any proxy file edit because the dev server reads the configuration at startup. Fourth, mention path matching nuances, specifically that /api matches only the exact path in the Vite-based dev server while /api/ matches all subpaths, and that the legacy Webpack dev server treated /api as equivalent to /api/.
The mistakes people make
Suggesting to enable CORS on the backend is a red flag because the question specifically asks for a CLI dev server fix and backend changes are often impossible or undesirable in local setups. Proposing to swap URLs in environment.ts files does not solve the CORS problem; the browser will still block cross-origin requests. Recommending browser flags or extensions to disable CORS indicates a misunderstanding of both security and sustainable development workflows. Another weak answer is editing the backend port to match the frontend, which is impractical in real teams.
What usually comes next
An interviewer might ask how path rewriting works if the backend does not expect the /api prefix, which you handle with the pathRewrite property in the proxy config. They might also ask about proxying WebSocket connections during development, or how this setup translates to production where the proxy does not exist and a real reverse proxy or same-origin deployment is required. You should also be ready to discuss SSL handling when the backend uses self-signed certificates.
A concrete example
Suppose your Angular app runs on localhost:4200 and your Express API runs on localhost:3000. You create src/proxy.conf.json with /api/** as the key, target set to http://localhost:3000, and secure set to false. In angular.json, under projects my-app architect serve options, you add proxyConfig pointing to src/proxy.conf.json. When you run ng serve, a request from your Angular service to /api/users is forwarded by the dev server to http://localhost:3000/api/users, the browser sees a same-origin request, and CORS errors disappear. If you change the proxy file, you must stop and restart ng serve for the new rules to take effect.
Interview question
To avoid CORS errors when calling a local backend from an Angular app in development, what should you do?
- a.Create a proxy file, register it under serve proxyConfig in angular.json, and restart ng serveCorrect
- b.Update environment.ts to point directly to the backend origin
- c.Launch the browser with disabled web security to allow cross-origin requests
- d.Enable CORS headers on the backend server for localhost:4200
Why? this is the answer
The Angular CLI dev server proxies requests to the backend only when you register a proxy configuration file in angular.json under the serve target and restart ng serve. Changing environment.ts to hit the backend directly does not resolve CORS because the browser still sees a cross-origin request.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles