skip to content

Two Postman requests to the same host, one proxied and one not — how do you work out why?

level: seniorimportance: should knowfreq 37%

answer

  1. The identical part cannot be the cause
  2. Compare full URLs, not endpoints
  3. Replay the decision in code order
  4. Scheme and path are in the pattern
  5. An unresolved lookup is not direct

basics

~20 s

Stop reasoning about the host and compare the two full URLs, because proxy patterns cover scheme, host and path. Then replay the decision in code order: disabled entries skipped, bypass before match, first entry wins, systemProxy last.

solid answer

~40 s

The host is the part that is identical, so it cannot be the cause. Both `match` and the `bypass` list are Chrome-grammar patterns over **scheme, host and path**, so replay the decision per full URL in the order the code takes it: `ProxyConfigList.resolve` walks entries in list order, skips any `disabled` entry untested, and for each remaining entry `ProxyConfig.test` checks `bypass` **before** `match`; the first entry that applies wins and the walk stops; if nothing applies, the runtime falls back to `systemProxy`. The split therefore comes from one of four things — a bypass pattern covering one URL, a scheme or path difference, a shadowing earlier entry, or the fallback. Narrow the bypass or reorder the list; widening `match` cannot beat a bypass hit.

code

javascript · 8 lines
javascript
const { ProxyConfigList } = require('postman-collection');

const list = new ProxyConfigList({}, [
  { host: 'proxy.internal', port: 8080, match: 'http+https://*/*', bypass: ['https://api.example.com/internal/*'] }
]);

console.log(list.resolve('https://api.example.com/v1/orders'));
console.log(list.resolve('https://api.example.com/internal/ping'));

go deeper

for a junior

Be ready to point out that proxy rules are written over whole URLs, so two calls to one host can differ if their scheme or path differ.

for a middle

Explain the evaluation you would replay: disabled entries skipped, bypass tested before match on each entry, and the first applicable entry ending the walk.

for a senior

Show a disciplined procedure: capture both complete URLs, replay resolution by hand, change one thing, re-run both calls, and record the verdict as a reusable rule.

for a principal

Own the systemic point: a shared, ordered, first-hit proxy list with an environment fallback makes runs non-reproducible across machines, so decide how that configuration is owned and reviewed.

## Why "the same host" is the wrong unit The instinct in this situation is to reason about the host, because the host is the part of the two URLs that is identical. The code never reasons about hosts on their own. Both properties that decide proxy selection in Postman's SDK — `match` on a `ProxyConfig`, and the `bypass` list on the same entry — are **Chrome-grammar `UrlMatchPattern`s**, of the form `<scheme>://<host><path>`. Scheme and path are therefore first-class parts of the decision. Two URLs that share a host can differ in either, and a pattern that covers one can miss the other. So the first move is to stop describing the problem as "the same host" and start describing it as two full URLs. ## The decision, in the order the code makes it Reconstruct it in exactly this sequence, per URL: 1. **`ProxyConfigList.resolve(url)`** walks the entries in list order. 2. Any entry with `disabled` set is **skipped without being tested**. 3. Each remaining entry is asked whether it applies. Inside `ProxyConfig.test`, `bypass` is checked **before** `match`, so a bypass hit ends that entry's evaluation with "no" regardless of what `match` says. 4. The **first** entry that says yes is the answer, and the walk stops there. 5. If nothing says yes, the runtime falls back to **`systemProxy`**. Every explanation for a split between two URLs lives in one of those five steps, and they are cheap to check in order. ## What can differ between two URLs on one host | Difference | How it changes the verdict | |---|---| | scheme (`http` vs `https`) | a pattern is scheme-specific unless written with the `http+https` form | | path | a pattern's path part must cover the URL's path; `/*` and a literal prefix behave differently | | port | part of the URL the pattern is tested against, and easy to omit when writing one | | which entry is reached | an earlier entry may capture one URL before the entry you are reading is consulted | The most common real cause is a `bypass` pattern that covers one of the two URLs and not the other — because the bypass was written for a scheme or a path prefix rather than for a host. ## The two traps that make it look inexplicable - **The bypass ordering.** Someone reads `match`, confirms it covers both URLs, and concludes the configuration cannot be responsible. It can: `match` is not consulted after a bypass hit, so a correct `match` proves nothing on its own. - **The fallback.** `systemProxy` means "no configured entry applied" does not imply "the call went direct". A URL can traverse a proxy that is written nowhere in the list, which makes the split look like it has no configured cause at all. ## A procedure that ends the argument 1. Capture both **complete** URLs — scheme, host, port, path — rather than the endpoint names. 2. Run the two URLs through the entries yourself in list order, honouring `disabled`, and for each entry check `bypass` before `match`. 3. Note the first entry that applies to each URL. If they differ, you already have the answer. 4. If one URL resolves to nothing, treat the fallback as the live hypothesis rather than assuming direct. 5. Fix the cause you found: narrow an over-broad `bypass`, reorder a shadowing entry, or enable the entry that was skipped. Do **not** widen `match` as a first move — it cannot overcome a bypass hit, and it usually broadens the blast radius of an entry that was already correct. ## Keeping the diagnosis honest Two disciplines keep this from turning into guesswork. First, **change one thing at a time and re-run both URLs**, because a change that fixes the proxied call often changes the direct one too. Second, **write the verdict down as a rule, not an anecdote**: "URLs under this path hit a bypass entry ahead of the matching entry" is reusable; "it works now" is not. The reason this is a senior question rather than a configuration lookup is that the observable symptom — two calls to one host behaving differently — has at least four distinct mechanical causes, and the wrong instinct (edit the pattern that obviously should have matched) makes three of them worse.

  • The call that went direct resolved to no entry at all. Is that the end of the diagnosis?
    No. When nothing in the list applies, the runtime falls back to `systemProxy`, which draws on the executing environment rather than the list. So an unresolved lookup does not establish that the request went direct, and it explains why the same configuration behaves differently on two machines. Confirm the fallback before concluding anything.
  • Why is widening the match pattern the wrong first move here?
    Because `match` is consulted only after the `bypass` list has been checked and missed. If a bypass pattern covers the URL, no widening of `match` is ever reached, so the change is unobservable while still broadening the entry for every other URL. Narrow the bypass, or reorder the shadowing entry, instead.

saying these in an interview costs you the question

  • Reasons about the shared host instead of the full URLs
  • Concludes configuration is innocent because match looks correct
  • Treats an unresolved lookup as proof of a direct call
  • Widens the match pattern as the first remedy
  • Ignores list order when one entry seems skipped
  • Changes several settings at once and re-runs only one call