Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensureUrl failure (potentially due to corporate proxy usage) #1541

jedateach opened this issue Apr 4, 2018 · 10 comments

ensureUrl failure (potentially due to corporate proxy usage) #1541

jedateach opened this issue Apr 4, 2018 · 10 comments


Copy link

@jedateach jedateach commented Apr 4, 2018

Current behaviour:

Cypress could not verify that the server set as your 'baseUrl' is running:


Your tests likely make requests to this 'baseUrl' and these tests will fail if you don't boot your server.

Desired behavior:

Tests run after successful ensureUrl check

How to reproduce:

Run tests over proxy.

Or this might be to do with the fact our baseURL serves 403 responses - which is normal behaviour for us. Our tests query sub-urls, which return 200 responses. This theory is inconsistent with the call failing the ensureUrl check.

Our hunch is that node's net.connect method, used in the ensureUrl check isn't respecting proxy settings.

Additional Info (images, stack traces, etc)

We are able to run via the Cypress UI, but with a warning message in the UI.

When I commented out the following ensureURL check, tests were able to run.

  _this._server.on("upgrade", onUpgrade);
          _this._server.once("error", onError);
          return _this._listen(port, onError).then(function(port) {
            return Promise.all([
              httpsProxy.create(appData.path("proxy"), port, {
                onRequest: callListeners,
                onUpgrade: onSniUpgrade
              }), fileServer.create(fileServerFolder)
            ]).spread(function(httpsProxy, fileServer) {
              _this._httpsProxy = httpsProxy;
              _this._fileServer = fileServer;
              _this._baseUrl = baseUrl;
              // if (baseUrl) {
              //   return connect.ensureUrl(baseUrl)["return"](null)["catch"](function(err) {
              //     if (config.isTextTerminal) {
              //       return reject(errors.get("CANNOT_CONNECT_BASE_URL", baseUrl));
              //     } else {
              //       return errors.get("CANNOT_CONNECT_BASE_URL_WARNING", baseUrl);
              //     }
              //   });
              // }
            }).then(function(warning) {
              _this._onDomainSet(baseUrl != null ? baseUrl : "<root>");
              return resolve([port, warning]);
  • Operating System: RHEL7
  • Cypress Version: 1.4.2
  • Browser Version: Chome 60
  • Node Version: 8.8.0
@jedateach jedateach changed the title ensureUrl failure ensureUrl failure (potentially due to corporate proxy usage) Apr 4, 2018
Copy link

@brian-mann brian-mann commented Apr 24, 2018

This is correct, net.connect does not respect proxies. We'll need to switch to using a regular HTTP request when net.connect fails or when proxies are set.

Copy link

@knaumenko knaumenko commented Oct 11, 2018

I am getting the same error when running my tests in circleCI and updating env variables didn't help. Are there any progress on this?

Copy link

@cgalbiati cgalbiati commented Oct 11, 2018

I am getting the same error when running my tests in circleCI and updating env variables didn't help. Are there any progress on this?

To elaborate on @katerynae's comment (I am a teammate), we started getting the error when we switched from a url that was redirected to a cdn using cname rules, to one that was proxied through cloudflare and an nginx server.

Copy link

@rsmets rsmets commented Oct 12, 2018

I have been using a workaround of just passing an environmental variable effectively replacing the baseUrl setting in the cypress.json. However I think a side effect of doing so is upon first opening a test using the test runner the initial check is made on localhost (and subsequently tests are run) then the browser reloads and all but the first test is reran which is what the dashboard reads as the result. This stutter step, so to speak, has had averse effects on tests as one can imagine. Below is an example to reproduce. Please open the console with preserve log checked. In this example the testUrl value is not used but in reality is. I have posted this a separate bug ticket here #2602

var randomstring = require("randomstring");
const BASE_URL = Cypress.env('testUrl'); // until is resolved using testUrl env var instead of baseUrl

var randomString;
describe('bug highlight', function () {
  before(function () { 
    randomString = randomstring.generate();
    console.log('randomString1', randomString);

  context('bug', function () {
    it('post', () =>{
        console.log('randomString2', randomString);
        return cy.request({
            method: 'POST',
            url: ``, //non-example case I would use var BASE_URL defined above via an env variable 
            form: false,
            body: {"jsr":{"_count":1,"bdl":"7133","msg":"Okay","u":"","pv":`${randomString}`,"sid":"jn6d3c0k2juz91","r":"","sta":200,"tas":1539368968738,"bld":17252,"s":"","uid":"jn6d3c0k2juz91","typ":"im","cfdt":"D","rt":115,"_type":"jsr"}}
        }).then((response) => {
            console.log('in request response');

    it('visit', () =>{
        console.log('randomString3', randomString);

Copy link

@cypress-bot cypress-bot bot commented Apr 1, 2019

The code for this is done in cypress-io/cypress#3531, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

Copy link

@supasympa supasympa commented Apr 30, 2019

Please could someone confirm that version 3.2.0 has fixed this issue?
I'm trying it and see the same behaviour as I did previously with version 3.1.*

Running on a different network without proxies, I don't have the same issue.

Copy link

@Lakitna Lakitna commented Apr 30, 2019

Latest release was 3/15/2019
This issue was closed on 4/1/2019

So this is not a part of 3.2.0.

Copy link

@jennifer-shehane jennifer-shehane commented May 1, 2019

This issue is still pending release - as indicated by this comment #1541 (comment) and the label of stage: pending release.

This is not part of 3.2.0. We will comment on this issue as soon as it is released.

Copy link

@supasympa supasympa commented May 1, 2019

My mistake - sorry for the confusion!

Copy link

@cypress-bot cypress-bot bot commented May 17, 2019

Released in 3.3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

8 participants