Angular HTTP Interceptor Not Firing: Real Causes and Fixes

Angular's HTTP client uses the `HTTP_INTERCEPTORS` injection token to collect all interceptors into an ordered array. The `HttpInterceptorHandler` chain is built by injecting `HTTP_INTERCEPTORS` as `@Inject(HTTP_INTERCEPTORS) interceptors: HttpInterceptor[]`. If any provider is registered without `multi: true`, Angular's DI replaces the token value with that single provider, destroying the array. The result: only the last registered non-multi interceptor survives, or if the non-multi interceptor fails to instantiate, the array becomes empty.

This is a common pitfall because most Angular providers are singular (e.g., a service). The `multi` flag tells Angular to collect providers into an array rather than override. Many developers forget it because documentation shows it but code completion doesn't enforce it. A quick grep for `HTTP_INTERCEPTORS` in your project will reveal missing `multi: true`.

If you provide an interceptor in a lazy-loaded module's `providers` array, that interceptor only intercepts HTTP requests made by components and services within that module (and its children). Angular creates a child injector for each lazy module. The root `HttpClient` uses the root injector's `HTTP_INTERCEPTORS` array. So interceptors provided in lazy modules are invisible to the root injector. This is intentional – it allows feature modules to add interceptors only for their own requests, but it often surprises developers who expect global interception.

The fix: either provide the interceptor in the root AppModule (or `app.config.ts` for standalone), or import the lazy module eagerly. Alternatively, you can use `providedIn: 'root'` on the interceptor class and still register it with `multi: true` in the root – the `providedIn` only ensures the class itself can be injected, but the token registration is what adds it to the chain.

Angular's production builds use Ahead-of-Time (AOT) compilation and tree-shaking to remove dead code. An interceptor class that is only referenced as a provider token (via `useClass`) may be considered unused if the token itself is not referenced by any component's constructor. Angular's compiler tracks dependencies through `@Injectable()` and constructor injection. If the interceptor is not injected anywhere directly (only registered as a provider for `HTTP_INTERCEPTORS`), the compiler might not see the dependency and tree-shaking may remove the class.

To prevent this, ensure the interceptor is referenced at least once in a way the compiler can trace. Common techniques: add the interceptor to an `entryComponents` array (Angular 9+ deprecated, but still works), or import the interceptor class in the module file and use it in a factory provider. The safest approach is to use `useExisting` with a class that has `providedIn: 'root'` – but that's complex. Simpler: add a dummy `@Injectable()` and inject the interceptor into a root service that is never used? That's hacky. What actually works: keep the provider registration in the root module and ensure the module is eagerly loaded. Angular's compiler then includes the class because it's referenced in the module's provider array.

Angular 15 introduced standalone APIs that change how interceptors are registered. `provideHttpClient(withInterceptorsFromDi())` enables the legacy DI-based interceptor chain (i.e., `HTTP_INTERCEPTORS` token). `provideHttpClient(withInterceptors([myInterceptorFn]))` uses functional interceptors, which are simpler and recommended for new code. Mixing both can cause confusion: if you use `withInterceptorsFromDi()`, you must still register DI interceptors via `providers: [{ provide: HTTP_INTERCEPTORS, useClass: ..., multi: true }]`. If you use `withInterceptors()`, you pass an array of functions directly, and `HTTP_INTERCEPTORS` is ignored.

A common mistake: using `withInterceptorsFromDi()` but forgetting to include the interceptor in the providers array, or using `withInterceptors()` but passing a class instead of a function. Functional interceptors have a different signature: `(req: HttpRequest<unknown>, next: HttpHandlerFn) => Observable<HttpEvent<unknown>>`. If you accidentally pass a class, it won't be called and no error is thrown.

If an interceptor's constructor throws an error (e.g., a required dependency is missing), Angular's DI catches the error and does not add the interceptor to the chain. Worse, it doesn't log the error by default (in production mode). The interceptor simply disappears. This is because `HTTP_INTERCEPTORS` is a multi-provider, and each provider is resolved independently. A failure in one does not block others, but it also does not report the failure.

To debug: add a try-catch in the constructor and log to console. Better: use Angular's `ErrorHandler` to catch all DI errors. You can also temporarily set `providedIn: 'root'` and inject the interceptor into a component to see if it instantiates. If the constructor throws outside the interceptor chain, you'll see the error. Another approach: run `ng serve` with `--prod=false` (dev mode) which gives more verbose DI error messages.